[开发测试]保障代码质量

需求分析

需求分解疑问case

需求评审

确认疑问的需求case，已经确认的case推动产品及时修改需求文档。

技术评审

评审需求case对应的技术实现，先想好怎么做，知道怎么做才能准确的做出开发排期。

代码开发

以上需求评审、技术评审都是为了更清晰、更容易、更安全（减少业务逻辑bug）的代码开发。

可读性

1. 不准出现魔法值
2. if判断必须加注释
3. 尽量降低代码耦合，避免大长多的单个方法逻辑，提高代码可复用。

代码自测

代码检查工具检测

1. 阿里代码规范
2. sonar检查

工具检查单元测试覆盖率

1. idea 单元测试用例覆盖率检查

代码评审

重视CodeReview
代码合并到feature对应的main分支时，根据之前的技术评审文档讲解自己代码逻辑。

项目复盘

1. 提出项目开发中的问题
   例如沟通协作效率
2. 记录
3. 下版本改善

bug后置处理

bug类型分析

bug记录

1. 业务理解不到位？
2. 代码逻辑缺失
3. 粗心写出低级bug（必须避免）
4. 代码运行效率

记录bug类型，追踪至以后的地带迭代，着重检查。根据组内反馈情况来决定要不要在以后的迭代中去除该bug类型对应的case。

需求分析

1. 拆解业务逻辑；

2. 需求在下一个迭代开始之前给出；

   1. 比如提前三天到五天；
      1. 根据需求量
   2. 之前逻辑牵扯
   3. 在线doc工具，可以打标注
      1. 例如飞书

3. 敏捷开发步骤

4. 前期需求理解到位之后，会为后期开发节省很多时间，同时减少业务逻辑bug。

5. 代码质量分析，插件检测，自动化检测

6. 保障代码可读性，不准出现魔法值，if判断必须注释，代码格式统一，便于维护，backup更容易

7. 测试用例覆盖率检测

8. codereview

9. 需求从开发到上线全流程

10. 1.拿到需求，先分析实现方法，不要边想边做，比如绘制流程图？

11. 2.开发后自测，测试用例覆盖率，代码检查工具，

12. 3.重视codereview，向审核代码同事讲明实现方法，

13. 4.建议类

14. 功能复用，代码耦合度降低，便于维护