本文主要是介绍设计模式: 关于项目中的技术债务问题与解决方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
技术债务
- 开发过程中因为时间紧迫导致的实现不合理
- 举例：查找100000以内的质数
- 算法不同，效率不同，好算法和坏算法的时间
- 开发过程中暂时没有想到更好的实现方式而妥协的版本
- 刚开始使用if…else实现
- 使用责任链模式来进行改进：每个函数都可以独立出来，作为一个判断条件使用
- 作为整体使用不好，使用责任链使用会让复用性提高，维护性提高
- 架构设计前期没有考虑到的一些细节
- 交互细节 -> props传递参数 (交互冗余，流程较长)
- 使用全局状态管理实现参数传递
- 不合理的交互设计，导致技术实现复杂
- 交互设计的难度，正确和设计人员沟通
- 减少这类问题出现
- 旧功能文档缺失，无正确拓展，修改和兼容旧功能，导致上线后问题剧增
- 无技术文档，技术功能没有预留出修改和兼容的接口
- 新开发功能要预留兼容旧功能的接口
- 让旧功能逐步符合当前架构设计的内容
- 阶段性重构，将旧功能变为新功能的实现
不修复技术债务的后果
- 修复变成重构：新功能要兼容旧功能的逻辑，有些旧功能无法兼容就不得不修改旧功能，导致重构，导致排期的影响
- 小的技术债务不做偿还，最后会演变为一场大规模的重构工作，导致产出不高
- 影响开发速度
- 导致整体开发需要兼容的点较多，影响开发效率和上线速度，导致整体项目迭代缓慢，失去核心竞争力(项目是企业战略落地的载体)
- 容易陷入，维护旧功能，开发新功能，兼容旧功能，维护旧功能，开发新功能的恶性循环
技术填补的解决方案
- 优秀的架构设计是基础
- 当前架构设计，能够有效处理当前需求可预见的情况，对于未知的，可能出现的特殊情况，很小的改动就能解决问题
2.1 我们的架构应该是简练的，精简的，对于一些可预见的问题，不建议做一些功能处理，只需要做一些预留接口即可 - 根据当前的业务，进行合理的项目拆分，尽量的代码解耦合
- 必须有日志模块，操作日志，错误日志，业务日志等等
- 良好的技术培训和传帮带能力
- 让每一位开发者可以从更深一层次理解所需要实现的功能
- 从最开始的代码规范，到熟悉业务，最后再到编写文档
- 充分的技术方案可避免一部分技术债务的产生
- 技术方案是充分理解需求之后所能产出的对需求理想的实现方式，必要性不言而喻
- 不同工程师之间可以相互review代码，避免当局者迷出现，codeReview是非常重要的，同时也是对自身的一个提高
- 提升对修复技术债务重要性的认知
- 工程师如果能预见一个债务可能导致的问题，自然愿意花时间去处理
- 善于发现和定期处理一些技术债务问题
- 勇于发现系统中的技术债务，让自己为系统负责
- 让自己为系统负责
总结
- 等产品和功能上线后，开发就没有那么紧张了，可以找个时间来处理技术债务
- 技术债务不仅仅是研发这个部门的责任, 需要联合测试和业务部门才能实现
- 所以，请谨慎对待技术债务，否则可能背大锅
- 如果项目节奏正常，合格的技术负责人，架构师在提测之前就需要处理好这些问题
- 代码review是一个重要的工作, 团队代码review是一种共同学习的方式
这篇关于设计模式: 关于项目中的技术债务问题与解决方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
