为什么还技术债的人总是我?

腾小云导读

不管你的研发团队有多么丰富的经验，还是拥有何等体量的代码，或者是新技术的运用，总会产生一定程度的技术债。本篇作者进入腾讯十余年，总结分析了技术债生成的原因并结合个人项目经历分享技术债务应对方法。欢迎围观～

1 基本认知

1.1 技术债务的含义

1.2 技术债务无法消除

2 典型成因

2.1 外因

2.2 内因

3 应对的方法论

3.1 以专业做事为纲

3.2 专业地做事

4 一些具体案例与经验

4.1 一些案例

4.2 一些经验感悟

5 写在最后

5.1 技术债治理需要有价值观的坚守

5.2 放任技术债会破坏团队

5.3 要保持对技术事务的资源投入 5.4 要因地制宜

5.5 再谈专业地做事

01、基本认知

1.1 技术债务的含义

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

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

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

1.2 技术债务无法消除

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

02、典型成因

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

2.1 外因

技术发展

由于技术的发展，原先采用的技术已经落后业界，体现为落后于时代的生产力，研发效能落后于竞争对手。

业务发展

由于业务的发展，原先采用的技术已经无法适应业务，体现为业务受限，或研发效率、质量产生下滑。

团队变动

由于组织结构调整，遗留下来的祖传老业务，若不能舍弃，在反复交接后导致维护越来越困难。

2.2 内因

团队管理

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

基础薄弱

团队所采用的基础设施落后，没有建设好统一的技术栈底座（基础库、框架、中间件等）。

标准缺失

团队没有根据最佳实践，持续建设好标准规范并遵循。

03、应对的方法论

3.1 以专业做事为纲

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

3.2 专业地做事

做什么

有宏观战略思考，目标导向，不要忙于战术而不自知，避免形式主义，不要混淆方法手段和目标，不要使用伪方法论。

需要有洞察力，对业务、技术、组织架构、组织能力进行顶层思考，做 zero-based thinking。

怎么做

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

背景与问题分析：按照 MECE 准则进行问题拆解，注意不要急着讨论方案，要先明确问题及其边界。现在有一种广泛的观点，“带着自己的思考建议来讨论”，有思考自然是好事，但不必急于介入到解决方案的讨论，否则可能会把大家的节奏带偏，在不明确是否要做的时候，就耗费大量时间讨论如何去做。因此对于一些很重要的问题，要充分地分析清楚问题，确定所要达到的目标，然后再去讨论解决方案。明确专业领域：如果有短板，需要补齐学习相关的知识，避免成为 “民科”。例如想做增长，那起码要先了解下 “增长黑客”。业界解决方案：参考对标业界成熟的解决方案，看看是否和我们的问题相匹配，有些时候直接采用即可。（例如想做单测，可能直接引入 gtest 要比从头自己做要更合适）自己的方案设计：在充分了解专业领域以及业界方案之后，结合第一性原理做思考，设计自己的方案，明确创新点、差异点。在方案选型时，用开放性的视角，使用多元的价值观，有时候不一定非此即彼，而是两者的融合，兼而有之。方案本身要关注到实际落地，规划好系统的边界和接口，重视统一性（标准化）、可扩展性和易用性，可以针对方案做全流程的投产推演。排期与计划执行：做项目管理，从时空两方面对工作进行拆解，可以分多个迭代，可以分多个模块。评估内外部资源投入，控制资源的投入规模与节奏，考虑组织调度资源的方式，例如组织架构是否需要调整、是否需要招聘借调人力等。（有时候这点要提前考虑，如果资源真的有硬限制，会影响方案选型，甚至会影响是否要做的战略决策）度量与结果对比：要有适当的度量方式，能通过数据来说明问题解决的效果。（有时候这点也要提前考虑，以免说服力不足导致无法推进）展望规划：看的更长远一些，适当考虑未来的发展。总结复盘：讨论、沉淀，内化为团队的方法论和能力。（例如完善最佳实践，完善代码库、基础组件等）

专业化习惯

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

04、应对的方法论

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

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

4.1 一些案例

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

标准规范缺失，编译构建、代码风格、配置管理、日志打印、单元测试、错误处理等都没有在早期形成统一的规范。

新技术引入的同时，未能消除旧技术，导致系统内部更加复杂，且不统一。（例如有两套协程开发框架，立新未破旧）

采用封闭的技术栈时，造过不少轮子，但又没持续造好。（例如早年连 STL 都不用，且没有建设好自己的基础库）

4.2 一些经验感悟

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

团队文化层面，需要形成自顶而下的统一认知，重视技术事务，在团队的正负向激励方面也予以配合，鼓励那些主动清理债务的员工。

团队管理层面，从能力和意愿角度识别员工，鼓励学习，为大家赋能，同时淘汰价值观不匹配的员工。从以人为本的角度讲，只要员工素质好了，技术债也就自然受控。

组织架构上可以设立技术中心、公共组之类的，主要是可以明确权责，方便长期持续性地维护好基础技术栈。如果仅仅是一些平行的业务研发小组，最后就会缺乏统一的质量把关控制，也没有稳定的人力投入。

项目管理层面，采用迭代运作，迭代中除了业务需求，也可以安排技术需求（但很难固定一个人力的百分比）。单个具体需求的评估中，需要包含有设计、文档、自测等工作的时间。

大的技术专项（如技术栈演进），需要自顶而下驱动，并注意做好各个角色之间的沟通。

当老的系统确实积重难返，改好的成本甚至高于重写，此时可以跳出现有系统去思考，考虑立新以破旧，另起炉灶采用更先进更合适的技术。但一定要考虑好如何平滑过渡，要当心新已立而旧难破的情况，同时也要评估好风险，从性能、安全、稳定性、扩展性等各方面评估新技术。例如：欢乐游戏的云原生技术栈演进。

持续沉淀最佳实践，形成标准、规范，并最好沉淀为模板、框架、库、组件、工具等。

适当采用开源开放的技术栈，通常比自己造轮子相对来讲会更加与时俱进，被技术发展淘汰的风险可能小一些。

从笔者个人过往经验来看，统一性（识别共性问题并采用统一的解决方案）、扩展性（功能和性能都方便扩展）、可维护性（不要搞黑科技，不要看复杂的手册才能维护），会是相对重要的几点系统非功能性需求。

充分利用好故障复盘的机会，推动相关技术债的偿还。

05、写在最后

5.1 技术债治理需要有价值观的坚守

对技术债的治理是一项价值投资，要做时间的朋友，如果没有价值观上的坚守，是断然坚持不下去的：

这个需求是急着要上线的，而且是老板重点关注的！看，东西不是也做出来了么？这么跑起来好像也没啥毛病啊？都已经好几年如此了，何必再去动呢？

在顶住压力，努力促成了团队对技术事务的正确认知后，一定还要牢记老祖宗的话：苟日新，日日新，又日新！

5.2 放任技术债会破坏团队

技术债的累积是一种慢性病，它不会一下子要命，但是一旦累积到一定程度，就会病入膏肓，到那时想找特效药？对不起，这个真没有！

当技术债累积到一定程度后，会限制业务的发展，研发效率、研发质量都会下滑。但是笔者这里更想强调的，是其对人的影响。

毕竟，谁会开开心心地长期在地雷阵、沼泽地里前行呢，那些技术负债过重的团队，必然口碑崩坏，也留不住优秀人才，而一旦人才都跑了，想必业务早晚也凉凉。

那么债务累积严重的程度是否有办法度量呢，很困难，如果是为了度量而度量，其实就会落入形式主义的误区！或许可以换个角度，尝试对研发效能做度量，一旦效能显著下降，就说明技术债务可能变多了。

5.3 要保持对技术事务的资源投入

没时间，没人力？

这恐怕是用的最多的理由，笔者个人自己的看法是 ... 无论是生活中，还是工作中，其实相当大比例的时间，一定是被浪费掉的。

有多少事情是战术上的勤奋使然？有多少事情是真正能产生价值的？尝试性的临时性的事情占比合理么？做了那么多事情，业务会不会还是原地踏步甚至下滑，有事后总结复盘过么？

任何团队都可以复盘，如果复盘得到的答案，是真的忙得其所，很有价值，那恭喜恭喜！既然那么有价值，老板肯定也看得见，那是不是可以申请到更多的资源，这样团队依然可以适当保持对技术事务的投入。

不要总是将长期利益，让位于短期利益，正确战略方向下的慢，远远好过错误方向下的快！既要有百米冲刺的速度，又要跑马拉松的距离？这绝对是很不人道的研发模式，长此以往，且不说业务系统会出问题，但凡有点能耐的员工肯定就真 run 了！

5.4 要因地制宜

那究竟还能不能真的为赶工采用临时的次优实现呢？

假如不是跑马拉松呢，例如本就是一波流的业务，又或者是涉及生死存亡的来自某种神秘力量的需求呢？老实说，此时的快糙猛似乎也没什么不妥。因此鼓励收敛技术债，未必要遵守所有的条条框框，不能搞教条主义。

由于业务背景的千差万别，以及债务度量本身的困难性，所以没有一把标准的尺子可以衡量。技术债务的程度目前如何，技术事务的人力投入比例值定为多少，都需要持续的实践和思考。就像有 “中国特色” 的社会主义一样，业务团队都需要从实际出发，结合实践，探索有 “业务特色” 的技术债治理方案。

所以到底债务多少合适呢？这里引用技术债讨论沙龙《通过系统思考理解业务债务并有序消除》中分享的观点：

5.5 再谈专业地做事

虽然文章标题是有关技术债的思考，但其实笔者本人更想强调的反而是专业地做事这一点，挂羊头卖狗肉 ...

对于有些团队而言，业务都不稳定，也没有找到稳定的收入来源，大谈技术债的治理注定是空谈。在这种寒冬之下，做点新东西，还要盈利不错，难，很难，非常难！

也正是考虑到这点，笔者在上面讲应对技术债的方法论时，并没有直接针对技术债本身来讲，希望那些因为眼前的苟且而选择践行快糙猛的团队，也至少可以采用更专业的姿势。

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

-End-

原创作者｜吴连火