前端代码质量保障之代码review

Posted 54开发者

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了前端代码质量保障之代码review相关的知识,希望对你有一定的参考价值。

 点击上方54开发者关注的人都有好技术哦~


  经验丰富的程序员和一般程序员之间的最大区别,不仅体现在解决问题的能力上,
还体现在日常代码的风格上。掌握一门技术可能需要几月,甚至几周就够了。
好的习惯风格养成却需数年。


团队成员之间需要合作,代码需要日后可维护,个体的能力和习惯存在差异。
故保证代码质量及风格,就需要制定一定的规则,按项目周期(最好是在上预发之前)组织进行集体代码review。



一 目的

        1    保证代码质量 
自己的代码要给别人看,在开发过程中就会刻意的注意一些规范,写法及逻辑严谨性。

2 扼杀潜在的风险
程序员会去自测,即使有某种情况分支遗漏, 在讲解的过程中其他同学也能发现。

3 互相学习提高
高手是如何写出逻辑严谨,简洁易懂的代码的。方便对照自己的不足,逐步的纠正。



 

 

二 如何推动

1 分组结对

   1  一般团队大前端,后端 肯定有多名同学。
可以按‘同项目,模块或老司机带新’ 的模式进行分组。并指定各个小组组长(最好轮值)。

2 小组长,负责开发过程中规范提醒 及 发起相互review。



2 集体review

  1  每次review最核心的代码,控制好时间。

2 各自讲解自己的模块,复杂业务最好配有流程图。



3 开发工期

要把 ‘代码review’及 代码优化也评估进去。



4 打分制(下面会继续 讲解打分细则)

   1  评判代码好坏,还是需要一个衡量标准,可以采用打分制度。除同个项目组成员外其余项目组同学,均要给该讲解人打分。

2 打分需要注明:一 需要修复和改进的地方; 二 值得学习借鉴的地方。
并统一由会议记录人,邮件抄送相关人员,开发者去落实修改,组长负责跟进验收。



 

 

三 自查(测)清单

前面说了,要自测。那么我们大概可以从如下方面切入:

1 常规项

1 代码能够工作么?它有没有实现预期的功能(需求),逻辑是否正确等。
2 所有的代码是否简单易懂? 是否尽可能的模块化了?组件化了?是否存在多余的或是重复的代码?
是否有可以被库函数替代的代码(尽量用集团自有的)? 不重复造轮子。
3 代码符合你所遵循的编程规范么(详见 我另外html,js,css编码规范的文章)?这通常包括大括号的位置,变量命名和函数名,行的长度,缩进,格式和注释。
4 去掉大段被注释掉的代码(若有用可以先提交到git上,以后可回滚)
5 循环是否设置了长度和正确的终止条件? 按钮是否有控制单次点击,不重复提交?
6 是否有考虑调用api接口缓存问题?是否有可以删除的日志或调试代码?
……



2 安全

1 所有的输入是否都进行了检查(检测正确的类型,长度,格式和范围),考虑了xss攻击和js脚本注入。

2 引用导入的第二、三方依赖包,是否存在不可用 和 版本升级导致功能不可用的风险。
是否是GPL协议的源码( 不能用,否则会要求使用者的代码也开源)

3 本机保存的数据,是否有泄漏的隐患。(铭感数据不做本地存储,即使保存也需要加密)。

5 发布之前清理log日志 和 敏感注释。尤其是前端同学。



3 文档

1 是否有注释,并且描述了代码的意图?数据结构和计量单位是否进行了解释?
2 对非常规行为和边界情况处理是否有描述?
3 第三方库的使用和函数是否有文档?
4 是否有未完成的代码?如果是的话,是不是应该移除,或者用合适的标记进行标记比如‘TODO’?



4 性能速度

1 页面加载显示是否超过3s(用户超过3s 就会不耐烦,除非你有很友好的提示。。。)
2 js代码 是否有明显影响性能的逻辑 和 计算。
3 同个组件 或者 页面布局层级嵌套尽量不要太深,保持简洁性。



 

 

 

四 评分标准及规则 (5大维度,总分100)

1 需求功能覆盖率 --------权重3(30%)

9-10分:代码严谨、逻辑分支覆盖全面 无遗漏
6-8分:无关键逻辑分支遗漏,普通遗漏不超过2次
0-5分:关键逻辑分支遗漏1次及以上 或其他分支遗漏2次以上



2 代码结构耦合度--------权重3(30%)

9-10分:结构清晰,模块独立(数据融合),模块间关联简单,模块内完成特定子功能
6-8分:模块间中度藕合(控制藕合)
0-5分:模块间强藕合,模块内功能复杂



3 健壮性---------2(20%)

9-10分:性能稳定,异常考虑周全,没有安全注入风险----1 页面打开速度不超过3s 2 破坏性测试情况下依然稳定加载
6-8分:异常处理不到位(undefined等),存在性能问题,但不影响关键流程,不宕机
0-5分:关键流程存在问题,有宕机风险



4 简洁度------1(10%)

9-10分:没有冗余代码,没有重复造轮子,单个函数功能单一,建议不超过20行,无多余导入的包或类
6-8分:存在冗余,重复代码
0-5分:普遍存在冗余,重复代码



5 可读性------1(10%)

9-10分:严格执行集团编码规约,易于理解,命名规范,注释清晰 
6-8分:存在阅读障碍与阅读困难的情况
0-5分:关键逻辑与复杂代码缺乏注释,理解极度困难




ps: 分数最终计算方式可以这么着
1 总分按100分算,单项最终得分=评分*权重 (例如‘覆盖率项得总分27=9*3) ,然后把5项的总分加起来。



2 3.75的标准就是各项加起来90分+ ;3.5的标准就是加起来80分+






 

补充:
1 方法的请求 和 数据处理 尽量分离, 抽离 (一个方法只做一件事情)。

2 相关对象,做下 容错 或 默认值 处理。

3 主要review 1 异常情况分析处理 2 主流程业务有无遗漏。


以上是关于前端代码质量保障之代码review的主要内容,如果未能解决你的问题,请参考以下文章

如何保障前端项目的代码质量

第27期如何保障前端项目的代码质量

Gerrit代码Review入门实战

Gerrit代码Review入门实战

架构师技能5:如何做code review 代码简洁之道

架构师技能5:如何做code review 代码简洁之道