共计 5015 个字符，预计需要花费 13 分钟才能阅读完成。
腾小云导读
不论你的研发团队有如许丰盛的教训，还是领有何等体量的代码，或者是新技术的使用，总会产生肯定水平的技术债。本篇作者进入腾讯十余年，总结剖析了技术债生成的起因并联合集体我的项目经验分享技术债权应答办法。欢送围观～
目录
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-
原创作者|吴连火
写代码不标准除了会积攒技术债，还会带来什么样的问题？你还有哪些缩小技术债的教训？欢送在腾讯云开发者公众号评论区分享探讨。咱们将选取 1 则最有意义的分享，送出腾讯云开发者 - 手段垫 1 个（见下图）。7 月 17 日中午 12 点开奖。