代码检查清单

代码清单

抽象思维

1. 基本类型偏执
2. 重复代码抽象

1.1 命名规范

1. 常量的命名
2. 变量的命名
3. 方法的命名应该使用动词
4. 类名应该使用名词
5. 命名应该清晰

1.2 NPL处理

1. 方法入参检验
2. 返回对象检验

1.3 单一职责原则

1. 不应该有重复的代码
2. 方法不应该过长，过长考虑是否可以拆分
3. 方法必须明确做的事情
4. 方法只能做一件事

> 如果函数只是做了该函数名下同一个抽象层上的步骤，则函数还是只做了一件事

1.4 方法

1. 只能做一件事

提高了整个代码方法的复用性、可测试性，可维护性。待单元测试搞起来，这样就可以维护整个代码的准确性了

2. 函数参数应该避免使用过多参数，最多3个参数，多参数封装成类
3. 别写出重复代码
4. 适当地写注释
5. 别返回null,也别传递null，使用异常替换成null,如果调用第三方方法，可以进行做一个适配器，判断null的
   情况，抛出异常（契约编程思想）

   自己的写的方法不要返回null,如果是null则调用方也要进行验证是否为空，如果调用第三方代码则需要进行判断是否为null，返回值需要在代码注释写清楚

6. 一个方法不应该引入过多的类（模块内聚性）
7. 在编写函数参数的时候，如果是单参数的时候，如果是需要转换的话，需要定义返回值，而不是传递一个参数对象，然后直接修改参数对象，这样会让人造成误解。
8. 避免标识参数，可以拆分成不同的方法
9. 注重方法的参数，尽可能地生成单参数的方法，避免多参数，这样会导致别人理解方法。
10. 方法要分隔指令和询问，要么做一件事情，要么就回答一件事
11. 使用异常代替错误码，使用异常代替返回null对象，这样调用层次就不需要进行验证

1.5 单元测试

1. 没有单元测试就无法保证自己修改的方法是否可以正常使用，这样故障就会越来越多，然后也不敢修改代码，导致生产代码越来越腐败。
2. 测试代码和生产代码一样重要，它需要被思考、被设计、被照料，也应该和生产代码一般保持整洁
3. 单元测试可以让你的代码可扩展、可维护、可复用。
4. 有了测试，就不用担心对代码的修改了，就可以时时对代码进行重构，不然这个版本提测好的方法，明显有问题，如果没有测试，就不敢进行重构。
5. 测试的要求：快速、独立、可重复、自足验证、（及时*）
6. 每一个测试应该只有一个assert,每一个测试应该测试一个概念
7. 单元测试应该恰好在使其通过的生产代码之前完成
8. 之所以现在还没有做单元测试，是指对软件中最小可测试单元进行检查和验证，但实际开发过程中大部分实际情况下，都没有做单元测试，做的只是为了测某一个功能点，而启动一整条功能测试，主要是在于系统功能的设计和开发中没有对功能节点进行拆分，使很多流程的边界不清晰。

1.6 注释

代码的注释：坏注释都是糟糕代码的支撑或借口，或者是对错误决策的修正，基本上等于程序员自说自话

代码编写规范

1. 时时保证代码整洁、时常重构，不要放在最后一次重构，看到了就去重构它
2. 在重构的时候需要对现有的逻辑进行分治处理（难点）
3. 先做设计再写代码
4. 便写代码需要明确，需要编写其他人能理解的代码
5. 编写设计文档
6. 一定得解决sonar问题
7. 使用构造函数复用代码
8. 不用的代码就删除掉，不要通过注释去了，保证代码整洁
9. 在时间的时候，需要添加时区，不然序列化转时区的时候，会丢失精度
10. 使用卫语句
11. 别传递null,也别返回null
12. 优化代码格式

架构

1. 使用架构结构、设计原则和设计模式等手段、将不同的功能模块进行分区实现、构建出界限上下文
2. 在做功能的设计和实现中，要注意模块的边界、并让它们尽可能的先保持独立运行后，依照设计原则编入整个流程中。
3. 在系统设计的时候，应该先成领域划分开始，明确对象边界，并且明确各个领域各个层次之间的依赖关系，调用关系，不能导致循环依赖问题，比如核心子领域不能交叉依赖其他核心子领域，通用领域不能依赖核心子领域等。

代码分支规范

1. Master分支（保证该代码都是提测通过的）
2. feater_xx （版本开发分支）
3. hotfix(上线后，紧急拉的分支，测试完合并到master分支)
4. bugfix(上线后，普通问题，可以合并到下个版本的feater_xx，也可以合并到master分支上）
5. feater_xx合并到master后可以打tag标签，标注版本号，如果上线后出现fix修复后，合并到master也要打tag。

保证代码质量

1. 对接接口时，前端有责任对对接数据进行判断是否合适合理，如果后端返回数据不正确，不合理需要提醒。

前端和后端不是同时进行的，因此需要前端先做初步的判断，如果完全在自测测的时候并不能考虑很细节，考虑到每一个接口的事情。

1. 减少发包次数，实在遇到堵塞问题则进行发包，减少发包时间

2. 进行部署后自测

3. 在解决问题时，需要考虑其相关性、将问题所涉及的其他场景列出，并且检查