谈谈技术债（三）

　　来自：DevOps探路者

　　3、技术债的特点、要素和类型

　　在这个章节里我们来了解一下技术债的特点、要素和类型。我要先问一个问题：为什么要将软件工程中的这类妥协叫做“债”问题能够帮助我们更深入理解技术债。

　　技术债的英文是Technical debt，注意这里使用的是debt，意为借款、账单，而不是贷款这个单词loan。Debt这个词用的非常精当，准确的将技术债为与简单的货币出借与归还进行类比，而不是更复杂的贷款产品以及金融衍生品，这样既利于大家建立对技术债的直观印象，又不会将技术债的概念复杂化。这是因为大多数人不具备专业的金融业务知识，对于债的理解比较简单，仅限于欠钱没还，略进一步可能还会类比为个人信贷、消费信贷、京东白条或者花呗之类的具体产品，所以如果严格从法学、经济学上“债”的意义上去对比研究，对于解释技术债没有什么帮助。

　　debt

　　啰嗦了这么多，我们进入正题。

　　技术债无所谓好坏，它实际上是在特定情况下所做的一种选择，甚至某种程度上来说，在做选择的时刻，技术债反而是能被最多人所接受、多方利益达成相对平衡的一种全日制最佳选择，如果不举债，你甚至无法经营下去。

　　3.1、技术债的特点

　　而既然是选择，那必然有其优缺点，为了方便理解，这里通过将技术债和货币债进行映射，来解释其优缺点。

　　借款和技术债的区别

　　通过这张表格，我们可以看到，技术债这种选择，在注意规避缺点的前提下，是能够发挥出积极作用的，这也就解释了为什么人们会选择技术债这种解决方案。

　　3.2、技术债的要素

　　然而选择技术债，不能盲目选择，特定情况要做特定分析，选择技术债时，要对其要素进行系统思考，判断是否能够让收益覆盖风险和成本。技术债的要素如下，老规矩，还是和货币债进行对比展示：

　　技术债要素

　　3.3、技术债的类型

　　根据导致技术债的原因和对技术债不同要素的侧重，技术债大概可以分成文档债、设计债、代码债、管理债、战略债五种。

　　3.3.1文档债

　　1.需求分析债：一种表现为需求不清晰，缺少需求必要性的上下文描述，既不能准确聚焦业务痛点，也不能为开发人员人员提供清晰的指导，同时不能提供制定开发计划的优先级参考；一种表现为需求的随意性，产品人员不考虑开发计划的严肃性，随意增减需求、调整优先级。

　　2.开发文档债：一种表现是缺少代码规范、接口规范、版本规范、数据规范等技术文档，一种表现是开发文档缺少更新维护，初期有文档，后续文档不随开发迭代而更新，文档的参考价值大幅降低或提供错误的指引。

　　3.测试文档债：主要表现为缺少必要的测试方案、计划、案例支持，测试缺少规划，覆盖不充分，无法有效暴露研发质量问题。

　　3.3.2设计债

　　设计债，指在项目/产品规划阶段，对业务的发展估计不足，设计方案前瞻性和可扩展性不足，导致软件高耦合、低内聚，后续研发成本高，扩展难度大。

　　3.3.3代码债

　　代码债，指一切会导致代码阅读、编写、修改、重构成本提高的问题，包括编码债、业务债。

　　1.编码债：比如代码命名不规范、复杂度过高、可读性差、耦合度高、垃圾代码过多等。

　　2.业务债：也可叫做“业务实现债”，通常表现为，为了快速实现业务功能，减少开发工作量，在业务功能实现时不深入理解业务逻辑，采取投机取巧的方案，为后续功能开发带来各种不良影响，比如硬代码，数据库改数等。

　　3.3.4管理债

　　管理债，指在项目/产品研发过程中，给效率、成本带来负面效果的管理措施，主要包括工期债、人员债、协同债、战略债、成本债。

　　1.工期债：出于抢夺研发资源、占据版本优势、抢占市场、打压竞争对手、赶政策窗口等等目标，为研发工作制定非常紧张的工期，从而一定程度上放弃了对质量和可持续发展的要求。

　　2.人员债：人员结构不合理、关键岗位覆盖不足、流动性大、技能栈不匹配等导致的一些类研发问题。

　　3.协同债：高协同工作中未对工作目标、方法、进度、资源等要求达成一致，导致工作中反复沟通，不断等待，工作全是断点，没有节奏感。

　　4.成本债：为了解决研发投入不足而从采取各种压缩成本策略，导致的交付需求数量、质量偏差。

　　3.3.5战略债

　　战略债，指因为企业战略目标错误，战略落地路径不清晰，执行策略过于追求赚快钱和短期业务/功能亮点，缺少长线战略和长期执行的战略定性，导致结构性技术债。