简直所有的互联网公司都会遇到技术债。
在业务倒退到某个阶段时，肯定会暴发。
对于技术债。
倡议大家不要急于还债。
欠债还钱理所当然，但不是所有的债都要还。
能够选着与技术债共存，它能够带来很多益处。
有形的技术债
1、策略的负债
企业在疾速回升的过程中，技术也随之晋升。
在撑持业务疾速演进，我的项目需要、公司摸索倒退的不确定性。
技术设计很难精确把控系统的范畴，导致软件设计缺点、过于设计。
2、能力参差不齐
技术人员的能力，就像有钱的人，考究吃得好不好、健不衰弱。
而没钱的人考究能不能吃饱、有没有吃得一样。
对于低端的技术开发来说，基本不考究什么负债不负债，能实现也算不错了。
用网络上的一句话来说：我都吃泡面了我还在乎健不衰弱。
同时，在设计和构建零碎时，有意无意的衡量。
没有足够业余的技术规范，放弃代码衰弱。
使我的项目不足洁净的代码、文档和最佳实施方案。
技术在横蛮的成长，研发过程没有达到标准化。
3、产业技术迭代降级
技术在疾速的迭代，产业技术的演变，几年前的完满解决方案，当初不完满了。
同时，紧跟技术的迭代，反而影响零碎速率、平安和稳固，引发反噬。
这些都会产生有形的技术债。
共存和还债的博弈
技术债存在踊跃和负面共存景象。
1、举债经营
技术有杠杆，加杠杆，有可能带来高的投资回报率。
无限工夫内将精力用到最关注的中央。
尤其是新的产品和性能未能证实其价值的时候，用软件日后的空间换取当初倒退的工夫。
从这个意义上讲，MVP 不仅仅实用于守业公司，也实用于任何大小的公司。
2、消极方面
对于技术债，很多管理者为之恐怖，其实这时管理者应该放弃平常心。
存在技术债也阐明我的项目在倒退，团队在提高。
除了能发现债的存在，还要适时「还债」，作为管理者要有这种前瞻性。
以后高频应用的我的项目，影响到了组织倒退，这类是急需偿还的，这类技术债不还，容易产生「技术破产」，后期所有的工作都徒劳，所有代码必须「齐全重写」。
对于这类技术债和现实生活中的债权一样，如果当初承当，那么明天失去更多，有价值的货色，并在一段时间内偿还。
技术债将给组织带来长期的胜利，从而产生策略杠杆。
对于消极方面，管理者应具备强烈的「还债」意识，为将来更多思考，缩小将来欠账，对团队和我的项目都有很好的后果。
钻研它、看透它
技术债的均衡，零碎是有推陈出新的有机体。
软件也须要推陈出新，这意味着新的代码一直退出，旧的代码也要一直删除。
生物体里细胞坏了会从新造，组织死了会从新生成，放弃技术债动静的均衡。
不要让技术债成为一场指摘游戏。
技术债的争执充斥指摘，我见过一些管理者这么说：
“如果你一开始就提出一个更好的解决方案，咱们也不会呈现当初这种状况。”
这种争议毫无意义，没有什么是完满的。
咱们都是人，时移世易万物变迁。
咱们能做的，便是从谬误中吸取教训，利用良好的实际，尽可能地分明所有的决策的利弊衡量。
1、对外
建设良好的对外沟通渠道。
时刻把握软件应用状况，对遇见的问题做好记录，并复盘剖析，这是发现技术债最无效的形式。
2、对上
对上只有一点，确保你和 CEO 信息统一。
3、对内
CodeReview。
CodeReview 进步技术人员本身能力。
不同阶段的技术人员能够互相学习，审查他人的代码，可能发现问题，同时也能学到更多的常识。
进步代码标准、技术文档，积淀出一套属于团队的代码品质监管零碎。
技术培训。
大部分程序员学习能力很强，部门外部培训还是很必要的。
一方面晋升授课人的能力，另一方面扩充听课人的知识面。
培训从代码标准、熟悉业务、编写文档的思路开始进行。
无意的决策。
联合以后公司和团队现状，趁势在非将来和将来两种形式选型。
在躲避技术债的同时，老本思考对公司影响更大。
主人翁的意识。
管理者在分工时，要进步本身和团队人员的主人翁意识。
要求团队针对产品提出的需要，进行细节确认，通过某些路径，让需要更清晰。
研发过程中，能够采纳流程图，将所有流程梳理一遍。
将技术难度、需要含糊做好记录，并及时提出来探讨。
如果有一致的中央肯定要及时沟通，达成共识。
最初的话
1、放弃技术方面的衰弱是技术治理团队的工作。
2、技术债就是资本家和工程师之间的矛盾，工程师是为资本家做服务的所以技术债永远存在，要与技术债共存。
3、给偿还技术债的技术人员更多地激励和展示，因为在偿还过程中很难短时间看到后果。
关注公众号：「CTO 说」，理解更多技术治理常识，伴技术治理的你一起成长