技术债务
「技术债务」是开发团队在设计或架构选型时，从短期效应的角度选择了一个易于实现的方案。但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务。
简单的说就是为了快速地解决问题，而采取的不规范的方案。
比如：开发工程师将某个判断条件写死、测试工程师未进行深入自动化测试、架构师运用了一个即将过时的框架。
危害性
对于房贷，大家肯定每个月都记着去还。
但是，对于技术债务，大家似乎都不那么关心。
的确，这个东西不一定谁借谁还，可能一个人的代码中产生了技术债务，可能是由于项目做，工作压力大，离职了。
那么，这笔债务就压在了工作接替者的身上，古人语：父债子偿，不知道这叫什么，O(∩_∩)O哈哈~
比如我们在一个类中欠下了技术债务，如果对这个类进行扩展、修改，或按照原来错误的写法写了一些新的业务方法。
用不了多久，我们就会发现我们已经无力偿还这份技术债务啦，只能重构啦。
客户：经常BUG缠绕，长期缺失的需求不能上线。
运营：不合理的界面设计、文档缺失、系统响应慢。
运维：频繁的BUG修复上线。
管理层：各方的抱怨让管理层崩溃，尤其是BUG、延期等问题。
研发：开发人员的工作比较多面，一方面开发新的需求，另一方面又要维护他人遗留的代码。
所有的问题，最终都会回到研发人员进行再次开发、修复，所以 加班，加班，加班...
其实每一个研发都不愿意出低质量的产品，也没有人愿意接受满手都是坑的代码。
分类
- 无意的
由于经验的缺乏导致初级开发者编写了质量低劣的代码。
解决方案：
1.技术培训
毕竟大部分的程序员学习能力还是很强的，部门牛人的培训还是很有必要的，也是学习的重要途径之一。
从最开始的代码规范、到熟悉业务、最后再到编写文档。
2.CodeReview
CodeReview 是非常重要的，同时也是对自身的一个提高。
在这个阶段不同工程师之间可以相互review,审查别人的代码能够发现很多问题，同时也能学到很多知识。
- 有意的
团队根据当前而非未来进行设计选型，这种方式可能很快就能解决当前的问题，但却很拙劣。
这就情况很可能是为了图省事才这样干的。
也有可能是工期太短，人员太少，技术问题等等。
推荐方法
- 系统设计的框架是对的
必须能够有效处理当前需求可预见的情况，对于未知的、可能出现的特殊情况，很小的改动就能解决问题。
根据当前的业务，进行合理的创建数据表，尽量的代码解耦和。
必须有日志模块，操作日志，错误日志，业务日志等等...
- 所有的工程师有主人翁的意识
开发前，针对产品提出的需求，进行要进行细节确认，自己也可以画一个程序的流程图。
开发时，首先把流程全部顺下来，其中遇到调用其他接口、技术难点、需求模糊，及时确认或记录 TODO 标签。
开发后，及时对自己的流程进行确认，查看代码中是否有未解决的地方。
每个公司都有自己任务管理系统，例如JIRA之类的，提测后，时时关注自己的BUG。
如果与产品有分歧的地方一定要及时沟通，达成共识。
- 一定要有健全的测试环境、预发布环境、正式环境
因为有些程序可能需要进行压力测试，所以服务器的配置还是很关键的。
多个环境的测试，更能保证程序的健壮性。
- 定期处理一些技术债务
等产品上线后，开发就没有那么紧啦，这个时间大家可以找个时间处理技术债务，一边建立感情，一边品味一下原来的代码，是不是酸爽无比。
- 善于发现系统的技术债务
勇于发现系统中的技术债务，当然不是为了所谓的奖励，仅仅是为了自己的提高，让自己为系统负责，而不是事不关己高高挂起。
当然，最重要的其实是把技术债务的重要性提到一个被认可的位置上。
工程师如果能遇见一个债务可能导致的问题，自然愿意花时间去处理。
切记：一些重要的技术债务远远比开发新系统的优先级要高很多。
Thanks ~
