• 技术发展

• 业务发展

• 团队变动

• 团队管理

• 基础薄弱

  
  

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

• 标准缺失

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

   3.1 以专业做事为纲

   3.2 专业地做事

• 做什么

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

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

• 怎么做

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

• 专业化习惯

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

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

   4.1 一些案例

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

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

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

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

   4.2 一些经验感悟

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

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

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

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

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

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

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

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

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

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

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

   5.2 放任技术债会破坏团队

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

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

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

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

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

没时间，没人力？

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

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

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

   5.4 要因地制宜

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

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

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

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

   5.5 再谈专业地做事

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

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

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

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

写代码不规范除了会积累技术债，还会带来什么样的问题？你还有哪些减少技术债的经验？欢迎在评论区分享讨论。我们将选取1则最有意义的分享，送出腾讯云开发者-手腕垫1个（见下图）。7月17日中午12点开奖。