前端规范约定

本文主要围绕前端工程，介绍如何制定开发规范 —— 针对开发规范，我们可以做哪些事情。

为什么

近年来，随着互联网、大数据的不断发展，前端开发的发展速度也是相当之快。但是，不论如何发展，在编写代码的过程中都要遵循一些基本的编码规范，但是有些开发水平较低的团队不太注意这些基本规范从而在开发过程中往往会多走很多的“弯路”……

1. 好的编码规范可以尽可能的减少一个软件的维护成本，并且几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护；
2. 好的编码规范可以改善软件的可读性，可以让软件开发人员尽快而彻底地理解新的代码；
3. 好的编码规范可以最大限度的提高团队开发的合作效率；
4. 长期的规范性编码还可以让软件开发人员养成好的编码习惯，甚至锻炼出更加严谨的思维；
5. 开发规范不只是代码格式的约束（缩进使用空格还是 tab），还有前人踩过坑留下的宝贵经验，按规范开发学习并提升编程技能。

思考：你在开发过程中遇到哪些因为开发不规范而踩过坑？

• 项目交接时缺少业务介绍和开发说明文档，花费过长的时间在熟悉项目上，如果遇到紧急需求更是如此；
• 需求评审不严谨，技术难点或遗留问题未能合理的评估，导致开发不能按时提测；
• 团队内缺乏一致的编码规范，每个开发人员都有自己的编码习惯，在接手别人开发的模块时，产生抵触心理乃至争执，不利于团队协作；
• 经验欠缺的开发人员缺少规范约束，输出的代码质量偏低，导致后面维护成本过高；
• 缺乏技术栈统一规范，开发人员为了个人学习诉求在项目中引入多种开发框架，导致后期维护成本过高；
• 版本管理混乱，在多版本并行开发时，错误的将测试中的功能部署到生产环境。

所以，为了实现团队统一的开发规范，我们需要针对项目开发流程中的各个环节制定规范。

理想目标

遵循「大胆假设，小心求证」的办法，我们先给自己立个 Flag —— 拥有成熟完备的文档和工具，成功实践统一规范化的开发流程，最终实现自动化的代码质量评分。

思考：那么，你又觉得开发规范可以做哪些事情？

上图是我们的理想目标，你可能会觉得这样的实现思路会过于激进和理想化了，特别是最终要实现的自动化质量评分。事实确实如此，现在大部分团队规范都难以统一，即使有规范也难以落实。但这里，还是希望给自己定个目标，作为自己的理想(画饼)。是否能够行得通，必须走一遭才知道 —— 哪里可行，给我们带来了怎样的收益？哪里不可以行，为什么行不通？

开发规范除了可能会给我们项目的开发效率和维护成本带来收益外，大家也可以在整个实践历程中对开发规范有更好的认知，对前端开发规范的生态有体系化的掌握。规范化作为前端工程化的一部分，在别人询问你规范化是否值得做，要怎么做时，能够胸有成竹的回答。

1. 前端开发规范是什么？
2. 是否有必要做开发规范？
3. 如何做好开发规范？
4. 开发规范给你和团队带来怎样的收益？

在我们实践过开发规范后，希望大家都能够清楚的知道这些问题的答案，能够结合自己的经验，思路清晰的给出具体的实践方案、项目案例和收益数据，而不再是三言两语的含糊其辞。

实现方案

开发规范的实现方案主要是针对项目开发流程中的各个环节做统一的约定，然后在团队内执行与反馈，不断地迭代优化这一流程。

• 项目管理：制定项目管理相关的规范，每个项目需要编写和维护好业务和开发说明文档，在团队内达成共识。此外，要求规范化需求评审的流程，以规避项目风险。
• 编码规范：主要在前端开源社区提供的规范文档和审查工具基础上制定适合团队的开发规范和工具。
• 版本管理：结合公司的前端部署流程，规范化 Git 分支管理和提交信息的格式。此外，针对前端公共库提供相应的部署环境，自动化和规范化的发布代码库。

技术架构

目前前端社区有各色各样的开发规范说明，一些大公司也会在社区推广自己的开发规范，例如：Google Style Guides、Airbnb JavaScript Style Guide、JavaScript Standard Style 等。此外，随着近几年前端生态的野蛮生长，出现了大量的优秀的开发规范工具，例如：ESLint、Prettier 等。所以我们的主要工作是整合前端开源社区的资源，组合输出适合团队的开发规范。

本文章 - 公司团队实际实现规范，并推广：项目地址不公布了。