学习
实践
活动
专区
工具
TVP
写文章

终究,还是要为技术债务交税

"本文将分享为什么要为技术债务付出一定时间成本,否则你将付出不可估量的代价" 现状(一) 如果有一天技术老大告诉管理层,最近两周应用不会发布任何新特性,所有技术人员要投入到重构、自动化工作、非功能性需求以及架构优化保证服务的可扩展性 再说了,谁能保证凌晨的技术人员不犯傻呢? ?     面对当今复杂多变的互联环境,老板们的心态也应该有所改变,愿意为技术人员研究不可见的功能特性留出一定的时间。      输出容易轻松理解和搜索的业务日志;一个阶段开发完成后要考虑安全性检查,如web站点攻击、XSS攻击、sql注入攻击等,这些事情如果非要挤压到一定程度再去解决,很可能会出现不能修改或者修改需要付出更高代价;     就现阶段技术环境而言 具体参考之前写的:云时代的运维正是不折不扣的架构师 所见耳闻(三) 关于最近几天微盟技术故障问题,吃瓜吃的沸沸扬扬,各种消息扑面而来,暂且不论事情结果怎么样吧,网上出了很多防删库指南,【数据备份很重要

14410
  • 广告
    关闭

    热门业务场景教学

    个人网站、项目部署、开发环境、游戏服务器、图床、渲染训练等免费搭建教程,多款云服务器20元起。

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    老码农看到的技术债务

    代码中的坏味道也是技术债务,是一种不计后果的债务,会让问题变得更加严重,进而将技术债务划分为4个象限: ? Bob大叔则认为坏味道并非技术债务技术债务并没有一个普遍接受的范围定义,甚至认为已知的bug也构成了技术债务。当前可用的技术债务量化工具仅仅关注几个维度,比如代码债务和一定程度的设计债务和测试债务技术债务的现金衡量 当然,技术债务的货币化有助于了解技术债务的严重程度,提供了一种跟踪技术债务偿还进度的方法。不过,需要谨慎对待这些成本和工作量估计。 对于所有希望监控技术债务成本并将其保持在一定限额内的敏捷团队来说,这很关键。 直面技术债务 面对已知的技术债务,普遍的经验是防止技术债务的积聚,以及有计划地偿还技术债务。 防止技术债务产生的主要方法是了解开发团队存在的技术债务。开发团队必须了解技术债务,它的各种方面和类型,以及债务对他们的项目的影响。

    56830

    DevOps如何解决技术债务挑战?

    许多组织在迁移到云期间发现了大量的技术债务。但是什么是技术债务呢?DevOps如何帮助我们去解决技术债务呢?在这篇文章中,我们将讨论使用DevOps将您的技术债务负担减少的方式! 什么是技术债务? “先做需要做的事,然后再做想做的事”的工作就是技术债务。 值得指出的是,技术债务不仅会发生在开发中,还可能发生在运营中。 这些都是技术债务。 为什么会存在技术债务? 马丁·福勒(Martin Fowler)的技术债务象限指出,有时技术债务是无意的。您不知道的内容,但是现在您知道了,因此可以对其进行修复。 这可能意味着您“偷工减料”,从而招致技术债务。 ? DevOps如何解决技术债务挑战? 由于这些团队(包括他们的产品经理)每天都会感受到技术债务的影响,因此他们极有动力偿还技术债务,以使生活更轻松。 简单的事情可以帮助团队解决技术难题 第一步是评估和跟踪产品中的技术债务水平。

    43940

    产品经理如何帮助减少技术债务

    花点时间定期与技术负责人交谈,共同了解公司内部技术债务的程度,并承诺予以解决。开发团队(不一定是管理层)中是否有任何拥护者愿意处理技术债务?避免让人们觉得技术债务是罪魁祸首。 让技术债务公开透明 技术债务无处不在,应该成为每一次产品会议的一部分。让它成为一个可操作的项目,并寻求定期更新。 将技术债务的补救列入路线图中 将技术债务嵌入到路线图时间表中。分配任务和时间来进行Bug修复、代码审查、维护,以及全面减少现有债务,以构建更强大、更具弹性的产品。 参考技术债务制定KPI 将消除技术债务作为跟踪组织内成功的方式。围绕具体参考技术债务的产品性能和开发速度创建KPI。 考虑如何预防技术债务技术负责人探讨什么样的战略可以纳入项目过程,以减少技术债务。这可能包括指导、团队培训和结对编程,了解这些是否可以包含进产品预算。

    18730

    Apache Hadoop:通过重构降低技术债务

    如果没有将实际行动纳入代码来控制和解决技术债务的话,那么技术债务将一文不值。 换句话说,技术债务中的14%已被勾销而不需要任何人力。 技术债务是没有价值的,如果没有将实际行动纳入代码,以控制和解决它。 正如您在屏幕截图中所见,Common有70天的技术债务,Mapreduce有66天。Scertify重构评估还计算了自动修正技术债务的潜力:债务抵消。他们都有自动重构的潜力,分别为38天和36天。 技术债务定义为纠正所有检测到的缺陷所需的时间。正如您在下面的屏幕截图中看到的,Common有70天的技术债务和66天的Mapreduce。 正如您在下面的屏幕截图中所看到的那样,在纠正这些缺陷后,每个项目的技术债务已经减少了10天。总的来说,这是20天的技术债务已被注销。

    32520

    在微服务架构中管理技术债务

    什么是技术债务? 从广义上讲,技术债务是在软件开发过程中的一系列决策,这些决策会导致团队通过构建特性以创造价值的能力受损。 在保持快速交付功能的同时偿还技术债务会很困难,而且系统架构越大越难。管理数十或数百个微服务的技术债务要比单个服务复杂得多,并且不偿还债务所带来的风险会增长得更快。 技术能力计划 公司的工程师们提出了技术能力计划(Technology Capability Plan,TCP)来解决技术债务问题。 TCP 是一种基于社区的用于制定偿还技术债务计划的方法。 该计划鼓励社区按照特定的格式制定偿还技术债务的计划。在记录每个领域技术债务的风险分数后,根据该风险分数设定要进行处理的优先级。通过优先级计划,可以与产品经理积极而有效地协商技术债务偿还的工程时间。 仪表盘上显示的这些指标可以让他们更真实地感受到技术债务,使得他们更可能选择偿还结束债务的工程投资。

    9220

    sonar中的技术债务简要了解 原

    sonar中技术债务的计算基于SQALE(Software Quality Assessment based on Lifecycle Expectations,基于生命周期期望的软件质量评估)方法学 那意味着,如果你想用SQALE管理你的技术债务,你首先需要公共的SonarQube存储库中那些规则的标记: 重复的代码块 失败的单元测试 不足的分支单元测试覆盖率 不足的注释密度 一旦你激活了它们,你可以以一个问题跟踪每个质量缺陷,为跟踪技术债务(SQALE方法用天度量)做准备。 ? 这些天的测量值是把每个问题中出现的技术债务相加得到的,你可以在每个问题块中看到。 ? 这里有一个小部件,它叫做技术债务金字塔,它看起来一点不像你以前所见过的金字塔。 ? 不要因这不像是一个古埃及的金子塔而困惑,这是一个比喻的金字塔。阅读它的方法是自下而上的。 像往常一样,每个部分的部件通过点击下钻操作让你知道一个特征的技术债务的精确位置。 SonarSource SQALE插件扩展了SonarQube内置插件的功能。

    1.8K20

    持续集成八 sonarQube配置及使用

    5%已进入应用程序的时间,等级为A 在6至10%之间,评级为B 在11%到20%之间,评级为C 在21%到50%之间,评级为D 任何超过50%的都是E 技术债务 与您的技术债务比率的值相关的项目评级。 新法规的技术债务(new_technical_debt) 努力解决在新法规期内首次提出的所有法规气味。 技术债务比率(sqale_debt_ratio) 开发软件的成本与修复软件的成本之间的比率。 技术债务比率公式为: Remediation cost / Development cost 可以重述为: Remediation cost / (Cost to develop 1 line of code 新法规的技术债务比率(new_sqale_debt_ratio) 在新法规期内更改的法规开发成本与与其相关的发行成本之间的比率。

    99110

    代码质量与技术

    这个定义暗示了这种“负债”是一种刻意的、理性的经过权衡的行为,后文中我们进一步探讨技术债务的类型时会指出这一定义仅仅代表了技术债中相对良性的一类,是一个比较“温和”的定义。 ,因为利息的存在,技术债务不及时偿还的话,会在未来呈现出非线性增长,造成始料不及的损失。 SQALE进一步使用了术语“债务等级”,定义了从A(非常好)到E(非常差)五个等级,根据负债率数值所在区间对应不同的等级,例如SonarQube中缺省[0, 5%]是A,(5%, 10%]是B,(10% 图3技术债度量示例(CppDepend) 图3中工具扫描的代码行数为19862行,共负债32天,债务的年息是9天2小时,负债率是6.39%,债务等级是B级。 图4技术债度量示例(SonarQube) 图中的项目负债12天,共有923个坏味道(即违规项数量),负债率(图中翻译为“技术债务比率”)为6.3%,债务等级(图中为SQALE评级)为B级。

    2.1K61

    准确识别技术债务才是改造遗留系统的破解之道

    如果你是一个信心满满的架构师,选择了更具挑战的遗留系统改造,动手前你应该知道这个遗留系统有哪些呆账坏账,这些欠账称为技术债务。你不仅要搞清楚都有哪些债务,还要搞清楚欠债的根因是什么。 架构与代码代表工程师写的瞬间对架构、代码、业务、环境的认知,随着技术进步,环境变化技术债务就自然产生了,这部分债务属于良性债务,或者说无法避免的债务。 代码已经写完以后才发现设计有问题就晚了,这时技术债务就已经形成了。所以代码检视的过程是学习的过程,也是相互促进的过程。 比如去度量团队的架构债务,代码债务有多少,把债务通过公式转换成时间,这样就得到 A 团队的技术债务是 30 分钟,B 团队的技术债务是 3 天。 如果技术没有管控覆盖绝大多数技术栈,那么难度会指数暴增。在这种场景下你身为一个总工也好高级技术专家也好,首先你要构建你的通用编程框架,基础设施,通用的公共组件以及债务的识别能力。

    16530

    SonarQube实践文档(一)

    SonarQube架构与集成 平台架构 SonarQube平台由4个组件组成 SonarQube服务器 开发人员和管理员操作频繁,用于浏览代码质量和配置服务器。 SonarQube数据库 存储代码分析数据报告。 支持oracle、PostgreSQL、MySQL。 SonarQube插件库 通过插件使平台功能更加强大。 SonarQube扫描器 客户端工具,用于扫描项目。 将扫描结果上传到服务器。 ? 开发工作流 IDE集成 开发人员在IDE开发工具中安装SonarLint进行本地代码扫描分析。 代码审查 开发人员通过UI对代码错误进行分析,减少技术债务。 经理从分析中获取分析报告。 运维使用API自动获取sonar中的数据,使用JMX监控服务器。 ? 关于机器和位置 平台不能通过多个sonarqube服务器公用一个数据库。 每个组件应单独安装在专用计算机上,这样性能是最好的。 扫描器可以在多台机器进行扩展。 所有机器的时间应该是同步一致的。

    99970

    关注

    腾讯云开发者公众号
    10元无门槛代金券
    洞察腾讯核心技术
    剖析业界实践案例
    腾讯云开发者公众号二维码

    相关产品

    • 语音合成

      语音合成

      语音合成(TTS)满足将文本转化成拟人化语音的需求,打通人机交互闭环。 提供多种音色选择,支持自定义音量、语速,让发音更自然、更专业、更符合场景需求……

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券