2-8技术填补与崩溃预防

千里之堤毁于蚁穴

技术债务填补与崩溃预防

1. 技术填补-问题1
   开发过程中因为时间紧迫导致的实现不合理
   举例：查找10000以内的质数
   循环的方法：筛选法

2. 技术填补-问题2
   暂时没有想到更好的实现方法而妥协的版本
   刚开始使用if…else实现
   演变为使用责任链模式

3. 技术填补-问题3
   架构设计前期没有考虑到的细节
   交互细节- > props的传递参数（交互冗余，流程较长）
   使用全局状态管理实现参数的传递

4. 技术填补-问题4
   不合理的交互设计，导致技术实现复杂

5. 技术填补-问题5
   旧功能文档缺失，无正确拓展、修改和兼容旧功能，导致上线后问题剧增

技术不及时填补-后果

• 修改变重构
• 小的技术债务不做偿还，最后会演变成异常大规模的重构工作，导致产出不高
• 影响开发速度
• 技术债务的存在导致整体开发需要兼容的点过多，影响开发效率，极大影响上线速度，导致整体项目迭代缓慢，失去核心竞争力
• 容易陷入维护旧功能→开发新功能→兼容旧功能→维护旧功能→开发新功能…这样的恶性循环

技术填补-解决方案

• 优秀的架构设计是基础
• 必须能够有效处理当前需求可预见的情况，对于未知的、可能出现的特殊情况，很小的改动就能解决问题。
• 根据当前的业务，进行合理的项目拆分，尽量的代码解耦合。
• 必须有日志模块，操作日志、错误日志、业务日志等等。
• 良好的技术培训和传帮带能力。
• 让每一位开发者可以从更深一层次理解自己所需要所需要实现的功能。
• 从最开始的代码规范、到熟悉业务、最后再到编写文档。
• 充分的技术方案可避免一部分技术债务的产生。
• 技术方案是充分理解需求之后所能产出的对需求理想的实现方式，必要性不言而喻。
• 不同工程师之间可以相互review.
• CodeReview是非常重要的，同事也是对自身的一个提高。
• 提升对修复技术债务重要性的认知。
• 工程师如果能预见一个债务可能导致的问题，自然愿意花时间去处理。
• 善于发现和定期处理一些技术债务。
• 勇于发现系统中的技术债务，让自己为系统负责。

总结

等产品上线后，可发就没有那么紧啦，这个时间大家可以找个时间处理技术债务，一边建立感情，一边品味一下原来的代码，这种感觉极其酸爽。