技术债务评估
对于技术债务，它的利息表现为系统的不稳定性，以及由于临时性手段和缺乏合适的设计、文档工作和测试带来的不断攀升的维护成本。 —— 《架构师应该知道的 97 件事》
Robert Nord 提出的“技术债务全景图”（Tech Debt Landscape）如下：
技术债会影响软件的可维护性（Maintainability）和可演进性（Evolvability）。这些影响通常不会直接体现在面向非技术人员的功能结果中。
梳理技术债
- 团队一起列出潜在的技术债
- 归纳、分类技术债
- 按影响范围和处理成本排序
- 通过实体看板呈现状态
可视化工具
技术债看板
技术债可使用任务看板管理；下图为此前在大象开发的任务看板管理应用。
技术债热力图
服务级别热力图
技术债墙
技术债务管理
《技术债治理的四条原则》提出以下取舍：
- 核心领域优于其他子域
- 可演进性优于可维护性
- 明确清晰的责任定义优于松散无序的任务分配
- 主动预防优于被动响应
减少新增技术债
童子军规则
童子军规则要求每次修改都让代码处于比修改前更易维护的状态。
提交的代码要比检出的更好
及时处理质量问题
破窗效应：及时矫正和补救正在发生的问题。
破窗理论认为，未被处理的失序信号会降低人们维护秩序的意愿。将它用于软件开发时，重点是及时修复已知质量问题，避免团队把缺陷当作默认状态。
原理论描述了社区失序的五个阶段：
- 社区开始出现失序的情形，部分居民迁出社区。
- 未能迁离社区的居民因担心自身安全，对区内的事务漠不关心。
- 地区的监察力下降，社区的治安进一步恶化。
- 区内更多的居民迁走，仍然留在区内的居民则更加退缩，减少外出时间。
- 外来的犯罪份子入侵社区，令犯罪数字持续上升。
软件开发中可能出现的相应过程：
- 部分开发人员未编写测试等质量保障代码。
- 团队只关注交付速度，忽略代码质量。
- 代码质量继续下降。
- 修复一个 bug 时引入更多 bug。
- 修改成本过高，项目可能需要重写。
可维护性
当代码可以在不影响其他功能的前提下被删除或替换时，系统的变更成本较低。要达到这一点，需要明确模块边界和依赖关系。
下列实现方式有助于降低维护时的理解和修改成本：
- 代码风格与团队约定一致，可通过 ESLint 约束。
- 按业务职责拆分模块，避免单个文件承载全部业务逻辑。
- 分离 Service、View 和业务逻辑等职责；可参考 MV*，并避免在同一层混入其他层职责。
- 将可复用的视图交互逻辑封装为组件，降低单个视图的复杂度。
相关文章：
