关于技术债的思考-轻识

在快速变化的互联网环境下，软件产品团队如何在质量和速度上取得平衡？如何让软件产品以最快的速度抵达用户手中，使团队得到最快速的反馈？交付质量与速度是否存在一定的平衡？如何在满足质量的前提下快速交付产品价值？这里每一个问题都是工程效能领域的经典问题？工程效能的提升涉及方方面面，今天我们只来探讨一下关于技术债在软件高效的持续交付过程当中扮演了什么样的角色，同时也深入了解下它对高效持续交付的影响和我们应该怎么面对它？

关于交付质量与速度是否存在一定平衡这个问题，在持续交付2.0这本书里，作者乔梁给出了一个肯定的答案：质量与速度根本不存在平衡，只有在产品能够承受的一定质量水准基础上，追求交付的速度才有意义。

基本概念

技术债指的是过往积累的低质量工作对当下工作进展造成损害的现象。技术债是一种软件缺陷，最有代表性的应该是程序源码中随时间累计而变得无用的过时垃圾程序代码。

技术债涉及的范围很广，可以是质量不好的代码、劣质的设计、脆弱的测试集、不恰当的决策、不稳定的构建环境、笨重的手工流程等任何因为短期利益而牺牲长期生产效率的东西。

技术债带来的影响

存在大量技术债务的系统，工程师需要花费更多的时间理解如何做出更改，同时提升了犯错误的概率。如果发现问题，则需要花费更多的时间去定位和解决它们。如果没有发现这些问题，就会遇到生产故障，以后会花更多的时间来修复它们。技术债务的积累，使任何一个微小的改动都需要花费数周的时间。

对于全新的项目，团队可以从一开始就避免技术债累计；对遗留项目，团队除了接过已经存在的技术债往往别无他选。但无论是哪种项目，如果团队不能管理好技术债，团队的效率就会逐渐下降。

论技术债的价值

技术债在技术方和业务方的交流讨论中是一个很好的隐喻。业务方尝尝认识不到持续拖欠技术债的成本，而技术方则尝尝意识不到（短期技术债能带来的）业务价值。在某些情况下，主动选择拖欠技术债是一个合理的业务决策，有时则不是。引入债务的概念使得业务方和技术方可以共享彼此的一些顾虑，促使团队就是否选择欠债、何时欠债，以及何时需要还债、以何种方式进行还债等问题做出更好的决策。

映射到我们日常工作中，其实就是产品经理或者业务方只关注需求的上线时间，到研发环节基本上都是到排期，同时为了满足时效性还需要牺牲一些质量，欠下的质量债务和损失优雅的设计换来上线时间。业务方即使意识到对研发是有侵害的，但由于屁股决定脑袋理论，也不会去过多的在意。

细化技术债分类

技术债类型	类型特征	类型描述	推荐应对方式
有意欠下的债	短期的	战术性或战略性的欠债。如为了准时部署一次对时间很敏感的上线。	如果有正当的业务必要性可以欠债，但需要尽快还清。
长期的	战略性的欠债。如一个这样的决策：仅支持一个平台，而非从一开始就支持多平台进行设计和构建。	如有必要，可以欠债；但需要明确还债的触发条件，通常是一期先支持一个平台，二期扩展还债。
无意欠下的债	得过且过	由于不好的软件开发实践而欠下的债。这类技术债会拖慢当下和未来的进度，应当避免。	一开始就应该通过高质量的工作实践避免这类技术债。
难以避免	由于软件开发易错的本质（设计方案没有按我们预期发挥作用或者新版平台使得我们设计的某些方面严重失效了）而偶然欠下的债。	这类技术债其实无法避免，这是由软件开发的本质所决定的。监控这些债务带来的影响，当债的『利息』变得过高时就需要还债了。通常也是重构的触发条件。
遗留技术债		新团队从已有代码库中继承下来的技术债。	做好还债计划，不要让”历史问题"成为不还债的借口。

我们其实还可以把上面的各种类型技术债按照出现的频率进行一个等级划分，并制定针对不同等级的应对原则：

以下摘自左耳朵耗子的一遍文章，我们借鉴其第八原则：

https://coolshell.cn/articles/21672.html#原则八：不要迁就老旧系统的技术债务

我发现很多公司都很非常大的技术债务，这些债务具体表现如下：

使用老旧的技术。比如，使用HTTP1.0， Java 1.6，Websphere，ESB，基于 socket的通讯协议，过时的模型……等等
不合理的设计。比如，在 gateway 中写大量的业务逻辑，单体架构，数据和业务逻辑深度耦合，错误的系统架构（把缓存当数据库，用消息队列同步数据）……等等
缺少配套设施。比如，没有自动化测试，没有好的软件文档，没有质量好的代码，没有标准和规范……等等

来找我寻求技术帮助的人都有各种各样的问题。我都会对他们苦口婆心地说同样的一句话——“如果你是来找我 case-by-case 解决问题，我兴趣不大，因为，你们千万不要寄希望能够很简单的把一辆夏利车改成一辆法拉利跑车，或是把一栋地基没打好的歪楼搞正。以前欠下的技术债，都得要还，没打好的地基要重新打，没建配套设施都要建。这些基础设施如果不按照正确科学的方式建立的话，你是不可能有一个好的的系统，我也没办法帮你 case-by-case 的解决问题……”，一开始，他们都会对我说，没问题，我们就是要还债，但是，最后发现要还的债真多，有点承受不了，就开始现原形了。

他们开始为自己的“欠的技术债”找各种合理化的理由——给你解释各种各样的历史原因和不得以而为之的理由。谈着谈着，让我有一种感觉——他们希望得到一种什么都不改什么都不付出的方式就可以进步的心态，他们宁可让新的技术 low 下来迁就于这些技术债，把新的技术滥用地乱七八糟的。有一个公司，他们的系统架构和技术选型基本都搞错了，使用错误的模型构建系统，导致整个系统的性能非常之差，也才几千万条数据，但他们想的不是还债，不是把地基和配套设施建好，而且要把楼修的更高，上更多的系统——他们觉得现有的系统挺好，性能问题的原因是他们没一个大数据平台，所以要建大数据平台……

我见过很多很多公司，包括大如 BAT 这样的公司，都会在原来的技术债上进行更多的建设，然后，技术债越来越大，利息越来越大，最终成为一个高利贷，再也还不了（我在《开发团队的效率》一文中讲过一个 WatchDog 的架构模式，一个系统烂了，不是去改这个系统，而是在旁边建一个系统来看着它，我很难理解为什么会有这样的逻辑，也许是为了要解决更多的就业……）

这里有几个原则和方法我是非常坚持的，分享给大家：

与其花大力气迁就技术债务，不如直接还技术债。是所谓的长痛不如短痛。
建设没有技术债的“新城区”，并通过“防腐层 ”的架构模型，不要让技术债侵入“新城区”。