技术负债与软件质量

技术负债，增加新功能所需的额外成本。

在平时增加新功能的同时，已经引入了复杂性，这个复杂性的成本就是一种债务，需要以后偿还——不会不还，只是时候未到而已。

技术负债的存在是导致软件质量下降的重要原因。软件质量下降以后，系统难以维护和修复，就会导致项目失败或者必须重写代码。

软件质量不同于其他商品质量。软件质量不是直接被软件系统的使用者所感知的，不过他们会发现，随着时间推移，自己的产品交付过程越来越长了。

软件质量问题不是直接面向用户，而是面向软件的开发团队。

正是由于软件质量不是最终用户所能感知的，导致行业内对软件质量没有过多重视——客户都没有提出改进要求，那么一切为客户服务的软件公司自然就没有动力去提升软件质量。

然而，软件并不是质量越高，成本就会越高。

降低技术负债意味着软件质量提高，软件质量越高，修改拓展起来就越方便。

如何降低技术负债

一个适度问题。

首先，代码越多，复杂性越高，技术负债肯定越高，那么就需要惜墨如金。

适度是在过度和不足中探索平衡的结果。代码适度的一个衡量标准是单一职责原则，即每个函数或类只能有一个职责，它就是为了这个职责而存在的，而不是为了多快好省，将多种功能放在一个类或函数中。

D RY（不要重复自己）原则。对这个原则的共同理解是代码不应该重复，如果两段代码表示的是同一个职责，那么合并它们。但是，这种抽象合并会导致共享内核或共享库，最终造成代码各处对共享库或内核的依赖，这就很自然地引入了不必要的、偶然的复杂性——一旦共享库发生修改，牵一动百的事情就可能发生。这也是使用框架或库包的局限所在，框架和库包确实提高了生产效率，但是也限制了项目代码，因为代码会依赖于它。

很多时候，重复的代码可能会带来相当大的优势，重复能拖延决策，这是软件开发的黄金。这样，延迟到适当时机后从多个专业化角度重构，这比从单个方法层面进行抽象的重构要容易数倍。预先应用DRY，将导致构建领域中不存在的抽象，虽然这是体现程序员创造性的地方，但是笔者不推荐无中生有的创造，因为当时你的视角可能存在偏见。将一些函数合并在一起的原因常常是，这些函数虽然位于在不同的类中，但是功能看起来是相同的，但随着时间推移，当你的注意力从函数功能本身转移到它所在的上下文时，又会发现它们还是有些不同的。

只有当复杂性变得难以管理或业务模型有明确要求时，才应该对抽象进行重构，提前执行此类操作只会损害代码并引入大量意外的复杂性。

降低技术负债的另一个办法是引入架构元素，例如编码前通过对业务模型的头脑风暴，缩小领域专家和程序员之间的业务水平落差；编码完成后增加单元测试和集成测试，尽可能将测试、发布和运维自动化，实现DevOps哲学化管理。改善质量不是一个人的责任，而是每个人的责任。精益是丰田应用于它们如何在整个组织中制造汽车的理念，短短几年内丰田的快速发展证明了这种哲学方法的有效性。

当然值得注意的是，不要被打着提高软件质量的旗帜欺骗，在增加了复杂性的同时也阻碍了软件质量的提高。编程是人类思维的延展，保证程序员足够的休息时间和愉快的心情，才是提高软件质量的重要因素。没有良好的精力和敏捷的思维，头脑风暴会议只能成为一场瞌睡大会。