设计模式: 关于项目中的技术债务问题与解决方案

技术债务

  • 开发过程中因为时间紧迫导致的实现不合理
    • 举例:查找100000以内的质数
    • 算法不同,效率不同,好算法和坏算法的时间
  • 开发过程中暂时没有想到更好的实现方式而妥协的版本
    • 刚开始使用if…else实现
    • 使用责任链模式来进行改进:每个函数都可以独立出来,作为一个判断条件使用
    • 作为整体使用不好,使用责任链使用会让复用性提高,维护性提高
  • 架构设计前期没有考虑到的一些细节
    • 交互细节 -> props传递参数 (交互冗余,流程较长)
    • 使用全局状态管理实现参数传递
  • 不合理的交互设计,导致技术实现复杂
    • 交互设计的难度,正确和设计人员沟通
    • 减少这类问题出现
  • 旧功能文档缺失,无正确拓展,修改和兼容旧功能,导致上线后问题剧增
    • 无技术文档,技术功能没有预留出修改和兼容的接口
    • 新开发功能要预留兼容旧功能的接口
    • 让旧功能逐步符合当前架构设计的内容
    • 阶段性重构,将旧功能变为新功能的实现

不修复技术债务的后果

  1. 修复变成重构:新功能要兼容旧功能的逻辑,有些旧功能无法兼容就不得不修改旧功能,导致重构,导致排期的影响
  2. 小的技术债务不做偿还,最后会演变为一场大规模的重构工作,导致产出不高
  3. 影响开发速度
  4. 导致整体开发需要兼容的点较多,影响开发效率和上线速度,导致整体项目迭代缓慢,失去核心竞争力(项目是企业战略落地的载体)
  5. 容易陷入,维护旧功能,开发新功能,兼容旧功能,维护旧功能,开发新功能的恶性循环

技术填补的解决方案

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

总结

  • 等产品和功能上线后,开发就没有那么紧张了,可以找个时间来处理技术债务
  • 技术债务不仅仅是研发这个部门的责任, 需要联合测试和业务部门才能实现
  • 所以,请谨慎对待技术债务,否则可能背大锅
  • 如果项目节奏正常,合格的技术负责人,架构师在提测之前就需要处理好这些问题
  • 代码review是一个重要的工作, 团队代码review是一种共同学习的方式

你可能感兴趣的:(Full,Stack,Design,Pattern,Web,设计模式,技术债务)