当了15年IT民工，待过几家公司，做过不少项目，捅过一些篓子，也掉进过好多个坑，今天与大家分享一些对于技术债的看法。
大家都知道，我呢，是一个“长情”的人——不知道的话可以用这个关键词加上我的名字搜索一下……。
也就是在一个公司待的年头会长一些，也就有机会用更长的时间视角看待一些系统、项目的发展变化。
对于一些技术债务的产生和影响，以及后续的清偿就有更多的切身体会，最近也比较关注，正好跟大家交流交流。
第一部分：技术债是如何形成的
技术债务是由Ward Cunningham在1992年创造的一个比喻，被定义为当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。这里有两个关键词，比喻和技术决策，还有两个词不那么关键，但也不能忽视，有意和无意。
我非常喜欢这个比喻，因为从技术管理角度，技术债务面对的也是各种成本和风险的问题，特别直截了当。
既然是比喻，总有不是太一致的地方，这是我们需要注意的，不能真的就当成欠钱那么简单，这一点我们后面会提到。
最上面这张图比较直观的体现了技术债的一种定义，是负面的，消极的，不可见的。
IT领域的理念大师Martin Fowler对技术债也进行过思考和分类，但过多的引申概念可能会干扰思维，在这里就不说了，大家感兴趣可以去看。
之所以说这个比喻非常好非常妙非常呱呱叫呢，是因为技术已经成为许多企业的核心资产。
尤其对于一些互联网公司，或者电信公司、金融企业、税务部门（老三样），业务运行重度依赖IT系统。
对于这样信息化程度很高或者说IT系统就是业务生产服务系统的组织来说，线上的系统、代码库里的源码、数据库里的数据、甚至包括技术人员，才是最重的资产。
很多互联网创业公司，列出预算，技术人员的薪酬才是最大的开销，又偏偏是不能省的（能省早砍了），再轻的公司都得付出这个成本。
而一个企业运转起来，积累的数据（包括用户数据），沉淀的代码和文档，不断升级的功能，熟悉业务的技术人员，这些都是业务更好发展的基础。
这样的公司，本就是运行在IT系统之上，一旦核心系统挂了，数据丢了，业务立刻停摆，直接带来损失。
所以说技术部门已经不是支持部门、成本中心，是需要投资带来收益的生产部门。
既然技术是资产，那就不仅仅是正资产，还会有负资产，也就是技术债。
简单说，技术债就是那些该做但是没做的，或者说做错了的事儿。
有些债务随着时间的推移，还会产生利息，而且可能衍生更多的债务。
正确的标准是什么呢？就是在对应的发展阶段需要做的一些事情，技术体系也有发展规律，也需要建设周期。
比如一个网站或者Web应用从小到大发展起来，技术的路线图大体上是一定的，在对的时候做了对的决策，自然事半功倍，否则就是事倍功半。
大家对软件工程理论都有了解，都知道这么一句话：软件错误发现的越早改正的成本越低。
所以呢，我们就看看技术债都会怎么产生，这里会泛化一些。
比如：
1.临时方案，凑合着用，没人再关注优化改进。这方面有人会说这是MVP。
2.技术体系本身的信息化建设落后，不重视基础平台建设。
3.缺乏基本的文档和规范，导致信息缺失和失控。
4.过度设计也会引入债务。
5.技术选型未跟上行业发展潮流，未享受到技术红利，陷入竞争劣势。
6.开发代码贴膏药，不写注释，不讲究结构设计，只为实现需求功能，导致代码腐化。
7.有缺陷的设计和代码。
8.忽视数据收集和历史数据沉淀。
9.网络安全工作不到位
10.长期依赖人工进行功能测试
还有很多很多，各个层面的原因导致的债务。
第二部分：技术债有怎样的风险，如何看待技术债？
如上所述，有些技术债是我们明确知道风险的决策，因为资源、时间之类的限制，进行了取舍，舍鱼而取熊掌者也。还有一些债务是无意中造成的，我们自己都不知道，充满了不确定性。
这些债务一旦产生，就会衍生一系列问题，甚至多重叠加，出来混，总是要还的。
尤其是互联网公司，系统外部环境更为复杂，更易引爆问题。
长期欠债的最大风险是隐性成本增加，欠债是为了节省成本，一直不还会导致其他成本上升，相当于是利息。
比如一些基础的、底层的服务没有做好，导致上层的应用必须考虑更多的逻辑，难以简化。
债务就像冰山一样，沉在水面下，容易被忽视，积累到一定程度会爆发债务危机。
这就像滚雪球，滚到后来就不知道最初的小雪球是什么样子了，变成了无处下手的大雪球。
直接的风险多数是指触发故障导致损失。
比如提倡敏捷，放松质量要求，测试不到位，常在河边走哪有不湿鞋。
比如设计时未考虑面对更高业务峰值的场景，架构难以横向扩容。
比如生产环境未作隔离，导致测试环境应用干扰了正常业务。
比如测试环境与生产环境不一致，验证结果不具备参考性。
比如N年前不知道谁写的代码里有一个特殊判断，其实正常情况下是不必要的，凑巧赶上了，引发了意想不到的结果。
技术债的后果，有人整理如下，应该主要指传统的IT服务企业，可作为参考：
1.爆发点不可预期
2.交付时间延长
3.缺陷数量可观
4.开发和支持成本上升
5.产品萎缩
6.可预测性降低
7.表现越来越差
8.挫败感四处弥漫
9.客户满意度降低
我很不喜欢欠钱，大家都知道谈钱容易伤感情，而谈感情呢，容易伤钱。
所以我也很不喜欢技术债，总觉得技术债不是个好东西，看着碍眼，如鲠在喉。
但我自己也因为各方面原因，欠下过不少的债，有的一直没还上。
尤其是很多时候我们只是接手别人的工作，同时就要接手现存的债务。
完全不欠债只是一种理想状态，欠债才是常态。
欠债太多，会导致恶性循环，如果是规模较小的系统和组织，还比较容易扭转，否则一旦形成不良趋势，要刹住势头，再往回拽就很难很难了，需要极大的勇气、毅力和方法。
第三部分：技术债的清偿方式
技术债只是一种比喻，与财务领域的债务还是有区别的。比如这种债务的形式很多，又没有欠条，触发的时间点并没有明确的期限，更没有债权人，不能指望宽宏大量免除债务。
多数人在进行技术决策之后就会认为已经解决问题，造成的债务摸不着看不见很快就抛之脑后，感觉心情愉快，空气清新。
而债务是会被继承的，人在做，天在看，不是你不知道，忘了就不存在了。
这些隐藏的债务，就是一颗颗不定时的炸弹，一旦碰上，都是意外惊吓，手忙脚乱，灰头土脸。
债务爆发需要偿还，会打乱当前的工作计划，而且要付出更多的成本，有时候光弄清楚到底什么问题就要很长时间。
好在亡羊补牢，为时未晚，早发现早解决，事情多半是绕不过去的。
前人挖坑，后人填坑，碰上了别说倒霉，很多人也是在解决前人留下的债务危机中迅速成长起来的。
一般来说，就事论事解决就好，如果积累太多，千头万绪一团乱麻，那就快刀一斩，推倒重来，重构。
重构看起来像是东山再起，没有在原系统上修修补补，但一样是偿还了债务的，而且还可能引入新的债务。
在有些情况下债务的确不需要偿还，或者用很少的代价就能解决。
1.债务产生的问题在可容忍范围内，处理债务的收益不高。
2.因业务发展变化，产品生命周期结束，最终下线。
3.新技术的出现，硬件性能的提升，可以通过另外的方式缓解债务。
比如曾经有这样的例子，应用性能不行，需要优化，还在分析梳理，突然听说别的系统替换下来一台很牛的服务器，正好挪过来一上，速度飞快，问题就不再是问题了，DB换SSD也差不多。
<卖瓜时间>
比如搞SOA服务治理，Java之外还有其他语言，想HTTP调用，后来发现了DubboX。
比如定时任务散布在服务器上，缺乏统一管理，还到处都是单点隐患，发现了Elastic-job。
比如MySQL数据量大了，直接拆库，在应用里把分库逻辑写死，业务迎来快速发展期怎么办？发现了Sharding-JDBC。
</卖瓜时间>
第四部分：如何避免技术债务危机
技术债的发展需要时间，又容易被忽视，成为房间里的大象，如果积累过多，在感知上会集中式爆发。技术债的集中爆发严重情况下一样会导致体系崩溃，烂摊子不可收拾，这种时候重构跟破产重组差不多，甚至可能导致企业垮掉。
一个合格的技术管理者，要保持对技术债务的敏感度，更要适时的调配资源，解决部分技术债务，避免失控。
但也不需要过于敏感，处处小心，防微杜渐，或者优柔寡断，有的时候不做决策一样是一种决策行为，会导致债务。
每个系统都有结束历史使命的一刻，但不应该因为技术债务而垮掉，要避免爆发危机，就要对技术债务进行管理，控制在可接受水平。
最简单有效的方式，就是维护一个债务列表，类似于待完成任务列表。
一旦发现债务产生，尽快登记在案，人的记性总是靠不住的。
有了这样一个列表，管理起来方便很多，可以公开，既可以区分重要程度和优先级，还可以记录一些关联关系。
Uber的工程主管Raffi Krikorian在《架构之重构的12条军规》也专门列出了一条“管理好技术债务”，建议列出清单。
有的人建议给每个债务定义价格和利率，并进行计算，虽然更直观，但感觉比较难以估量实际价值，最终体现的还是重视程度。
如果考虑全面，可以一石N鸟，串起来一次性解决多项债务，甚至还能带来额外的收益，或者在业务需求实现中连消带打清理债务。
技术体系是为业务服务的，但不能仅凭业务需求驱动，需要分配一定比例的资源还债、优化、创新。
以上说法主要是被动式的，主动的预防也很重要，而且预防是多方面的。
1.招聘能力符合要求，踏实做事的人才，维持团队稳定，避免发生断档。
2.制定完善的项目流程规范，对设计进行评审，提高整体的质量意识。
3.对代码进行Review。
4.不同领域的技术应用通过专家小组方式进行管理。
5.对项目和故障进行复盘，及时发现问题。
6.建立完善的监控系统，对系统运行数据进行分析，关注趋势和异常。
第五部分：技术宅怎样与技术债共度一生
作为一个技术宅，我常常说自己是IT民工，这个工字呢，不管是叫工人还是攻城狮，都是跟工程学有关，对，我是个工科生。所谓工程，是要落地实现的，有生命周期，有边界和局限性，有各种不足和缺陷的。
就像在医生眼中，每个人身上都有一些小毛病，没有一个完全健康的人。
没有哪个系统会是理想中的样子，技术债是必然存在的。
这样来看，每个技术宅都会遇上技术债。
总会有自己接手的第一笔债，还的第一笔债，欠下的第一笔债。
于是开始与技术债相爱相杀的职业生涯，接下来面对更多的债。
俗话说得好，虱子多了不痒，债多了不愁，债多不压身。
但这样的心态不免过于良好，甚至有些不负责任。
越大的系统，其中包含的技术债务越多，越高的技术管理者越要重视债务，规避“系统性风险”。
什么是系统性风险？08年的次贷危机，很多赫赫有名金融机构就翻了船，越大的系统，出现问题的代价越高，风险越需要重视。
存在即合理，技术债也有两面性，就如同房贷、车贷，给我们在某些方面的收益。
因此正视技术债，有意识的管理、使用好技术债，是技术管理者必备的技能，必经的修炼。
你见，或者不见
债就在那里
今生，今世
不弃，不离
本文转载自IT民工闲话 ITCrossTalker 微信公众号，作者史海峰 微信原文链接
