前端规范之路

作者：曾干

壹钱包航旅事业部前端负责人

前端发展之路

2005 年以前，前端的地位很低，我们只是做后端模板，虽然我们也可以跟后端进行交互，但场景不多，而且大多数时候，前端同学并不写 JS，大部分工作内容也与业务逻辑无关，主要由 Java 主导项目，进行逻辑实现、发布、部署，这一时期，前端基本没有规范可言。

2008 年前后，这一时期是 H5 推出的时期，H5 为前端带来了更多的样式实现能力，我们的工作内容也开始逐渐丰富、多样化了。

2010-2014 年左右，这一时期，前端领域各种类型的框架推出得非常多，至今，我们都还会讨论哪一个框架更好。

ECMA2016 开始普及，在这之前，前端开发对设计模式的理解不多，后端开发在工作 3 年左右，如果问领导如何突破职业瓶颈、晋升，大部分人可以自然而然的选择去学设计模式。但前端领域，在这个阶段，就很少谈到去学设计模式，因为大家感觉离设计模式很远，这是由语言的能力特性造成的。不过 ECMA2016 出来之后，这块就得到大幅改善了，到今天，很多人开始觉得前端、后端已经没有什么区别了。

为什么前端开发需要规范

第一，最开始的时候，前端人很少，很多时候，大家的开发规范，遵从的是契约精神，比如我接手你的项目，沿用你的开发习惯。但现在前端团队人数多起来了，开发者素质参差不齐，就会带来很多低级错误，这个时候，契约精神就非常难推进下去。

第二，前端现在越来越复杂化，之前有人提过一个前端摩尔定律，就是每 18 个月复杂度增加一倍，我非常赞同。以前我们一个项目可能一万行代码，现在可能是 10 万行代码，项目交接的时候，我们去看代码就非常累。

第三，很多时候，每一个产品经理的需求，前端相对于后端而言，它不会因为并发量小，就可以极大减少工作量，我们前端的工作量总是恒定的，所以我们也非常需要一个开发规范，来帮助我们提升效率，减少返工。

第四，我觉得技术开发同学，需要有点自我修养，这非常有利于个人在团队的发展。如果你写的代码，大家觉得很优雅，那你在团队里面肯定更受欢迎，也有利于提高自己的职场影响力。

前端开发规范原则

这上面很多的规范原则，道理是非常浅薄的，但很多时候，我们回过头去 review 我们自己的代码，还是会发现非常非常多的问题，在我看来，更多时候，对于开发规范原则，更重要的是我们心中要保持一个精神准则，需要我们团队反复去做宣导。

另外，对于一个团队来说，我们的代码应该是写给别人看的，一个业务代码逻辑的实现，今天可能是由我来负责，明天是其它人负责，或者总有一天会由别人负责，这个时候我们需要尽量保证我们代码的可读性，这就需要有一定的约束力。

我们团队推进开发规范的一些实践

第一，团队成员是规范的制定者。我们团队规范的制定不是由 leader 单方面制定的，而是来源于我们团队每一个同学的最佳实践，比如有人做 CSS 的规范，有人做 JS 的规范，然后团队一起来遵守，这样每一个开发同学彼此之间就能够形成约束力。

第二，CR 信息透明。我们团队在做代码的 PR 之前，通过 GitHook 的能力，我们实现了一个 CR 的过程，小组 leader，或者团队的架构师就可以上去点评代码，写一些评论，这个流程非常透明，大家都能看到。另外，我们在这个基础上还开发了一个系统，大家的 CR 评论可以被可视化。

第三，团队反复宣导。一个规范制定下来，如果不去经常维护，它是没有生命力的，很容易就被团队遗弃，所以我们团队会反复去宣导规范。

第四，KPI 制定，周会复盘。我们周报有一趴是跟 CR 相关的内容，主要是将 CR 内容拿出来做点评，大家看一看 CR 的内容是否合理，这里面可能会有一些争论，但最终可以帮助团队成员共同成长。