---
title: 关于基建工作的思考
date: "2020-05-20 13:00"
tags: ["架构"]
published: true
---

## 技术债务评估

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

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

![tech-debt-landscape](../../assets/2020/05-20-技术债思考/tech-debt-landscape.png)

技术债会影响软件的可维护性（Maintainability）和可演进性（Evolvability）。这些影响通常不会直接体现在面向非技术人员的功能结果中。

### 梳理技术债

1. 团队一起列出潜在的技术债
2. 归纳、分类技术债
3. 按影响范围和处理成本排序
4. 通过实体看板呈现状态

### 可视化工具

#### 技术债看板

技术债可使用任务看板管理；下图为此前在大象开发的任务看板管理应用。

![image (1)](../../assets/2020/05-20-技术债思考/image-1.png)

#### 技术债热力图

服务级别热力图

![heat-map-services](../../assets/2020/05-20-技术债思考/heat-map-services.jpg)

#### 技术债墙

![image (2)](../../assets/2020/05-20-技术债思考/image-2.png)

### 技术债务管理

《[技术债治理的四条原则](https://insights.thoughtworks.cn/managing-technical-debt/)》提出以下取舍：

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

## 减少新增技术债

### 童子军规则

童子军规则要求每次修改都让代码处于比修改前更易维护的状态。

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

### 及时处理质量问题

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

破窗理论认为，未被处理的失序信号会降低人们维护秩序的意愿。将它用于软件开发时，重点是及时修复已知质量问题，避免团队把缺陷当作默认状态。

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

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

软件开发中可能出现的相应过程：

1. 部分开发人员未编写测试等质量保障代码。
2. 团队只关注交付速度，忽略代码质量。
3. 代码质量继续下降。
4. 修复一个 bug 时引入更多 bug。
5. 修改成本过高，项目可能需要重写。

### 可维护性

当代码可以在不影响其他功能的前提下被删除或替换时，系统的变更成本较低。要达到这一点，需要明确模块边界和依赖关系。

下列实现方式有助于降低维护时的理解和修改成本：

- 代码风格与团队约定一致，可通过 ESLint 约束。
- 按业务职责拆分模块，避免单个文件承载全部业务逻辑。
- 分离 Service、View 和业务逻辑等职责；可参考 MV*，并避免在同一层混入其他层职责。
- 将可复用的视图交互逻辑封装为组件，降低单个视图的复杂度。



相关文章：

- 《[Defects 的启示](https://insights.thoughtworks.cn/about-defects/)》