前端开发规范

编码规范

网络上大部分‘前端规范’指的都是编码规范， 这是一种‘狭义’的前端规范。

统一的编码规范对团队项目的长远维护不无裨益。一致性的代码规范可以增强团队开发协作效率、提高代码质量、减少遗留系统维护的负担。

最直接的好处就是避免写出糟糕的代码，糟糕的代码与新手和老手关系不大，我也见过好处工作很多年的‘资深’工程师写出恶心的代码。 这样的代码随着项目的迭代会变得难以控制。

现代的Lint工具已经非常先进，几乎可以约束各种编码行为。 比如约束一个文件的长度、函数的复杂度、命名规范、注释规范、接口黑名单、DeadCode、检查简单的逻辑错误...

每一个程序员心目中对‘好代码’都有自己的主见，统一的编码规范可以像秦始皇统一战国一样，避免不必要的论战和争议。

其实与其自己建立前端编码规范，笔者推荐选择社区沉淀下来的规范。 这方面的资源非常多，所以本节也不武断地提出自己的规范建议。推荐下面这些资源:

Javascript

HTML

CSS

代码格式化

chapter5_1

基本上，所有代码格式相关的工作都可以交给Prettier来做，在这个基础上再使用Eslint覆盖语义相关的检查。

特定框架风格指南

Code Review

上述的Lint工具和类型检查器, 可以约束代码风格、避免低级的语法错误。但是即使通过上面的Lint和类型检查，代码也可能未必是‘好代码’。

很多代码设计的‘最佳实践’是无法通过具象化的自动化工具或文档覆盖的, 这时候，'经验'或者'群体智慧'就派上用场了. 比如Code Review阶段会检查这些东西:

  • 编程原则、设计思想. 例如符合SOLID原则? 是否足够DRY？接口设计是否简洁易扩展、
  • 模块耦合程度、代码重复
  • 代码健壮性。是否存在内存泄露、是否线程安全、是否有潜在性能问题和异常、错误是否被处理
  • 代码的性能和效率。
  • 是否有没有考虑到的场景？

如果你们是第一次推行Code Review, 可以建立一个检查列表，对照着进行检查。熟练后，心中自然无码。

Code Review有很多好处，比如：

  • Code Review可以让其他成员都熟悉代码。这样保证其他人都可以较快地接手你的工作，或者帮你解决某些问题
  • 提高代码质量。毫无疑问. 一方面是主动性的代码质量提升，比如你的代码需要被人Review，会自觉尽量的提高代码质量；另一方面，其他成员可以检查提交方的代码质量
  • 检查或提高新成员的编程水平。培养新人时，由于不信任它们提交的代码，我们会做一次Review检查代码是否过关。另一方面这是一次真实的案例讲解, 可以较快提高他们的能力

Code Review有两种方式: 一个提交时、一个是定时:

  • 提交时. 大部分开源项目采用这种方式。通俗讲就是Pull Request。只有代码通过测试、和其他成员的Review才可以合进正式版本库。这种方式也称为‘阻塞式’代码检查，一般配合GitFlow使用。
  • 定时. 在项目完结后、项目的某个里程碑、或者固定的时间(每天、每个星期..). 团队成员聚在一起，回顾自己写的代码, 让其他成员进行审查

Code Review是比较难以推行的，不过这个也要看你们团队的情况，向我们钱少活多的团队，很少的时间去立马去兼顾其他成员的代码. 这时候定时Review会更有用，因为看起来更‘节省时间’.

而提交时Review则可以针对新人，比如你不信任他们的代码或者希望帮助他们提高编码能力。

相关资源: