技术债：人的因素

在维基百科中，技术债是这么定义的：

Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

所以我们可以把技术债看做是一种捷径 —— 一种带来短期利益（交付期更短）但需要未来花费更多时间弥补的技术捷径。「债」在这里是一个非常形象的比喻，它和我们日常生活中产生的银行债务有异曲同工之妙：

1) 债务总有归还的时间 —— 技术债在未来的某个时刻也需要通过重构来解决

2) 债务需要付利息，而不断借债，甚至为了还「利息」继续借债，债务成本会越来越高，累积的利息会呈指数增长 —— 在技术债基础上继续引入技术债，会让事情变得越来越糟糕，引入新功能（软件资产）的时间会越来越长。

3) 当债务累积到一定程度，超过资产时，如果此时没有足够的自由现金流来偿还本息，那么个人或者公司可能不得不寻求破产保护 —— 当技术债太大无法通过重构来解决时（或者成本太高），此时重写是最好的方案。

技术债分成几个部分：1) 架构和设计上的技术债 2) 代码实现层引入的技术债 3) 软件测试的技术债 4) 文档技术债。

我们平时对技术债有些误区，认为技术债的引入很多时候是开发工期不够，开发团队不得不做出妥协，选择短平快的解决方案。其实在实际工作中，技术债的引入很大程度上是因为人和流程的原因，而流程是人制定和人来执行的，所以归根结底是人的原因。

首先说人的原因。

架构和设计自不必说，开发者需要有足够的知识，经验和对需求的敏锐把握，才能做出足够好的架构和设计。除此之外，开发者在接到一个新的功能时，他需要处理的不仅仅是这个功能本身，还涉及这个功能和已有系统的对接。开发者是否对已有系统有足够的了解，往往决定了这个功能的质量。

那么，什么叫对已有系统有足够的了解？

首先，开发者需要知道系统提供了哪些 API，哪些是稳定的 API，哪些是不稳定的 API，哪些是在这个层级可以调用的 API，哪些是不该调用的内部 API。这里 API 是广义的 API，可以是后端提供的某个 REST/gRPC 接口，也可以是前端的某个组件，甚至是某个算法的实现。

这件事情在很多开发团队中是很模糊的，在系统内部（比如一个 android 项目内部），大部分时候可能没有成熟稳定的 API 文档，仅仅靠目录结构约定俗成，以及开发人员间的口口相传；在系统间（前端后端之间），即便有文档，可能也是描述地十分简陋的 swagger 或 protobuf 文档，协作还是得靠口口相传。

其次，开发者需要知道当前的系统有哪些技术债，这些技术债产生的原因是什么。

如果说对 API 的理解还不算太大的挑战，那么，全面了解当前系统，尤其是自己所做功能涉及到的技术债，则难度高了一大截。很少有公司或者团队能在引入技术债时撰写文档阐述这里面的 tradeoff，所以，不像 API，你还可以有具体的东西向别人咨询，技术债是个无形的东西，除非你读代码的时候读到了 TODO 或者 FIXME，或者是代码的问题太过明显（比如复制粘贴出来的代码），否则你都不太会知道某段代码有某些问题。

为什么在开发新功能的时候需要知道当前的系统有哪些技术债呢？首要的目的是你不想新的功能无意间加深或者说强化了技术债，使其更难重构；此外，如果能在开发新的功能时，顺手将能解决的技术债解决掉一部分，那将是大大的功劳。

所以，我说技术债里面，人的因素很大 —— 单单是对已有系统有足够的了解这一条，就足以刷掉很多开发者。但开发任务摆在那里，不可能所有的开发都放在团队中少数的几个人那里完成，所以，很多时候，系统的技术债是不断地，慢慢地叠加的。

我们再看流程的问题。

当开发团队没有一套合理的代码构建流程时，技术债也会不断累加。比方说，开发者等待 code review 的 PR 没有代码格式化，没有 lint，没有 UT，那么，code review 还有多大的意义呢？很可能 reviewer 主要的精力都放在了基本的代码问题上，而没有功夫去管更重要的问题：接口设计是否合理，数据结构是否合理，逻辑是否有问题等。

对于这样的问题，很多团队会使用一套完整的流程来应对：

1. 本地代码使用 precommit hook，处理代码风格，lint，UT 等，只有在所有检查通过，才允许 commit
2. 生成 PR 后，CI 至少会做 precommit hook 做的所有事情，以及测试覆盖检查，甚至还会做集成测试。
3. 如果测试覆盖率有明显下降，PR 的 CI 不会通过。开发者必须要更新 UT，达到足够的覆盖率才能通过。
4. 至少两个 reviewer 通过后，并且 PR 跟 master up-to-date，PR 才能被合并。

这个流程不但考虑了尽可能减少代码层面的技术债，还考虑了减少测试层面的技术债。但很可惜，根据我跟很多微信朋友的了解，一半以上的团队都没有这样的流程。

即便这个流程通过机器（比如 precommit / travis / github action）来确保执行，但 code review 依然是其中不稳定的部分。这是因为做 code review 的是人，他们往往受限于自己对系统的理解和对新功能需求的理解，以及自己的时间精力，无法时刻做出最佳的应对 —— 有时候 review 质量很高，发现了隐藏的问题，但很多时候，review 可能没有太多发现。所以，它是不稳定的。

上述的流程还缺乏对文档的约束 —— 很多语言，比如 rust，会在 linter 里提供对文档的检查：任何外部接口（pub）都需要要有文档描述。但这还远远不够：文档需要足够的深思熟虑，而不是随手应付的一两句话；当代码发生改变的时候，文档也需要跟着改变。而这往往是最困难的，需要开发者强大的自律。很多时候，过期文档带来的问题可能比没有文档还要大。

正因为人的因素在软件开发的各个环节中如此重要，为了减少不必要的技术债的产生，最好的方法是不断招募足够优秀的人才，进行合适的培训，并且给予他们最大的上下文来处理要处理的问题；同时，不断优化和自动化开发流程，使得每一次新的 commit，引入的熵尽可能少。

以上。你也可以看我四年前的文章：技术债：the good, the bad and the ugly。