前端代码评审标准规范

前端代码评审标准规范

目的

• 提高代码质量，在项目的早期发现缺陷，将损失降至最低
• 评审的过程也是重新梳理思路的过程，组内加深了对项目的理解
• 促进团队沟通、促进知识共享、共同提高

评审时间、地点

• 周五早上进行一次代码评审，如遇临时紧急事务时往后推迟。
• 单次评审地点213, 时间9点~11点

评审范围

• 命名规范、注释规范、 样式规范
• 代码结构、实现方式、性能优化
• 逻辑、功能检查

评审代码选择

• 最近一次迭代开发的代码
• 系统关键模块
• 业务较复杂的模块

审查对象内容

• 前端开发团队

审查人员

代码走查不只是开发人员的事情！需要多种角色同时参与，因为走查活动不仅仅要看功能是否实现了，还要看代码和设计是否一致？测试用例是否完备和有效？

• 主持人（孙XXXX）
  负责主持整个走查活动，控制时间和进度。
• 讲解人（被审查研发人员）
  负责对走查的代码进行讲解。
• 评审人（其他研发人员）
  负责对走查代码提出问题，建议。

审查规范方法

编码习惯：（关注点-框架使用与基本功）

• css、js、image等静态文件应该放在约定的目录里面。
• 在页面中尽量避免写入行内样式，即style=“”。
• 多行注释语句规则：

对难以理解的代码段或者可能存在错误的代码段等可以采用多行注释（/* */），
每一行以*开头，并且*后跟一个空格。

• 变量命名：变量采用驼峰式命名且首字母小写（除了对象的属性以外），
• 不允许把多个短语句写在一行中，即一行只写一行数据。
• 函数中传入的参数必须具有有效性，对特殊的入参必须进行说明。
• 尽量减少循环嵌套层次，尽量避免大于三层的循环。

业务实现：

• 如果类似的逻辑被使用了多次，应该把它写成一个函数，然后再多处调用。

安全：

• 对于那些在短时间内提交非常多请求的方法，可以采用防抖或者节流来控制请求次数，或者采用loading来阻止用户多次点击。

• 发生故障时，尽量少的暴露问题所在，只向用户返回一般的信息，比如登陆失败不应区分具体失败原因（用户名不存在、密码错误、密码已过期等），应采用统一的失败提示（错误的用户名或密码）。

• 页面标签中应该尽量避免使用 iframe。

性能：

• 所有不需要的变量应该及时的删去；尽量减少闭包的使用；如果在代码中使用了闭包，则必须在退出函数之前，将不使用的局部变量全部删除，或者将变量赋值为null。

• 尽量合并和压缩css以及js文件以减少http请求次数以及减少请求资源的大小。

• 尽量使用字体图标或SVG图标来代替传统的png图。因为字体图标或者SVG是矢量图，是由代码编写出来的，放大后不会变形，而且渲染速度快。

• 避免使用iframe，不仅不好管控样式，而且相当于在本页面又嵌套其他页面，消耗性能会更大（加载其他页面的资源）。

• 样式中给图片设置尺寸。如果图片不设置尺寸，首次载入时，占据空间会从0到完全出现，上下左右都可能位移，发生回流。

• 注意控制Cookie大小和污染，因为Cookie是本地的磁盘文件，每次浏览器都会去读取相应的Cookie，所以建议去除不必要的Coockie，使Coockie体积尽量小以减少对用户响应的影响。

注释：

Js单行注释：

在代码上面注释，必须独占一行。
// 后跟一个空格，缩进与下一行被注释说明的代码一致。

Js后缀注释：在一段语句后面后缀进行注释。

// 前后都跟一个空格，用于对某个语句的说明。
在有处理逻辑的代码中，代码有效注释量必须在20％以上。

文件注释：

文件注释（包括作者, 依赖关系和兼容性信息等）写在文件头部。
注释的内容要清楚、明了，含义准确，防止注释二义性。说明：错误的注释不但无益反而有害。

对变量的定义和分支语句（条件分支、循环语句等）必须编写注释。

新技术（关注点-适用性和扩展学习）

• 代码使用新技术是否有效，是否最优，一起讨论学习

评审结果

代码评审中评审人提出的代码问题如果合理，
被评审人需当场记录问题，在评审结果后及时修复

评审记录

评审结果记录(陆庆洋/孙丽娟), 邮件/群通知：

• 代码问题类型及改进方案
• 修复优化时间点