关于技术债务的总结（22.1.25）

一直以来自己心中都有一个顾虑，就是采用敏捷开发之后可能带来的技术债务。首先谈一下什么是技术债务，举个例子，我们借了别人的钱，不管多久都需要归还是吧？你拖得越久，归还的利息就越多。这个应用到软件开发中也是一样的道理。在前期的需求架构设计上面做的所有不到位的地方，往往到了后期就会需要加倍前期偿还，这个就是技术债务，今天从需求、架构、开发三个方面对技术债务进行思考。

首先说一下软件需求，在传统的软件工程里面，我们一般的都会设置独立的软件需求和分析人员，所以软件需求有面向结构大的方法，也有面向的对象的方法。不论是哪种方法，我们可以看到软件开发都需要比较完整的业务调研、需求调研，端到端的流程梳理，进而去做完整业务建模的过程。在这个业务建模中要两个重点，一个是业务对象建模，一个是业务用例分析。最终软件需求人员还要再去划分业务组件或者业务模块。但是到了Scrum敏捷研发后，实际上把需求这个职责弱化掉了。所以我们一看敏捷研发中的需求，好像就理解得很简单。就是基于流程、基于场景的分析去梳理一个个用户故事。这就是我们常说的敏捷开发中的软件需求。所以我们可以看到，当前很多不管是产品经理还是需求人员，他去做软件需求实际上把它简化了。我们一开始就会去想要实现这个场景需要做好哪一些功能，然后这些功能对应到哪些界面。但是这些都不是做软件需求的核心。当我们这么去做的时候，很可能就忽视了底层一个完整的业务模型。这样反而导致了当出现了业务流程和场景变化的时候，我们很难去应对这种变更或者是扩展。任何一个软件系统架构的可扩展性首先要求我们做到软件需求和业务建模的可扩展，其次才是架构的可扩展。比如我们做报销系统，有差旅报销、借款报销等多种报销。好的软件需求人员他首先要去做业务建模和业务抽象。因为他认为所有的报销都可以抽象出一个标准的业务模板，通过配置的方式去做。这就是是一个典型的业务建模做了抽象。最后架构和设计仅仅是基于这个业务抽象再去做一层技术层面的抽象和实现。

第二点谈一下架构。架构其实也是在scrum敏捷开发以后弱化的一个概念。因为它强调业务场景分解成具体的user story以后，完全基于用户故事，去一对一条目化去驱动，去跟踪。这个时候我们会发现，没有架构设计这么一个位置。对于一个全新的大系统，实际上并不适合采用敏捷研发的思路，还是需要按照传统思路来做。因为全新的大系统整体的架构，底层模型的完整性就相当重要了。我们一定不能按一个系统需要10个还是50个功能这样去思考和设计，因为这个时候底层模型相对来说就不完整。但是架构为什么这么重要，是因为架构如果出现问题，导致的技术债务在后期偿还的代价就相当大。就拿装修来说，有很多像水电这样的属于隐蔽工程（基装的部分），上层会有很多软装。我们会发现，当水电工程呈现问题的时候，需要做总体调整，这个时候就会感到伤筋动骨，很可能要推倒全部重来。但是如果仅仅是上层的软装出问题，很容易快速做出调整。对于架构来说也是一样的道理。就当我们的架构本身出问题的时候，底层的数据结构和模型出问题的时候，你会发现这个时候调整就相当困难。很可能需要全部推倒重来，如果本身的底层架构，数据库模型没有出现问题，我们会发现，当出现一些需求变更或者新增功能的时候，就很容易去优化和调整。所以架构层面是最容易带来技术债务的一个点。这个债务在后期很难去弥补。所以，即使我们推行敏捷开发也要注意尽量避免架构阶段引入太多技术债务。

最后谈一下开发。开发也是经常引入比较多技术债务的一个点。说简单一点就是连最基本的编码规范、开发规范和开发原则这些基本的东西都没有做好，导致后续大量的变更或者是缺陷。对于任何一个开发，不是简单去实现一个功能就完事。还需要去考虑这个功能对应的性能、可维护性、代码可读性和可扩展性，但是如果我们把这些因素都考虑进去，整个开发量就需要翻倍。任何一个开发、编码完成以后，都需要去考虑几个关键点。第一个就是整个代码对于变更是友好的。对变更友好需要理解成什么呢？首先是代码整个的可读性直接影响后续好不好做维护，好不好做变更。一个代码可读性并不代表要加多少注释，而应该是可以自解释的。小到变量常量命名可以自解释，任何的业务规则和业务逻辑的实现也是一样的道理。我们不能写一个几千行代码的函数，应该是体现出步骤和相互的依赖关系，这样的一个很清晰的逻辑结构。另外一个就是我们所写的代码尽量做到健壮性和高性能。但是这个的核心最重要的是数据结构和算法。你在实现一个功能的时候，你有没有去选择一些不合适的数据结构去解决这些问题，其次就是实现业务所选择的算法是否合理。我们可以参考类似《代码大全》、阿里编码规范等对团队开发过程进行规范，包括一些成熟的代码检查工具，安全漏洞扫描工具等提前发现代码中存在的一些问题。

所以我们不能小看了在各个技术债务的引入问题，这会直接影响的产品迭代，项目实施和公司知识沉淀等各方面的工作。