警惕技术债务：你所不知道的风险与威胁

原创 leehomwu 腾讯技术

本文作者：leehomwu、腾讯IEG后台开发专家

1. 基本认知

1.1 技术债务的含义

所谓技术债务，通俗地讲，其实就是那些技术上没做好的事情，会逐渐体现为长期的成本。

如果把视野再拔高一点，其实不单单是技术有债务的问题，业务发展带来各种各样的债务，例如团队管理、项目管理、知识管理等，其实都可能形成债务。

关于技术债务准确的定义与分类，因为不影响核心的思考，这里不做展开。

1.2 技术债务无法消除

技术债务其实无法彻底消除的，只要业务在持续运转，就一定会产生债务，重点是控制债务的规模，使其受控即可。

2. 典型成因

从不同的维度看，技术债务的成因会有各种各样的类别。这里我们仅从研发团队的内外视角出发，可以分成外因和内因两大类。

2.1 外因

技术发展：由于技术的发展，原先采用的技术已经落后业界，体现为落后于时代的生产力，研发效能落后于竞争对手。
业务发展：由于业务的发展，原先采用的技术已经无法适应业务，体现为业务受限，或研发效率、质量产生下滑。
团队变动：由于组织结构调整，遗留下来的祖传老业务，若不能舍弃，在反复交接后导致维护越来越困难。

2.2 内因

团队管理：急功近利的文化，习惯性地将长期利益让位于短期利益，过度追求短期交付效率。团队人员的选、育、用、留不当，人才培养跟不上，体现为团队成员的能力不足（没招到 / 没留住 / 没培养出合适的人才，导致团队能力实质上无法匹配所需解决的问题）。

唯快不破的迷思

基础薄弱：团队所采用的基础设施落后，没有建设好统一的技术栈底座（基础库、框架、中间件等）。
标准缺失：团队没有根据最佳实践，持续建设好标准规范并遵循。

3. 应对的方法论

3.1 以专业做事为纲

这里想换个自顶而下的视角，不盯着债务本身。不单纯地为解决技术债而解决技术债，而是本身就是按照最专业最科学的方式来做事情，这样自然结果之一就会是技术债规模可控。

3.2 专业地做事

a. 做什么

有宏观战略思考，目标导向，不要忙于战术而不自知，避免形式主义，不要混淆方法手段和目标，不要使用伪方法论。
需要有洞察力，对业务、技术、组织架构、组织能力进行顶层思考，做 zero-based thinking。

缘木求鱼

b. 怎么做

按时间维度展开，大致可分为以下环节：

背景与问题分析：按照 MECE 准则进行问题拆解。
明确专业领域：如果有短板，需要补齐学习相关的知识，避免成为 “民科”。例如想做增长，那起码要先了解下 “增长黑客”。
业界解决方案：参考对标业界成熟的解决方案，看看是否和我们的问题相匹配，有些时候直接采用即可（例如想做单测，可能直接引入 gtest 要比从头自己做要更合适）。
自己的方案设计：在充分了解专业领域以及业界方案之后，结合第一性原理做思考，设计自己的方案，明确创新点、差异点。
排期与计划执行：做项目管理，从时空两方面对工作进行拆解，可以分多个迭代，可以分多个模块。评估内外部资源投入，控制资源的投入规模与节奏，考虑组织调度资源的方式，例如组织架构是否需要调整、是否需要招聘借调人力等。（有时候这点要提前考虑，如果资源真的有硬限制，会影响方案选型，甚至会影响是否要做的战略决策。）
度量与结果对比：要有适当的度量方式，能通过数据来说明问题解决的效果。（有时候这点也要提前考虑，以免说服力不足导致无法推进）
展望规划：看得更长远一些，适当考虑未来的发展。
总结复盘：讨论、沉淀，内化为团队的方法论和能力（例如完善最佳实践，完善代码库、基础组件等）。

c. 专业化习惯

目标导向：反复自省长短期目标是什么，并动态观察路径、工具、方法、资源（人 / 财 / 物 / 关系）、时机节奏等。
复杂问题分而治之：时间上分迭代，空间上分模块。
标准化：有章可循，沉淀形成团队的规范合集。
范式化：对于很多重复的事情范式化，形成最佳实践，最好进一步固化下来，沉淀为模板、框架、库、组件、工具等。
工具化：通过工具化、自动化来提升生产效率（例如 git、codecc 代码扫描、tapd、iwiki、流水线、代码生成等）。
算法化、系统化：通过技术角度来解决问题（例如人工配置变为基于画像的智能决策）。
迭代思维：任务分期拆分迭代，小步快跑，闭环复盘，持续自省。
灰度：渐进过渡，平滑演进。
调研：市场调研，用户调研。
ROI：考虑成本收益与风险。
知行合一：实践 - 理论 - 实践，螺旋式结构。

关于“专业地做事”，从实际情况来说：

对于有些团队而言，业务都不稳定，也没有找到稳定的收入来源，大谈技术债的治理注定是空谈。也正是考虑到这点，笔者在前文讲应对技术债的方法论时，并没有直接针对技术债本身来讲，希望那些因为眼前的苟且而选择践行“快、糙、猛”的团队，也至少可以采用更专业的姿势。

如果从发现并度量问题，到解决问题，再到反思避免问题的典型问题解决步骤来讲，专业地做事是利于事前 “避免问题” 的，因为往往领域内的专家早就思考总结过了，可以避免团队自己去踩坑再反思。如果债务一旦产生后就难以专门腾出人力来收拾，那是不是尽量参考专业领域内专业的方式来做事，起码让债务产生的慢一些、小一些。

4. 一些具体案例与经验

上文中对专业化做事的讨论，并没有明确针对技术债务，略有偏离文章主题的嫌疑。现在让我们把视线拉回来，再聚焦到技术债本身上来。

以笔者所在的《欢乐斗地主》项目为例，它是一个运营了十几年的老项目，不但有技术债，而且有些债务的历史可谓相当悠久。下面就列举一些我们在应对技术债务时的一些案例和经验。

4.1 一些案例

C++ 的后端研发框架有三套，且基础库不统一。

不统一的冗余基础库

标准规范缺失，编译构建、代码风格、配置管理、日志打印、单元测试、错误处理等都没有在早期形成统一的规范。
新技术引入的同时，未能消除旧技术，导致系统内部更加复杂，且不统一。（例如有两套协程开发框架，立新未破旧）
采用封闭的技术栈时，造过不少轮子，但又没持续造好。（例如早年连 STL 都不用，且没有建设好自己的基础库）

4.2 一些经验感悟

要持续专业地做事（参考 3.2 ），周期性地审视系统，涵盖研发管线的所有环节。

研发管线的各个环节

团队文化层面，需要形成自顶而下的统一认知，重视技术事务，在团队的正负向激励方面也予以配合，鼓励那些主动清理债务的员工。
团队管理层面，从能力和意愿角度识别员工，鼓励学习，为大家赋能，同时淘汰价值观不匹配的员工。从以人为本的角度讲，只要员工素质好了，技术债也就自然受控。
组织架构上可以设立技术中心、公共组之类的，主要是可以明确权责，方便长期持续性地维护好基础技术栈。如果仅仅是一些平行的业务研发小组，最后就会缺乏统一的质量把关控制，也没有稳定的人力投入。
项目管理层面，采用迭代运作，迭代中除了业务需求，也可以安排技术需求（但很难固定一个人力的百分比）。单个具体需求的评估中，需要包含有设计、文档、自测等工作的时间。
大的技术专项（如技术栈演进），需要自顶而下驱动，并注意做好各个角色之间的沟通。
当老的系统确实积重难返，改好的成本甚至高于重写，此时可以跳出现有系统去思考，考虑立新以破旧，另起炉灶采用更先进更合适的技术。但一定要考虑好如何平滑过渡，要当心新已立而旧难破的情况，同时也要评估好风险，从性能、安全、稳定性、扩展性等各方面评估新技术。例如：欢乐游戏的云原生技术栈演进。
持续沉淀最佳实践，形成标准、规范，并最好沉淀为模板、框架、库、组件、工具等。
适当采用开源开放的技术栈，通常比自己造轮子相对来讲会更加与时俱进，被技术发展淘汰的风险可能小一些。
从笔者个人过往经验来看，统一性（识别共性问题并采用统一的解决方案）、扩展性（功能和性能都方便扩展）、可维护性（不要搞黑科技，不要看复杂的手册才能维护），会是相对重要的几点系统非功能性需求。
充分利用好故障复盘的机会，推动相关技术债的偿还。