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

最新推荐文章于 2025-06-20 09:06:02 发布

转载最新推荐文章于 2025-06-20 09:06:02 发布 · 874 阅读

1 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/softwarelanguagebs/p/10190132.html

文章标签：

#前端 #git #数据结构与算法 #ViewUI

本文详细介绍了代码审查的目的、推动方法、自查清单及评分标准，旨在提升团队代码质量，确保代码风格一致性和可维护性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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


        团队成员之间需要合作，代码需要日后可维护，个体的能力和习惯存在差异。 
故保证代码质量及风格，就需要制定一定的规则，按项目周期(最好是在上预发之前)组织进行集体代码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 本机保存的数据，是否有泄漏的隐患。（铭感数据不做本地存储，即使保存也需要加密)。

4 所有的请求链接是否都是用https，包括图片地址。

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  主流程业务有无遗漏。

转载于:https://www.cnblogs.com/softwarelanguagebs/p/10190132.html