【软件工程之美 - 专栏笔记】24 | 技术债务：是继续修修补补凑合着用，还是推翻重来？

---

专栏信息

1. 专栏作者：宝玉

2. 专栏发布平台：极客时间

---

主要内容

---

有一个很形象的名词叫“技术债务”，用来形容上面这些架构或代码上的质量问题。

---

一、什么是技术债务？

范围不减，成本不增加，还想节约时间走捷径，就会影响到质量。这个“质量”，不只是产品质量，还有架构质量和代码质量。这种对质量的透支，就是一种债务。而技术债务，就是软件项目中对架构质量和代码质量的透支。

技术债务确实是个形象生动的比喻，让你意识到它是和成本挂钩的，而且技术债务也有金融债务的一些特点，比如有利息，再比如技术债务也有好的一面。

1. 技术债务是有利息的

   债务的“利息”，就是在后面对软件做修改的时候，需要额外的时间成本。

2. 技术债务不一定都是坏的

   在软件项目中，也经常会刻意的欠一些技术债务，提升短期的开发速度，让软件能尽快推出，从而抢占市场；还有像快速原型开发模型，通过欠技术债务的方式快速开发快速验证，如果验证不可行，甚至这笔技术债务都不需要偿还了。

---

二、技术债务产生的原因

如果现实中有人负债累累，那么多半有几个原因：这人对债务没有规划、生活所迫不得不借债、为了长远利益而临时借债、不知情的情况下欠了债务。

技术债务产生的原因也类似，所以《重构》一书的作者 Martin Fowler 把技术债务产生的原因分成了两个维度：

1. 轻率（reckless）还是谨慎（prudent）；
2. 有意（deliberate）还是无意（inadvertent）。

• 轻率 / 有意的债务

  这个象限，反映的是团队因为成本、时间的原因，故意走捷径没有设计、不遵守好的开发实践，对于债务没有后续的改进计划的情况。

• 谨慎 / 有意的债务

  这个象限，则反映的是团队清楚知道技术债务的收益和后果，并且也制定了后续的计划去完善架构和提升代码质量的情况。

• 轻率 / 无意的债务

  这个象限，反映了团队不知道技术债务，也不知道要后续要偿还技术债务的情况。

• 谨慎 / 无意的债务

  这个象限反映了团队其实很重视架构设计和技术债务，但因为业务的变化，或者其他客观因素的原因，造成技术债务的产生。

---

三、如何管理技术债务？

Martin Fowler 画过一张图，来形象的描述了设计、时间和开发速度的关系。没有设计直接写代码，从短期看确实是节约时间的，但是跨过一个临界点后，开发速度会急剧下降。

技术债务的收益和利息也是类似的道理，最初的时候，利息低收益高，欠一些技术债务是会节约时间的，但是超过一个临界点后，利息高收益低，就会大大降低开发效率。

1. 识别技术债务

   如果是现实中的债务，查查银行账户就很容易知道是不是欠债了，而技术债务却没那么直观，但识别技术债务是很关键一步，只有发现系统中的技术债务，才能去找到合适的方案解决它。你要是细心观察，还是可以通过很多指标来发现软：

   • 开发速度降低
   • 单元测试代码覆盖率低
   • 代码规范检查的错误率高
   • Bug 数量越来越多

2. 选择处理技术债务策略

   • 重写：推翻重来，一次还清
   • 维持：修修补补，只还利息
   • 重构：新旧交替，分期付款

3. 实施策略

   当你选择好用哪种策略处理技术债务之后，就可以实施你的策略了。不同的策略可能实施方式上略有不同。

   • 对于重写的策略，要当作一个正式的项目来立项，按照项目流程推进；
   • 对于重构的策略，要把整个重构任务拆分成一个个小任务，放到项目计划中，创建成 Ticket，放到任务跟踪系统中跟踪起来；
   • 对于维持的策略，也要把需要做的修补工作作为任务，放到计划中，放到任务跟踪系统中。

   实施策略的关键就在于要落实成开发任务，作为项目计划的一部分。

4. 预防才是最好的方法

---

四、其他摘抄

• 但技术借债也一样不能是无限制的，因为借债越多，利息越大，当收益抵不过利息时，就会陷入恶性循环，导致开发效率低下，进度难以保障。
• 对于项目中的债务，我们要清楚的知道有哪些技术债务，以及它给项目带来的收益和产生利息，这样才能帮助我们管理好这些债务。
• 重构相对是一种比较折中的策略，就跟我们采用分期付款的方式偿还贷款一样。

---

总结

对于技术债务，是继续修修补补凑合着用，还是推翻重来？其实取决于哪一种策略的投入产出比更好，如果推翻重来代价太大，那么就应该谨慎考虑，不如先修修补补或者局部重构；如果修修补补难以维持，就要考虑重写或者重构。

对于技术债务，还是要在日常开发中有好的意识，不走捷径，防患未然，预防技术债务的发生。