前端CR基本原则及最佳实践

Nora
863 阅读16分钟

前言

作为一名开发工程师，相信对于code review一词，你应该不会陌生，至少应该过耳闻。

coding之余，在读技术书籍的时候，在学习的时候，在看博客的时候，在泡论坛的时候，在看前沿技术新闻的时候，在夜深人静的时候...总之在你深度思考的时候，你应该会有这样的疑问，如何才能提升自己的代码质量？怎样让工作敲出来的是优质代码而不是烂代码？怎样可以让代码好维护、好扩展、易读性强，而不是别人看着提交记录有想打死“前任”的冲动？怎样让自己在工作中得到更多提升，而不是日复一日年复一年？怎样才能让团队对于项目和代码的理解和清晰度集体上升一个台阶，而不是你做你的我做我的？怎样让团队的同学都能够得到提升，省的整体听到抱怨，要不就默默地给别人擦屁股（有时候是给自己擦屁股）...

如果你有深度思考过，那么恭喜你，你不是每天在撞钟的人，你是对自己的职业有要求和规划的人，也是对自己负责的人。代码能力如果停滞不前，对于个人而言，将是职业危机的前兆。代码能力如果停滞不前，对于团队而言，将意味着团队在走下坡路。

刚提到的都是在开发之外的疑问，互联网开发工作起来永远都是时间紧任务重，要提升代码质量，实则不容易的。Code Review（代码审查）是一个重要的环节，是公认的提升代码质量的利器。接下来，我们会根据深度思考的问题，针对Code Review，进行深度的勾兑。

为什么要做好Code Review

先看一下定义，以及行业中的位置。

  • 定义：Code Review是在编码完成后进行代码审查，找出代码中存在的问题编码、设计漏洞，进而修复问题，提高代码质量的环节。
  • 定位：code review（代码审查）是软件开发中提升代码质量的最佳实践之一。
  • 星标：google、微软、国内大厂，CR的基本要求，代码都必须走审查流程（据说google每一行都是要审查过的）。
  • 标准：好的团队，代码审查一定是必选项。

可以说，有Code Review是好的开发团队的标志，也是变成好团队不可或缺的一环。丢掉这一环，会引发包括但不限于上边提到的各种各样的问题，对于个人和团队，都是很糟心的一件事。

总结一下Code Review的好处：

  • 提高工程团队的开发流程的标准化
  • 高效提升个人与团队能力
  • 保持项目代码风格一致性
  • 降低bug率

做好Code Review，于个人、于团队都是一件好事。

如何做好Code Review

Code Review是提升代码质量的最好方法，那么如何做好Code Review，如何让Code Review的价值在个人和团队得到充分体现，让个人和团队得到Code Review的巨大红利？这是一个值得人深思的问题。

其实Code Review是有成熟的执行流程的，如下：

  • 制定规范
  • 运用工具
  • 角色分配
  • 基于一致的认同（是一种文化，而非一种制度）

制定规范

我相信许多中小型公司都会面临下面几个问题：

  • 老旧业务代码的技术负债：由于历史原因，仍旧还有一些老业务在旧项目中运行（想改又不敢改），所以这种技术负债就必不可少了
  • 要研发进度，不要研发质量：在需求进度的催促下，许多同学的代码逻辑以及代码质量可以说是一塌糊涂了
  • 无 GitFlow 协同工作流： Git 的使用仍旧停留在 commit、pull、push 等简单使用中
  • 团队更迭文档负债：存在最大的问题就是对一些老旧业务的不熟悉；因为人员的更迭，许多业务产品无记录、代码无注释，导致许多业务逻辑只能靠猜，极大的降低了团队的研发效率
  • 沟通少，导致效率低：可以少沟通，但是聊天工具永远无法比当面沟通有效率

正是由于这些问题的存在，从而影响到团队之间的协作，使团队的效率整体降低，严重的甚至会影响团队和谐.

其实作为一名优秀的程序员，写的代码无论是可读性、可维护性还是可复用性，都是必不可少的。 那么如何去写高可读性、高可维护性、高可复用性的代码呢？ 就值得我们每个人深思熟虑了。接下来我们带着疑问一起进入规范的世界！

定义：

代码规范是基建的之一。在日常开发中，任何能 提高代码可维护性、降低代码理解成本、提高代码的容错率 和 提高项目可扩展性 的统一标准，称之为 规范标准；

好处：

  • 代码的一致性
  • 降低开发成本
  • 提升团队效率
  • 减少沟通成本
  • 有助于自身成长
  • 提高团队和谐

前端编程规范的都有什么？

关于前端规范，我大致划分出了下列的内容，具体实施还需以自身公司实际情况为准；

image.png

（1）命名规范

命名 有多重要，我相信每位工程师都能明白其中的重要程度。一个不好的命名，可能就会引起别人的错误理解；遵循一套严格的命名规范，无论是对自己还是接手的他人，都会大大降低代码的维护成本，所以想要成为一名合格的前端开发，命名规范是必须的。

驼峰式命名：

  • Pascal Case 大驼峰式命名法：首字母大写； eg：StudentInfo、UserInfo、ProductInfoCamel
  • Case 小驼峰式命名法：首字母小写； eg：studentInfo、userInfo、productInfo

文件资源命名：

  • 文件名不得含有空格；
  • 文件名建议只使用小写字母，不使用大写字母；
  • 名称较长时采用半角连接符(-)分隔；

变量命名：

  • 命名方式 : 采用小驼峰式命名方法；
  • 命名规范 :
    • 普通变量(number, string, date)；
    • 布尔类型：需要一个标识变量含义的前缀，比如has, is, wether, can, should等；
    • 数组/集合等复数形式：最好以s或list等能够标识复数形式的后缀结尾，标识当前变量是复数形式，提高可读性；
    • 常量全部大写，且用下划线来分割单词，eg：MAX_LENGTH = 1

函数：

  • 命名方式 : 小驼峰方式 lowerCamelCase ( 构造函数使用大驼峰命名法 )
  • 命名规则 : 前缀为动词（CURD），动词 eg：add / update / delete / detail / get

css 命名：

  • 样式类名使用小写字母，以半角连接符(-)分割；
  • id 采用驼峰式命名；
  • scss / less 中的变量、函数、混合、placeholder 采用驼峰式命名

（2）技术栈规范

我相信不同的人肯定都有不同的答案，因为在不同的公司技术栈肯定是不一致的，技术栈不仅取决于领导的拍板，也取决于业务的支持，所以会出现同一个业务部门会有不同的技术栈的情况。比如ToC对于界面要求、兼容性、SEO要求较高，处于引流和广告会采用友好需求的技术栈，比如SSR的Vue框架Nuxt。比如我公司架构师根据公司业务需要以及友好于团队开发角度已经搭建了脚手架（这里要夸一下，这个不要太好用，大大降低了技术门槛，让更少的人做更多的事，做更重要的事）。脚手架在已经囊括了技术栈规范的考量。那么就技术栈，做下比较。

  • 为什么用 TypeScript 而不用 JavaScript 呢？

    • 静态类型语言要较于动态类型语言更安全；
    • TypeScript 代码更可靠且更易于重构；
    • TypeScript 更明确类型；

  • 为什么用 Vue 而不用 React ？

    • 这是一个容易引战的话题；
    • 所以答案是：领导让的

  • 为什么用 Sass 而不是 Less ？

    • Sass 功能齐全；
    • 不仅有变量和作用域，还有函数和进程控制的概念；
    • 更像一门正规的编程语言；

（3）编程规范

  • 为什么需要编程规范？

    • 前端三剑客——HTML、CSS、JS，有因为 JavaScript 不规范的，也有因为 CSS 不规范的；
    • 但是我们究其原因，无非就是没有一个所谓的统一标准而导致；
    • 正所谓：无规矩不成方圆，有了规范才有好的团队~

  • 编程规范的意义：

    • 统一团队的编码规范，有助于代码的维护
    • 提升编码效率
    • 减少沟通成本
    • 提升团队气氛
    • 有利于 Code Review

  • 编程规范都有什么？

    • HTML规范
      • 基于W3C、苹果开发者等官方文档，并结合团队日常业务需求以及团队在日常开发过程中总结提炼出的经验而约定。
    • CSS规范
      • 统一团队 CSS 代码书写和 SASS 预编译语言的语法风格，提供常用媒体查询语句和浏览器私有属性引用，并从业务层面统一规范常用模块的引用。
    • JS、TS规范
      • 统一团队的 JS 语法风格和书写习惯，减少程序出错的概率。
    • 图片规范
      • 了解各种图片格式特性，根据特性制定图片规范，包括但不限于图片的质量约定、图片引入方式、图片合并处理等。
    • 命名规范
      • 从 “目录命名”、“图片命名”、“ClassName” 命名等层面约定规范团队的命名习惯，增强团队代码的可读性。
    • Vue规范
      • 统一团队的类 Vue 应用的语法规范，规范类 Vue 应用书写。

怎么搞编程规范？

  • 确定现有团队的问题
  • 定制属于自己公司的规范
  • 统一规范应以自动化为前提
  • Eslint、Prettier、Stylelint 自动化必不可少

（4）Git 规范

  • 为什么要 Git 规范？

在实际开发中，无论是 Git 版本的规范，还是 Git 的提交规范，都是一环较重要的部分，规范他们绝对是大有裨益的。

Git作为程序员的必备技能，可能都不会要求Git的使用达到炉火纯青，林纳斯·托瓦兹写的丰富功能是造福程序员的，结果每个人都有一套自己的Git使用理论，多人开发简直会出现五花八门的问题，杀死了多少人的脑细胞来挽回由于工具导致的代码低级错误，简直就是灾难，甚至是生产问题。解决办法，还是“规范”，要求有Git的版本规范以及提交规范。

Git规范的好处：

  • 方便跟踪工程历史
  • 方便快速回溯代码
  • 方便 Code Review
  • 方便生成 CHANGELOG
  • 提高项目的整体质量，提高个人工程素质

下边是最基本的Git工作流规范： image.png

  1. 开发分支基于master检出
  2. 环境分支（dev、test、release）禁止交叉
  3. 环境分支（dev、test、release）禁止反合并到开发分支
  4. 禁止线上解决冲突
  5. 非必要禁止强推

Git Commit 规范（结合工具强制使用 Git Commit 规范，约定式提交）：

  1. feat：新功能 feature
  2. bug：测试反馈 bug 列表中的 bug 号
  3. fix： 修复 bug
  4. ui：更新UI；
  5. docs： 文档注释变更
  6. style： 代码格式(不影响代码运行的变动)；
  7. refactor： 重构、优化(既不增加新功能，也不是修复bug)；
  8. perf： 性能优化；
  9. release：发布；
  10. deploy：部署；
  11. test： 增加测试
  12. chore： 构建过程或辅助工具的变动
  13. revert： 回退
  14. build： 打包

（5）BFF 研发规范

BFF 是为前端设计的后端，不可图一时之方便而越俎代庖，将大部分本该由后端服务提供的能力据为己有，而更应该关注在前端的体验优化上，做好前后端的隔离，让前后端能够各司其职，合理高效协作。

原则如下：

  1. 接口数据返回统一原则：统一一致的数据格式
  2. 微服务接口聚合原则：秉承五合一原则，即单个接口至多只能聚合五个微服务接口
  3. 业务下沉原则：需下沉至后端服务

（6）UI 设计规范

记得好多年前，前端还被称作美工，会切图，会写各种静态页面，全是刀耕火种不说，写的还都不一样，UI调整一个风格，简直不要太痛苦。

设计规范的意义与目的：

  • 统一样式风格
  • 提高组件的复用
  • 提升研发效率
  • 提升团队协作能力
  • 保持产品迭代过程中品牌一致性

设计规范包括：

  • 通用样式UI规范：

    • logo
    • 标准色
    • 字体
    • 图标
    • 标签
    • 图片
    • 阴影

  • 常见交互规范：

    • 常态
    • 悬停
    • 激活
    • 点击

  • 通用组件库规范：

    • 表单组件
    • 表格组件
    • 弹窗
    • 吐司
    • 等等

（7）前端测试规范

前端测试一般可以划分为针对 UI 的测试，以及面向于组件工具库的测试。但由于前端页面变化太大，单元测试耗时耗力，劳民伤财，性价比低，所以前端不是那么重视。

前端测试的常用工具（大家可以去玩一玩，毕竟单元测试的力量还是蛮强大的，此处略过）：

  • mocha：Mocha 是一个功能丰富的 JavaScript 测试框架；
  • jest：facebook 出的一款JavaScript 自动化测试框架，专注于简单性。
  • vitest：尤大团队打造，一个由 Vite 打造的单元测试框架，而且它很快！

（8）浏览器兼容规范

浏览器大战是时代已经过去了，依稀记得曾经的IE折磨了多少前端童鞋，都不晓得多掉了多少根秀发。还记得有一次上线，第二天紧急回滚，就是因为保险的阿姨都是用IE浏览器，发版后完全不能用。。。还好IE已死，前端程序员也终于迎来了放牛班的春天。就前端团队，应该根据用户设备类型 、实际开发成本、浏览器市场份额等因素来制定对应的浏览器兼容规范。毕竟要讲究投入产出的，95%的人力物力就要服务于95%的用户，至于剩下的5%，可以等待他们变得更更加重要，也可以等待他们被产品所遗弃。

（9）IDE编辑器规范

编辑器还是根据开发内容做区分的，毕竟各有所长，这也是他们活下来的原因。但无论如何，团队协作开发，还是要统一IDE。

IDE 编辑器规范的意义：

  • 统一配置，方便开发
  • 规定团队编码风格
  • 规范对应插件

（10）CR 规范（Code Review）

CR的优点不予赘述了，搞 Code Review 规范需要注意什么？

  • 在 Code Reivew 的评论中适当加入Code Sample
  • 注重团队整体，把“你”改为“我们”
  • 表达肯定（注意措辞和表述方式，要让CR产生正确作用，影响团队开发氛围）
  • 阐明原因，最好有理论依据支撑，并赋予解决方向（不要“我觉得”，也不要抛出问题，不解决问题）
  • 遇到紧急上线，无法完成CR怎么办？（先记录，之后补齐CR及代码优化）

使用工具

现在很多源代码管理工具都自带Code Review工具，典型的像Github、Gitlab、微软的Azure DevOps，尤其Gitlab，还可以自己在本地搭建环境，根据自己的需要灵活配置。之前有分享过基于Gitlab的CR实践，此次不予分解。

角色分配

每个人的的代码都应该经过审查，每个人也应该去审查和学习其他人的代码的优长之处。审查者和被审查者同样重要。但是代码审核的质量，和审核者的代码能力直接相关。代码审核的质量差，反映的是审核者的代码水平。

基于一致的认同（是一种文化，而非一种制度）

真要把Code Review这件事做好，必须让Code Review变成团队的一种文化，参与成员真正认同这件事，并认真执行这件事。

要形成这样的文化，不那么容易，也没有想象的那么难，比如这些方面可以参考：

  • 首先，得让开发人员认识到Code Review这件事为自己、为团队带来的好处
  • 然后，得要有几个人做好表率作用，榜样的力量很重要
  • 还有，对于管理者来说，你激励什么，往往就会得到什么
  • 把Code Review要作为开发任务的一部分，给审查者和被审查者都留出专门的时间去做这件事

基于项目的CR最佳实践

google、微软、国内大厂对于代码审查是有要求的（听说google、微软的代码不审查是不可以用的），基于日常开发，任务繁杂，但是对于技术团队本身CR又是不可或缺的，如何让CR落地，值得思考。要实现项目中实行Code Review来满足团队的需求，分一下几个重要节点：

  • 制定前端规范
    • 前文很大篇幅在讲述前端规范，那么还是要进行规范的制定。毕竟没有落到文字的规范，算不得规范
  • 输出方案设计（设计文档、xmind等）
    • 好的代码一定是设计出来的，对于复杂实现，方案设计、技术选型，留有文稿是必要的
  • CR代码评审会（编码后，提测前）
    • 针对需求：交代需求背景、结合设计方案和界面演示，评审核心代码
    • 针对技术方案：交代背景、以及技术方案设计，进行评审
    • 针对bug、代码优化：交代问题代码及相应理论支撑，给出解决/优化方案，进行评审
    • 针对知识、技能分享：对分享内容进行调研及总结，进行分享
  • 完成代码优化

总结

代码审查于个人和团队的是重要的，也是必要的。迭代过程，在开发速度与开发质量的度长絜大中，不言而喻，技术是服务于功能的。但是作为技术人员本身提升编码质量也至关重要。所谓长治久安，于团队也是做大做强的重要一环。相信，用好Code Review，团队会带着个人原地起飞~

avatar
文章
阅读
粉丝