【数媒在线课堂】代码质量建设怎么开始呢？

首先得知道什么是好的代码，这就要有标准，那就是我们常常看到的各种各样的规范，但我觉得要有几个简单的原则，太多了，记不住，有几条原则简单的原则，可以时不时拿来判断，当前做得对不对。

然后就是去实践规范，这里需要一些技巧、一些工具，来帮助我们更好地遵循规范。

接着是度量，看我们对规范实践的效果，这就是我们常说也常做的 Code Review，但 Code Review 也需要遵循一定的规范，应用一定的技巧。

度量之后是改进，CR 结果要及时跟进，这是最重要一环，否则 CR 就没有实际意义。

总结不可少，复盘是一种很有用的工具，CR 也需要复盘，总结 CR 流程、过程等方面好的和不好的地方，更新规范和 checklist。

接下来我们分别聊一聊各个步骤。

▐规范：先知道什么是好代码

从上边高质量代码的诞生途径我们可以看出，设计也是很重要的一环，所以我们的规范包括设计规范和编码规范，结合我们的生产实际，这里加上安全生产的规范，所以规范有 3 部分：设计、编码、安全生产。

设计：先有优秀的方案

设计推荐多用图表达，图比文字有更直观的传达能力：

首先是业务流程图，它能快速构建起我们对业务的认知，带着对业务的理解再来看代码，事半功倍。

然后是用例图，清晰地表达出我们系统的职责、边界、服务对象，结合业务流程图，能快速构建起我们对系统职责的认知。

接着是架构图，从我们日常的设计需求来看，架构图是需要的。好的架构图能快速给人搭建起理解的框架，再来看系统的细节部分，就很好理解。架构图推荐C4规范，它是我目前接触的表达最清晰的架构图规范。

接着再用时序图、状态图、ER 图等把关键和复杂部分的设计表达出来。

但日常我们的需求有大有小，方案也不需要都遵循统一的范本，为了设计而设计，就徒增加工作量了。以按需为第一原则，能把要做啥，怎么做的表达清楚即可。这里按场景推荐各个图的使用场景:

新建应用 / 对原有应用进行重大修改 / 复杂项目

业务流程图 (交代业务背景)

C4 的系统上下文、容器、组件这 3 张图

用例图：有多个外部参与者

类图：关键模型超过 5 个

状态图：对象状态超过 3 个

时序图：关键流程或复杂链路的参与对象超过 3 个

ER 图：涉及数据库变更 (包含数据表结构文档)