技术债务评估

对于技术债务，它的利息表现为系统的不稳定性，以及由于临时性手段和缺乏合适的设计、文档工作和测试带来的不断攀升的维护成本。 —— 《架构师应该知道的 97 件事》

如 Robert Nord 提出的 “技术债务全景图”（Tech Debt Landscape） 所示：

技术债对于软件的影响：可维护性（Maintainability）、可演进性（Evolvability），而这些技术债对于非技术人员来说都是不可见的。它们源于生活，藏于黑暗中。

技术债头脑风暴

1. 团队一起列出潜在的技术债
2. 归纳、分类技术债
3. 优先级排序
4. 物理板可视化

可视化工具

技术债看板

技术债看板（比如我之前在大象做的任务看板管理应用）

.png)

技术债热力图

服务级别热力图

技术债墙

.png)

技术债务管理

技术债治理的四条原则（《技术债治理的四条原则》）：

1. 核心领域优于其他子域
2. 可演进性优于可维护性
3. 明确清晰的责任定义优于松散无序的任务分配
4. 主动预防优于被动响应

避免技术债

童子军规则

童子军有一条规则：“永远保持离开时的露营地比你发现它时更整洁”。

提交的代码要比检出的更好

避免破窗效应

破窗效应：及时矫正和补救正在发生的问题。

以一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。又或想像一条人行道有些许纸屑，如果无人清理，不久后就会有更多垃圾，最终人们会视若理所当然地将垃圾顺手丢弃在地上。因此破窗理论强调着力打击轻微罪行有助减少更严重罪案，应该以“零容忍”的态度面对罪案。

此理论描述了社区失序的五个阶段：

1. 社区开始出现失序的情形，部分居民迁出社区。
2. 未能迁离社区的居民因担心自身安全，对区内的事务漠不关心。
3. 地区的监察力下降，社区的治安进一步恶化。
4. 区内更多的居民迁走，仍然留在区内的居民则更加退缩，减少外出时间。
5. 外来的犯罪份子入侵社区，令犯罪数字持续上升。

对应的软件开发失序：

1. 少部分开发人员不关注代码质量。如测试的编写
2. 开发人员关注于交付速度，不关心代码质量。
3. 项目代码质量进一度恶化
4. 改一个 bug，出现更多的 bug
5. 项目无法维护，只能重写

可维护性

代码可以快速无副作用的删除掉，可维护性最强。这对系统架构的要求最高

一般项目中具有可维护性的代码大多都有以下特征：

• 代码风格是与团队代码风格一致的，这个可以通过eslint做约束
• 代码是模块化的，不应该一个文件包含所有业务逻辑，必须做物理拆分
• 逻辑是分层的，Service是一层，View是一层，核心业务逻辑是一层，可以参考MV*，每一层不应该掺杂其他层的职能
• 视图是组件化的，将通用视图交互逻辑层层抽象封装，进一步简化核心视图复杂度

相关文章：

• 《Defects 的启示》

Written by xi ming You should follow him on Github