开发域的质量

SonarQube 的技术债务

SonarQube 扫描出来 Gitlab 的 repo 的技术债务需要清零，在迭代过程中，团队需要持续关注技术债，保持技术债稳定下降的趋势，建立修复技术债的技术故事卡（举例如下），在对应的提交中需要将代码提交的 commit message 中的需求 id 填写该技术故事卡的 ID。

单元测试

单元测试的两种实践：

• 普通的开发模式实现开发实现故事卡的逻辑代码，然后再根据写好的代码编写单元测试，对单元模块进行测试。

• 采用测试驱动开发的开发人员，根据用户故事中的 AC 或测试用例，先进行测试用例的编写，再进行功能模块的开发。

单元测试的一些规则：

• 被测函数的外部函数调用，外部服务调用，都需要解耦（java 推荐 mockito）。

• 被测试函数访问数据库、消息中间件、redis 等中间件的，都需要解耦。

• 测试类在 test 目录下所在的路径应与被测试的类在 src/main/java 下的路径保持一致。通过约定的规则，测试类和被测试类相对应，方便查看和定位。

• 测试类的命名和被测试类保持一致，后缀加上 Test。

• 测试用例的命名应该采用 should_get_when 的方式:should_get_number_when_score_given_equal_60()。

• 每一个测试用例必须有断言，用断言验证测试结果。

• 单元测试代码和被测试业务逻辑代码最好再一次 commit 中提交，如果分开，也建议前后 2-3 个 commit 中提交，避免先写完逻辑代码，批量补单元测试的情况。

CodeReview

代码评审比较常用的有：

• 基于 Gitlab 的 Merge Request，相关评审人员走查通过后，代码合并到 release 分支中

• 集体代码走查，在开发人员提交测试前，组织团队成员进行集体评审。目前组织级的实践要求通过 Gitlab 进行代码评审，各团队可以自行选择是否开展集体代码走查，并制定执行集体代码走查的条件和规则两种实践可以混合使用。

基于 Merge Request 的评审

• 开发人员在 feature 开发分支上完成代码提交，并推送到 gitlab 服务器

• 开发人员在 Gitlab 上发起 Merge Request，目标分支为 release 分支。选择 Assignee（指定 Reviewer），选择审核人（approvers）及最小批准人数（Approvals required）。根据描述模板中的内容检查代码状况，然后进行提交。

• 代码审核人员审查提交的 Merge Request，评审时为存疑的代码片段添加注释 comments，MR 的创建者应对相应的注释及时解答。

• 审核通过，可以提交 Merge，将代码合并到目标分支。

集体代码走查

集体代码走查的意义

• 传播知识，避免对特定模块/特定人员单点依赖。

• 达成共识，避免重复，改善设计。

• 让新人从讨论中学习到解决问题的思路和技术要点。

• 培养新人的最直接和最有效的途径，对已有代码的讨论，既实例化，又能直接提升质量。

集体代码走查的频次

频率建议一开始每天做一次代码走查。如果大家时间很难协调， 也要保证每周两到三次。时长根据团队大小决定，如果小团队(2~3 人)，时间控制在半小时以内。如果团队人员较多，1 小时为宜。根据发现问题的情况，及时调整评审的范围和时长。频率和时⻓可以根据团队情况不断调整，最终找到最合适你团队的实践。

评审议程

• 检查上次代码走查所记录的改进点是否已经修复，更新记录表

• 代码作者简要介绍所走查的代码的业务上下文和开卡验卡验收条件

• 展示代码规范标准工具扫描结果

• 作者展示所修改的代码，参与者提问，作者答疑

• 作者记录改进点