什么是技术债

技术债的诞生

  1. 为了解决短期压力
  2. 获得短期利益
  3. 向未来借款,产生债务
  4. 债务需要付出的额外代价是「利息」

技术债本身存在风险的。如果不及时处理会导致系统「破产」。

技术债都是不好的

技术债的诞生为了快速上线带啦巨大的商业利益
如果该利益大于后续的利息,那么技术债是有积极价值的
但是技术债的存在会在未来护短产生了利息,这些利息不及时处理,可能会对利益造成负面影响

怎么分析

从三个方面进行分析:可维护性、可演进性、问题的可见性

可维护性

整体来说,基于问题代码

  1. 代码的可读性
  2. 是否易理解
  3. 是否有明显的坏味道
  4. 是否容易扩展和增强

可演进性

整体来说,是系统适应变化的能力,软件架构趋于目标演进的能力

  1. 支撑功能快速迭代的灵活性
  2. 高可用性
  3. 可扩展性

问题的可见性

  1. 对于最终用户来说,软件功能、设计和用户体验等方面的缺陷,导致用户无法顺利完成既定的业务流程,那么对于永不不可见的代码问题就升级成为了可见的质量问题
  2. 不合理的技术债导致无法快速响应变化,使得交付延期,这样升级成了交付风险

技术债困境

现状

通过头脑风暴手机的技术债,通过迭代计划的方式很难持续下去,最终真正能治理的少之又少

堆积原因

团队对于技术改进缺少战略思考

没有将技术改进和业务战略结合起来执行。
从而导致技术改进的方向和业务发展不一致,产出的结果无法得到业务的认可。

代码可维护问题难以让客户买单

  1. 技术债的影响和收益难以衡量
  2. 之前承诺了交付高质量的产品,代码质量也是交付内容之一

有的改进治标不治本

  1. 比如性能优化,解决部分技术债提高了性能,但是等数据体量继续上升,会再次暴露出来
  2. 有的问题是模型设计问题,难以一时间就改进

怎么发现

  1. 代码审查
  2. 提升团队能力
  3. 使用自动化工具
    1. 静态代码扫描工具
      1. SonarQube
      2. checkstyle
      3. 自定义扫描规则并作为代码审查的一部分
    2. 可演进性问题
      1. 适应度函数
        1. 用计算机模仿自然界生物进化禁止,用于评价个体的优劣程度。适应度越大个体越好,繁殖适应度越小则个体越差
        2. 在软件系统的不断增量迭代过程中,可以基于架构的严谨目标,定义出软件架构的适应度函数,来衡量增量的代码是否导致架构偏离这个目标
      2. ArchUnit
      3. NDepend

怎么治理

核心领域解决的优先级高于其他子域

核心域的价值是用20%的代码带来80%的成功
在领域模型视图(核心域、支撑子域、通用子域)和技术债分布结合起来得到的视图可以作为优先级排序的依据,遵循『核心域有限,其他子域次之』的原则来决定技术债解决优先级

可演进性优于可维护性

  1. 不合理的架构设计,会给功能迭代造成不少麻烦。可能少量的改动会有巨大的连锁反应
  2. 可演进性问题可能会直接导致开发进度滞后
  3. 引入技术债没有在合适的时间处理,利息会变得无比巨大
  4. 和可演进性问题相比,可维护性也很重要,但是软件适应变化的能力有更高的价值
  5. 结合领域模型图+技术债的视图可以得到各个领域的可演进性和可维护性技术债分布

明确软件系统的负责人

有了明确的分配可以促使软件朝可持续发展的方向前进

  1. 任务分配的方式会导致业务和技术存在上下文割裂,并且不用对系统可持续性负责,加上频繁的业务切换会将技术债遗漏
  2. 需要有一个这个业务的负责人或负责团队,触发上下文分享,制定规范和约定,对系统负责。这样可以更深入地从需求、技术方案、技术架构等方面着手解决问题。
  3. 服务责任人制度 - service owner
    1. 一个小组负责一个或者多个微服务,每个微服务只由一个小组负责,在分配特性功能、技术债务和线上问题时,需要把服务责任人制度作为首要遵循的原则
    2. 好处:
      1. 业务只是和技术上下文的相对集中,在解决具体的软件缺陷时不再浮于表面,团队成员可以更加深入地从需求、技术方案、软件架构等方面着手解决根本问题
      2. 针对线上问题通过清晰、明确的责任制度,倒逼团队在开发阶段竹筒关注软件的内建质量,谨慎判断是否引入技术债

主动预防优于别动响应

提早发现技术债
[[技术治理的四条原则#怎么发现]]


其他参考资料:
技术债务,到底应该怎么还?