前端CodeReview流程及开发基础标准

1.提高代码质量，及早发现潜在缺陷，降低修改/弥补缺陷的成本

2.促进团队内部知识共享，提高团队整体水平

3.鼓励相互学习对方的长处和优点

开发完成后. 开发者群里告知相关人, 可开始做code review准备.

1. 开发者交叉review

a.熟悉了解该模块的业务和逻辑

b.仔细检查代码. 并将发现的问题记录下来.

c.所有开发者把问题形成excel表格, 登记在wiki上.

2. 外部人员review

a. 每次code review前确定一个带队者. 负责推进该次code review顺利进行.
如人数较多,可细分安排小伙伴负责独立模块/系统;
如有时间关系, 先核心代码, 最后低风险代码

b. 根据之前CR形成的标准规范, 快速检查. 尽量减少这部分review所花费的时间

c. 了解页面业务. review业务代码. 将发现的问题记录在confluence上.

(上面两步同时进行)

3. 评审会

a. 代码评审会上根据上面两步发现的问题进行讨论.

b. 根据实际情况. 一步步沉淀code review基本标准.
单次CR时间过长, CR内容过多, 都会影响到评审的质量, 可根据实际情况, 分次进行.

4. 会后

a. 该次code review带队者负责邮件发送.

b. 开发者及时解决code review问题.(在email中确认deadline)

c. 问题提出者在修复后验收. (需在该次迭代上线前完成)

项目如果版本正常迭代, 代码量往往很大. 而没有形成review习惯的童鞋往往不知道从哪开始, 要看什么问题, 要怎么review才有效果.

可从代码的一致性、编码风格、代码的安全问题、代码冗余、是否正确设计以满足需求(性能、功能)等方面入手. 如下图:

CR list

1.上图的CR要点, 也可以作为自测清单. 检验自身开发的代码是否符合要求.

2.代码基础标准

描述注释类:

风格类;

如果特殊情况. 避免使用行类样式.
遵循基本标签嵌套规则.
块状元素内可嵌套任何块状元素或行内元素 ( 特例：h1~h6、dt、p不能出现任何的块元素 )
行内元素内只可嵌套非自身的行内元素
ul标签下级用li. 其他类似标签一样. 如ol, table.
css代码请写在js代码后面.
样式统一加上scoped, 避免污染，组件需要样式重置的，采用deep方式，参考：https://blog.csdn.net/supming1/article/details/93485409
vue项目js模块基本顺序: name, props, data, 计算属性. 监听, 需要用到的生命周期. methods (name, props, )
给vue项目添加vue模块. 方便快速进行页面初始化. 参考: https://www.jianshu.com/p/34a5a4193892

js类:

循环和递归,注意判断边缘条件.
所有对像变量在操作其属性或方法前必须先判断有无空值再使用，如果是空值，加上默认值.
表单输入使用trim方法去掉两端空格. (特殊业务需求除外, vue项目采用v-model.trim)
避免"通过刷新页面更新数据"的实现方式.
map 是将一种形式的数组映射成另外一种形式的数组，需要return 东西出来，不要只用做循环，单纯的循环用foreach.
data里放置数据, 不调用封装的方法. 如果需要对数据进行数据, 请使用计算属性或方法.
注意单页代码行数, 必要时使用模块化. 独立组件, 减少单文件代码量. 采用v-cloak，避免在变量在解析前被用户看到，参考(https://cn.vuejs.org/v2/api/#v-cloak )文档

实践建议(不硬性要求):

参考学习其他平台的代码风格/规则:

airbnb (官方:https://github.com/airbnb/javascript 翻译版: https://www.jianshu.com/p/527fe171e8d7)
https://eslint.vuejs.org/rules/valid-v-show.html . (目前项目里只引入了Essential级别的, 剩余的Strongly Recommended 和 Recommended级别可作为代码优化范围)