如何停止在技术债上浪费时间？

摘要：相信每个人都有相同的感受，每个Sprint做好手头工作的压力本来就很大了，怎么可能再拿出10%-20%的时间来偿还技术债务？如果你也曾经为争取这样的时间而起过争执的话，那么一定会明白偿还技术债务占据的时间不容忽视。

但是，偿还技术债务依然可行，本文我们就来介绍一下如何才能做到这一点。

作者 | Stepsize

译者 | 弯月，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

 

我经历过太多的会议在这个话题上浪费大量时间。房间里的每个人都情绪高涨，纷纷拿出各种传闻轶事当作证据，最后往往是声音最响亮的那个人的意见占据上风。

然而，难题在于：如果业务上的压力过大，那么公司就会积攒过多的技术债务，从而导致工程师们失去动力，公司在技术上破产，最后获胜的是你的竞争对手。如果工程上的压力过大，那么公司承担的技术债务可能会太少，结果是你的竞争对手会以更快地速度推出新产品和功能、占领市场，然后用赚来的钱偿还技术债务。这种局面下，你依然是输家。

传统观点认为，工程团队应该让公司明白代码库中存在技术债务，以及技术债务对公司的影响，这样才能获得组织的信任。如果创立公司的首席架构师告诉你立即重构核心代码，那么你也应该照做。

为了留住人才，我们需要建立知识、分享和信任的文化。但这种文化的构建需要长期的努力，而另一方面我们在努力重构的时候，无法确定自己花出去的时间是否值得。我们的努力可以为将来节约时间吗？或者，我们是否可以再等一段时间，先做新功能，然后再来偿还技术债务？这个问题我们永远都没有答案，我们认为产品开发是个艺术行为而不是科学。

那么，下面就让我们从科学的角度看一看这个问题。

网站的可靠性和技术债务预算的共同点有哪些？

 

妥善管理技术债务并认真做好技术债务计划是一个良好的开端。与金融债务一样，如果我们能够很好地掌控的话，就可以把债务当作杠杆撬起更多资金。但是，如果我们承担了过多债务却不自知，例如，没有真正理解交易的条款，即对我们的代码库、客户、团队和业务的影响，那么就可能将公司引向灭亡。

优秀的网站可靠性维护工程团队需要根据管理的技术债务，考虑网站的可靠性预算。网站可靠性是一个由谷歌推广的概念，旨在负责保持软件产品的正常运行，然而有趣的是，即使谷歌这样的公司也没有以100%的正常运行作为目标。这是因为对谷歌的产品来说，99.99%的正常运行就足以让现实世界的用户觉得谷歌极其可靠了。最后的0.01%是一个非常难以达成的指标，因此根本不值得为之奋斗。

因此，只要某个方案能够实现每年52分钟的停机时间，谷歌就会全力以赴尽可能实现这个方案。他们会放弃任何能将停机时间减少到52分钟以下的方案，选择接受风险以便为客户提供更宏大的功能。

你可以按照考虑网站可靠性预算的方式来考虑你的技术债务预算。谨慎地承担你的技术债务，努力将技术负债维持在不影响客户和业务的水平，同时承担更多风险打败竞争对手。

如上图所示，当技术预算呈现红色时，则应该支付部分负债。如果处于绿色状态，则表明可以承担更多风险并承担更多债务。你的目标是尽可能地保持技术负债接近理想的水平。换句话说，如果你的技术负债呈现上图红色部分的顶峰，那么理想的技术债务预算应该是A⇒B。如果你处于绿色部分的顶峰，则应该是B⇒C。请记住A ⇒C的预算太大了。

因为技术债务可以衡量（请参照我们的另一篇文章：https://blog.stepsize.com/use-research-from-industry-leaders-to-measure-technical-debt/），所以这不仅仅只是个概念，而是切实可行的方法。

 

如何充分利用你的技术债务预算

 

技术债务预算的目标应该是让债务下降或上升到你可以容忍的最大技术债务。为了定义这个预算，你应该确认代码库中哪些区域的技术债务值得立即偿还，即那些有碍于公司达成当前目标的技术债务。你偿还的债务不能太少，但也不必偿还太多债务。

AngelList的远程主管Andreas Klinger在他的文章“重构大型遗留代码库”中有相应的介绍：

并非一切都需要重构。如果不是关键性的功能，或者在未来几个月内没有人需要改进这个功能，或者这个功能太复杂，那么就考虑作为技术债务。

简而言之，你的目标是找到与当前Sprint、当月或当季度代码库有交集的技术债务。偿还这些有交集的技术债务，其余的债务都可以放一放。

在这个过程中科学与艺术相辅相成。你可以通过数据来确定需要尽快偿还的技术债务：

• 找出代码库中没有所有权的文件，因为代码所有权是代码库健康状况的主要指标。

• 衡量这些文件的内聚和耦合，然后找到一组没有所有权、低内聚和高耦合的文件。

• 计算每个文件的活跃度，找到关键的一组文件。微软研究院表明：“活跃的文件仅占系统总体大小的2-8%，占系统文件变化的20-40%，却占所有bug的60-90%。”

• 比较这些文件与本季度的蓝图规划。工程师在构建蓝图中的功能时，是否需要改动你找出来的这组文件？如果是，那么就应该将这些文件作为重构对象，估算所需的工作，并将其分配给相应的工程师。而这些工作也应该纳入你的计划中。

 

与技术债务建立长期的关系

 

我们公司与许多世界级软件公司一样，都采用了这种数据驱动的方法。如今不仅大家更容易提出技术负债的问题，而且我们也知道我们愿意承担多少技术债务，以及何时、如何偿还。我们无需再纠结我们是否在新功能和技术债务之间做出了正确的权衡。我们已经消除了大量的猜测，以及随之而来的恐惧和焦虑。

请注意，这不是每年使用一次的秘密武器。你需要时刻关注技术债务。跟踪每个Sprint所有指标的进度，并不断改进整个过程，才能获得技术财富。

原文：https://blog.stepsize.com/how-to-stop-wasting-engineering-time-on-technical-debt/

本文为CSDN翻译，转载请注明来源出处。

【END】

学了两年Python没抓住关键只学了皮毛，到底错在哪？

https://edu.csdn.net/topic/python115?utm_source=csdn_bw

热 文 推 荐 

☞不满 C 的繁琐，崛起的 Python 正在蚕食编程语言界！

☞CPU 是如何工作的？

☞阿里拟 20 亿美元收购网易考拉；联通 5G 套餐最低 190 元；Rust 1.37.0 发布 | 极客头条

《乐队的夏天》很酷？程序员式的摇滚才燃爆了！

只需要支付0.5元就可以撤回交易？这下可坑苦DApp了……

从原理到代码，轻松深入逻辑回归模型！

@程序员，“10倍工程师”都在追这四大AI风向

常见的Hadoop十大应用误解

行！这下 CSDN 玩大了！粉丝：太良心

点击阅读原文，输入关键词，即可搜索您想要的 CSDN 文章。

 

 

 

 

 

你点的每个“在看”，我都认真当成了喜欢