一个好的程序员肯定是要能书写可维护的代码，而不是一次性的代码，怎么能让团队当中的其他人，甚至过一段时间之后的你，再看自己某个时期写的代码，依然能看懂？这就涉及到规范你的代码了。
1一、规范代码的好处 2 31、从根本上降低开发成本： 4 5提高代码整体的可读性、可维护性、可复用性。 6 72、保证代码的一致性： 8 9软件系统中最重要的因素之一就是编码的一致性。如果编码风格一致，也更加易于维护，因为团队内任何人都可以快速理解并修改。 10 113、提升团队整体效率： 12 13开发人员通常需要花费大量的时间来解决代码质量问题，如果都按照规范编写，也有助于团队尽早发现问题，这将提高整个交付过程的效率。 14 15二、不规范代码的弊端 16 171、增加团队成员间的协作负担： 18 19由于缺乏规范，导致代码风格不一，极端情况下，某段代码只有某个人能修改。 20 212、团队间协作更加困难： 22 23由于开发人员要适应不同的风格，会导致效率低下。 24 253、回顾困难： 26 27在review期间，可能经常为类似的事情做过多的讨论。 28 294、影响降低团队整体效率： 30 31影响团队的生产力和质量，严重的甚至会影响团队和谐。 32 33三、为什么很多团队缺乏规范 34 351、当开发人员被要求在短时间内完成任务时，通常会回避质量标准。 36 372、长时间养成的开发习惯很难在短时间内去改变。 38 393、有的时候虽然达成了一致，但在开发中依旧我行我素。 40 41四、规范包含哪些内容 42 43我们平时理解的前端开发规范，更多层面的是编码层面的规范，实际上远不止这一个。比如技术栈规范、浏览器兼容规范、项目文件结构规范、UI设计规范、前后端协作规范等，以下主要从这六个方面简单介绍下前端开发规范。 44 451、技术栈规范 46 47前端目前主要有三大框架Vue、React和AngularJS。每一个框架背后都是一个架构、一个生态。每个框架背后牵涉着开发思维、生态系统、配套工具、最佳实践、性能调优。要精通和熟练一个框架需要付出的成本是很高。 48 49所以说团队的开发效率是基于稳定且熟练的技术栈的。稳定的技术栈规范有利于团队协作和沟通; 另外如果团队精通这个技术栈，当出现问题或者需要深入调优, 会相对轻松。 50 51前端技术栈规范主要包含下面这些类型: 52 53① 编程语言 – Typescript或Javascript 54 55② UI框架及其配套生态（路由、状态管理、组件库、国际化、动画、服务端渲染、脚手架、CLI工具、组件测试等） 56 57③ 样式。命名规范、预处理器等 58 59④ 动画引擎 60 61⑤ 项目构建工具流。webpack、vue-cli 62 63⑥ 包管理器。npm、yarn 64 65⑦ 开发工具、工具库（moment.js）、版本管理（gitlab）等 66 672、浏览器兼容规范 68 69前端团队应该根据应用所面对的用户情况、应用类型、开发成本、浏览器市场统计数据等因素，来制定自己的浏览器兼容规范。不过确定哪种兼容策略，应该取决于用户比重，如果大部分用户使用的是现代浏览器，就应该使用优雅降级，为现代浏览器提供最好的体验，而旧浏览器则退而求之次，保证大概的功能，反之选择渐进增强，保证低版本浏览器的体验，对于支持新特性的新浏览器提供稍好的体验。 70 71有了浏览器兼容规范，前端开发和兼容性测试就有理有据，避免争议; 同时它也是前端团队的一种对外声明，除非特殊要求，不符合浏览器兼容规范的浏览器，前端开发人员可以选择忽略。 72 73我们也可以根据浏览器市场分布情况、用户占比、开发成本等因素对将浏览器划分为多个等级，不同等级表示不同的支持程度： 74 75① 完全兼容: 保证百分百功能正常 76 77② 部分兼容: 只能保证功能、样式与需求大致一致。对于一些不影响主体需求和功能的bug，会做降低优先级处理或者不处理 78 79③ 不兼容: 不考虑兼容性 80 813、项目文件结构规范 82 83主要包含项目的命名、项目的文件结构、版本号规范等。 84 85下面简单列举一类项目文件结构： 86 87① README.md: 项目说明。你可以在这里提供关于项目的关键信息或者相关信息的入口。一般包含下列信息: 88 89·简要描述、项目主要特性； 90 91· 运行环境/依赖、安装和构建、测试指南； 92 93· 简单示例代码； 94 95· 文档或文档入口, 其他版本或相关资源入口； 96 97· 联系方式、讨论群； 98 99· 许可、贡献/开发指南。 100 101② CHANGELOG.md: 放置每个版本的变动内容, 通常要描述每个版本变更的内容。方便使用者确定应该使用哪个版本。 102 103③ package.json: 前端项目必须. 描述当前的版本、可用的命令、包名、依赖、环境约束、项目配置等信息。 104 105④ .gitignore: 忽略不必要的文件，避免将自动生成的文件提交到版本库。 106 107⑤ docs/: 项目的细化文档, 可选。 108 109⑥ examples/: 项目的示例代码，可选。 110 111⑦ build: 项目工具类脚本放置在这里，非必须。如果使用统一构建工具，则没有这个目录。 112 113⑧ dist/: 项目构建结果输出目录。 114 115⑨ src/: 源代码目录。 116 117– src 开发目录 118 119– pages 视图 120 121– module-a 模块A 122 123– components 私有组件 124 125– ComA.tsx 126 127– ComB.tsx 128 129– index.module.less 130 131– index.tsx 132 133– Content.tsx 134 135– module-b 模块B 136 137– components 公共组件 138 139– index.ts 导出所有组件 140 141– header 142 143– index.tsx 144 145– index.module.less 146 147– User.tsx 148 149– useGetBaseInfo.hooks.ts 150 151– routers 路由文件 152 153– store redux中的数据 154 155– utils 这里是以utils为后缀 156 157– index.ts 158 159– a.utils.ts 160 161– b.utils.ts 162 163– hooks 这里是以hooks为后缀 164 165– index.ts 166 167– a.hooks.ts 168 169– b.hooks.ts 170 171– styles 静态资源文件 172 173– service api请求,这里是以api为后缀 174 175– a.api.ts 按照后端微服务进行划分 176 177– b.api.ts 178 179– constans 常量 180 181⑩ tests/: 单元测试目录。 182 183⑪ tests: 全局的测试目录，通常放应用的集成测试或E2E测试等。 184 185⑫ .env*: 项目中我们通常会使用环境变量来影响应用在不同运行环境下的行为。可以通过dotEnv来从文件中读取环境变量. 通常有三个文件: 186 187· env 通用的环境变量； 188 189· env.development 开发环境的环境变量; 190 191· env.production 生成环境的环境变量。 192 1934、编码规范 194 195每一个程序员心目中对‘好代码’都有自己的主见，统一的编码规范可以避免不必要的论战和争议，有利于团队项目的长远维护。一致性的代码规范可以增强团队开发协作效率、提高代码质量、减轻系统维护的负担。 196 197以下主要从HTML、JS、CSS、代码格式化这四个方面谈谈编码规范： 198 199① HTML规范 200 201使用 HTML5 的文档声明类型 : 202 203DOCTYPE标签是一种标准通用标记语言的文档类型声明，它的目的是要告诉标准通用标记语言解析器，它应该使用什么样的文档类型定义（DTD）来解析文档。 204 205使用文档声明类型的作用是为了防止开启浏览器的怪异模式。 206 207没有DOCTYPE文档类型声明会开启浏览器的怪异模式，浏览器会按照自己的解析方式渲染页面，在不同的浏览器下面会有不同的样式。 208 209如果你的页面添加了，那么就等同于开启了标准模式。浏览器会按照W3C标准解析渲染页面。 210 211详细规范可查看：https://codeguide.co/#html 212 213② JS规范 214 215函数变量命名、代码注释等。JS/TS主流的大致有这几种: 216 217· Airbnb JavaScript Style Guide： 218 219https://github.com/airbnb/javascript 220 221· Google JavaScript Style Guide：https://google.github.io/styleguide/jsguide.html] 222 223· Idiomatic JavaScript Style Guide： 224 225https://github.com/rwaldron/idiomatic.js 226 227· JavaScript Standard Style Guide 228 229③ CSS规范 230 231ID和class的命名、合理使用ID、css选择器中避免使用标签名、使用子选择器、尽量使用缩写属性等，详细可参考以下网站： 232 233· Airbnb CSS / Sass Styleguide： 234 235https://css-tricks.com/bem-101/ 236 237· Code Guide： 238 239https://codeguide.co/#css 240 241④ 代码格式化规范 242 243由于每个开发者的IDE不同，即使IDE相同也会因为每个人的配置不一样导致格式化的结果不一样。如何确保团队内开发人员采用统一的格式化配置呢？ 244 245这里给推荐大家使用 prettier，它内置了一套格式化的规则。细可参考以下网站：https://prettier.io/ 246 2475、UI设计规范 248 249UI 规范的最大好处就是能够提质提效： 250 251① 在开发者的角度，与设计规范同步形成研发资产，避免重复造轮子； 252 253② 在测试的角度，能够避免重复的无意义走查； 254 255③ 在UI设计师的角度，减少设计成本，提高设计效率，可以快速承接新需求； 256 257④ 在产品角度，提高产品迭代与优化效率，降低试错成本； 258 259⑤ 在用户角度，解决用户体验一致性。 260 261如果团队不打算制定自己的UI设计规范，则推荐使用现成的开源组件库：Ant Design、Element UI、iView、WeUI等 262 2636、前后端协作规范 264 265前端往往不能脱离后端而存在，和后端协作的时间也是比较长的。 266 267一个常用的前后端协作流程： 268 269① 需求分析。参与者一般有前后端、测试、以及产品。由产品主持，对需求进行讲解，接受开发和测试的反馈，确保大家对需求有一致的认知。 270 271② 前后端开发讨论。讨论应用的一些开发设计，沟通技术点、难点、以及分工问题。 272 273③ 设计接口文档。可以由前后端一起设计；或者由后端设计、前端确认是否符合要求。 274 275④ 并行开发。前后端并行开发，在这个阶段，前端可以先实现静态页面; 或者根据接口文档对接口进行Mock, 来模拟对接后端接口。 276 277⑤ 前后端进行接口联调。 278 279五、前端开发规范实例 280 2811、项目情况 282 283多人开发同一个项目的不同模块；由于开发前没有制定规范，导致每个人的代码都是一种单独的风格；当其他人去修改代码时需要熟悉不同风格的代码，浪费了大量时间在阅读代码上；而且由于没有全局的样式规范，导致每个人都有一套自己的样式，在后期如果想要做统一的界面风格时需要每个人都去修改样式代码，增加了大量工作量。 284 2852、制定规范 286 287根据项目的实际情况，由于项目已经开发到一定程度，已经选好了开发框架，所以可以从编码和UI设计等方面进行规范。 288 289由于项目是一个管理系统，所以对于前端UI来说可以统一页面结构；制定一个统一风格的模板，开发的时候可以直接使用模板代码去做适应性的修改； 290 291由于缺乏统一的样式标准，导致后期统一风格时会花费大量时间，所以进行统一的样式分离，抽离公共的CSS样式去引用，方便后期统一修改； 292 293由于一些变量和函数命名过于简单比如a、b、c等，规范多使用一些语义化的单词去命名，方便理解和阅读； 294 295由于项目开发中前后端是同一个人开发，导致有些可能是后端的工作放到了前端去处理。比如分页功能，虽然这个是前后端都可以做的，但是如果使用前端去分页，这样就要需要一次性返回全部数据，数据量大的时候接口可能会返回很慢，导致页面空白时间比较长，所以建议有些逻辑功能要根据实际情况去决定是前端还是后端处理。 296 2973、最终成果 298 299项目代码结构基本上有一个统一的风格；各模块页面也有了统一的风格；用户体验较好；也方便了开发和维护。 300 301总结： 302 303一个人走得更快，一群人可以走得更远。统一规范的最根本目的是为了保证团队成员的一致性，从而减少沟通成本，提高开发效率。学会热爱标准，但要确保它们不是一成不变的。如果制定的规范不适合您的团队，请确保可以适应和重写所需要的任何规则。它并不是要强制执行一种工作方式，而是为了帮助促进团队之间的互动。