前言
本文谈技术负债的成因以及相应的处理方法。
技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是程序设计及软件工程中的一个比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。
成因
-
不充足的事前定义，从而需求仍然在开发过程中被定义，开发在设计之前就已经开始。这种做法的目的是节约时间，但常不得不以后返工。
-
缺少流程或理解，从而商务上对技术债务不了解，不考虑后果就做出决策。
-
紧耦合组件。功能不是模块化，软件不够灵活应对商务上的变化。
-
缺乏测试包。这刺激了快速高风险“凑活式”的修复bug。
-
缺少文档。写代码但没有必要的支撑性文档。[3]
-
缺乏合作。知识没有得到共享，对新手缺乏监督辅导。
-
在两个或多个分支上平行开发而累积了技术债务。由于工作最终需要合并两个分支的代码，拖延越晚，需要工作代价越大。
-
拖延做重构 – 重构拖延越晚，需要修改的代码越多。[4]:29
-
缺少与标准对齐。工业标准的特性、框架、技术被忽视。最终也必将遵从标准，做得越早代价越小。[3]:7
-
缺少知识。开发者并不知道如何写精致的代码。[4]
-
缺少所有权。外包的软件最终要让自己的工程师去重构或重写源代码。
-
技术领导力差，未深思熟虑的命令通过命令链传达下来，增加了技术债务，而不是减少它。
-
最后一分钟规范改变。这有可能渗透到整个项目中，没有时间或预算通过文档或检查来发现它们。
| 鲁莽Reckless | 谨慎Prudent | |
|---|---|---|
| 故意Deliberate | 我们没有时间做设计 | 我们必须马上交付，后果以后再说 |
| 疏忽Inadvertent | 什么是分层（设计）？ | 现在我们才知道该如何做了 |
大泥球
| 大泥球（Big ball of mud）是指一个缺少可认知架构的软件系统。这种系统往往是在业务压力、人员变动、软件熵增加等情况下开发所致。是一种反模式。 |
Brian Foote与约瑟夫·约德的1997年的同名论文，给出定义如下：
所谓的大泥球就是一个随意结构化、蔓延的、不经心的、意大利面条式代码的乱七八糟混合。系统展现了无可争议的表象：不受管制的增长、重复、权宜之计的修补。信息被系统中相距很远的模块杂乱地共享，重要信息常变为全局的或者重复的。
系统总体架构可能从未良好定义。
其损害往往超过上述认知。稍有架构敏感性的程序员避开了这些泥潭。只有那些对架构不感兴趣的人，也许对修补这些失败的堤坝上的漏洞的日常琐事的惰性感到习惯的人，才愿意在这样的系统上工作。
根源：
-
程序员在编写程序或是系统时遇到问题后的解决方法，往往缺少前期设计，不是合适的或者最优的解法，而是方便修改的，变动最小的、碎片式增长，这就为以后的系统架构的混乱甚至整个系统的崩溃埋下了隐患。
-
用户的需求或者编程的要求是在不断地变化的，应对需求和架构变化过晚，使得系统越来越复杂化，维护也越来越昂贵。
-
程序员的经验，技巧，眼界的限制。
应对方法
实际场景
以上都是从维基百科抄的， 看到这里，想必大家对技术负债也有一定认识了，然而我不是空谈家，概念要落地要结合实际才有意义。下面咱们罗列一下日常工作中的技术负债。
开发人员水平低，经验不足，得过且过（微观）
写代码的人开发敷衍了事，或者境界不够意识不到以后可能出现的问题，这点本文对此其实没有什么好说的，对于开发人员解决该问题的方法也很简单，就是严格要求自己多学习多琢磨，而想不想解决、需不需要解决这是另外的问题了。
开发排期不足（宠观）
相信这点很多人都有同感，相当数量的公司一味地追求新功能而压缩排期、紧逼进度、频繁修改需求。虽说工作的挑战性在于用有限的资源去实现目标，但时间紧迫导致项目代码质量的下降由此产生的技术负债总要有人承担，而这类公司往往只愿意为新功能付费，后期维护成本他们会选择摊给开发人员，而又不愿意给他们留出足够时间。所以这种情况下，要消除技术负债，只能占用员工的个人休息时间，否则项目代码会腐化的越来越严重，反过来拖延项目进度。而对于员工来说，没有利益补偿的情况下，这部分个人时间无偿被使用无疑是亏本的买卖。
着急交付而牺牲质量，这合适吗？
既然公司没有提供足够的开发资源，开发人员只能牺牲设计，以能上线为目标，所产生的技术负债的成本就算让公司承担，但这对开发人员本身也有很大的负面影响：质量差导致工作成就感低、缺少总体设计只顾在局部修修改改导致成长空间有限、需求变动频繁不停返工导致情绪焦躁。
所以这总体而言还是亏的，公司并不会为这些隐性成本掏钱。
也许领导说以后会作优化，但later equals never，以后的事情永远都不会发生，要保证质量，就只能牺牲自己的时间。
但无疑还有更好的选择，那就是换家公司，在市场上重新定价，选择一个盈利良好、懂开发规则的，当然如果自己水平很垃圾就无从谈起了。
结语
综上，一切都是权衡，每个人看重的东西都不一样，作出的选择自然也不一样。