一、技术债务产生原因

技术债务产生的几个原因：

  • 开发过程中因为时间紧迫导致的实现不合理；
  • 暂时没有想到更好的实现方式而妥协的版本；
  • 架构设计前期没有考虑到的细节；
  • 不合理的交互设计，导致技术实现复杂；
  • 旧功能文档缺失，无正确拓展、修改和兼容旧功能，导致上线后问题剧增；

如果不填补这些技术债务，可能产生以下的后果：

  • 修复变重构(举例：开发一个新功能，需兼容所有旧功能的逻辑，但在实际开发过程中会发现有些旧功能并不能完全兼容掉，这个时候就会阶段性地对当前所有旧功能进行重构，这样就不免对新功能的开发造成延期)
  • 小的技术债务不做偿还，最后会演变成一场大规模的重构工作，导致产出不高(注：实际业务看不到明显产出)
  • 影响开发速度
  • 技术债务的存在导致整体开发需要兼容的点过多，影响开发效率，极大影响上线速度，导致整体项目迭代缓慢，失去核心竞争力
  • 容易陷入“维护旧功能 => 开发新功能 => 兼容旧功能 => 维护旧功能 => 开发新功能 ……”这样的恶性循环

二、技术债务填补

那么该如何做技术填补呢？以下是技术填补的一些解决方案：

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

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

三、崩溃预防

系统崩溃是严重的架构设计事故，也是我们需要预防的关键所在。以下是一些预发措施：

  • 日志记录，如：操作日志、错误日志、业务日志等。通过这些日志文件，可以进行用户行为抓取，进而争取在最短时间内获取到用户操作链路
  • 解决存量问题 => 技术债务
  • 遏制新增 => 减少新增问题的概率
  • 对脏数据进行兜底和检验
  • 单元测试
  • 崩溃报警(异常达到阈值进行报警)
  • 自动化测试(主要进行主体链路的测试)
  • 更广的灰度触达(灰度策略，注：RPA也可采用灰度策略进行推送更新)
  • 性能优化体系(性能优化、技术架构优化…..)