遇到祖传代码：技术债是推翻还是维护？
赵钰莹
讲述：丁婵大小：2.40M时长：05:14
近日，Reddit 上有关技术债务的话题再次引起程序员的广泛讨论，面对由错误或不理想的技术决策所累积的债务，程序员到底是该继续维护还是推倒重写，这个决定应该依据哪些因素来最终决定？如何避免在技术债务上浪费过多时间呢？
技术债务是由 Ward Cunningham 在 1992 年的报告中创造的比喻，被定义为当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。简单来说就是为了快速解决问题而采取的不规范方案。
对任何一家公司而言，在不断发展的过程中会出现很多“技术遗产”，这其中的部分遗产没有文档，甚至连注释都语焉不详，一旦引入新的需求和框架就可能出现混乱、冲突等，这部分代码很难将其称之为“技术资产”，称作“技术债务”会更加准确。
即便技术债务让很多开发人员不爽，但是要想明白完全推翻还是继续维护，依旧是一个巨大的难题，这既需要考虑现有业务的稳定性、也要平衡后续的开发和维护成本。通常，如果业务可以正常有序的运行，管理者很难主动提出重构整个代码。但是，如果不对技术债务进行妥善管理及合理规划，组织或者开发人员很可能会陷入崩溃。
重构，就是在不改变外部行为的前提下，有条不紊地改善代码。为了保障软件的外部行为，唯一的办法就是通过测试。因此，重构是建立在完备的测试覆盖基础之上的。如果不能保证修改后的代码还能提供相同的功能，那么这种修改就可能是错误的，会给用户带来极大损失。在有风险意识的团队中，不会同意盲目重构。
即便公司有完备的测试，但如果重构花费时间周期太长，还是很危险，开发人员不得不在这段时间内同时应付重构工作和新功能的开发。所以，组织应该如何进行抉择呢？
这里可以参考谷歌公司站点可靠性的例子，谷歌的搜索引擎其实并不追求 100% 正常运行。这是因为，99.99% 的正常运行足以让用户把谷歌评为“极其可靠”的服务提供者，而由于最后 0.01% 的指标太难达到，所以根本就不值得为其浪费时间。
因此，如果每年有 52 分钟的计划内停机时间，谷歌会尽可能实现这一目标。而低于 52 分钟的目标都是在浪费时间，相关成本太高，包括无法承担额外风险以及不能为客户额外提供更多功能。
如果将技术债务预算类比成站点可靠性预算，假设目前正在承担的技术债务非常关键，而且开发人员很清楚其能力低于客户与业务能够承受的最低标准，那么应该尽可能弥补，如果预算不允许，可以先考虑偿还其中一部分。如果预算充足，则可以上调风险与债务比例。
总而言之，目标是尽可能保持技术债务水平接近理想程度。换句话说，如果处于上图的红色峰值部分，那么理想的技术债务预算应该是 A 到 B。如果处于绿色峰值部分，那么理想的预算则为 B 到 C，尽量不要选择 A 到 C，这样的预算额度太过激进。
现在也有很多指标可以帮助量化分析技术债务，避免过度浪费时间。决策者可以利用数据分析快速确定需要尽快偿还哪些技术债务，比如：
识别代码库中归属关系较弱的文件，因为代码归属权是代码库运行状况的主要指标。
衡量文件的内聚与耦合情况，并最终列出一份包含弱归属权、低内聚与高耦合文件的列表。
计算各个文件的组成以确定问题文件中的各个子集。正如微软研究院所指出，“活动文件仅占系统总体大小的 2% 至 8%，但占系统文件变更的 20% 至 40%，而且有 60% 到 90% 的 bug 来自于此。”
将这些文件与本季度的发展路线图进行比较。在路线图当中列出的所有功能，是否都要求工程师对问题文件子集进行调整？如果答案是肯定的，请将这些文件作为重构对象，估算相关工作量，并将其分配给文件所有者的工程师。最后，把这部分工作量纳入下阶段计划。
以上就是今天的内容，针对技术债务的判断原则、分类、应该采取哪些措施以及如何避免在技术债务上浪费过多时间等问题，你有何看法呢？欢迎在下方留言讨论。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
李春恒祖传代码，请勿乱动!4
Man先想办法自己打脸给领导看，拿到支撑重构理由的数据，接下来就可以自由发挥了。2
搞怪者😘 😒 😏 👿简单点，扔给其他人负责
收起评论