Code Review小结

前段时间针对团队敏捷模式下开展的项目工程代码进行了几轮的Code Review，下面是梳理的若干应该注意的条目：

1. 方法的命名不规范，应坚持使用驼峰形式，标准英文名称拼接，阿里标准：禁止使用下划线和$作为命名的开头和结尾，不能使用拼音和英文拼接的形式命名，除了一些国际公认的名称比如：taobao或hangzhou。

2. 发送http请求没有设置超时限制，建立设置请求超时时间并做额外的处理。

3. 前人代码中存在历史命名或代码不规范的地方，由于涉及面广，最好不做修改，知道有问题即可，自己在做改造时切忌遵守阿里代码规范，除非团队排计划进行代码规范的修改或重构，不然自身处理耗时太久，效率过低。

4. 没有对某一块的代码逻辑进行模块化的封装，现象是方法中实现的逻辑事务太多，应该把每一快逻辑单独封装成员一个方法，然后提出来公用。

5. 对于非空判断要注意逻辑性，去除掉一些不必要的非空判断。

6. 避免在for循环体内取一些数组或者列表的count，这样每循环一次就需要调用一次，可以先把容器大小的获取放在for循环外完成，到了for循环体中直接使用，可减少调用次数。

7. 对于一些没有事务性处理的代码逻辑片段，需要在失败之后记录日志，这样可以追溯具体的操作现场的一些信息，方便追溯和排查问题。

8. 在for循环中使用的对象，为了避免重复创建，无端占用过多内存，可以在for循环之前就创建好，然后在for循环中直接使用。

9. 如果某代码块中涉及到很多的if...else...判断，则可以从面向对象的角度考虑将这块判断逻辑单独提出封装为一个方法，这样大大增强了代码结构的优良性、易维护性和可读性。

10. 对于代码中出现的硬编码，即写死的常量或变量赋值等，都可考虑进行统一配置和维护，比如平台所有的http请求超时响应时间可以统一成配置项。

11. 有时copy别处的代码，要注意删除不必要的逻辑，不可完全照搬。

12. 对于遇到访问失败或报错等情况，页面应该给出增强用户体验的友好提示，比如网络错误等等，而不该直接给予一个“404”报警。

13. 如果页面方法全都封装到外部JS对象中，建议新增的方法也要统一按照这样的约定或标准做，也封装到JS对象中，方便后期维护和查找。

14. 对于逻辑判断较多的地方，建议单独提出来封装成方法，返回true或false，增强可读性和易维护性，也方便扩展到其他地方可用。

15. 有些加密key作为常量字符串应该提出来作为类的成员变量，并调取配置项进行赋值，而不应该直接在代码中赋值。

 

未完待续......