一个好的程序员必须能够编写可维护的代码，而不是一次性代码。你怎么能让团队里的其他人，甚至过段时间的你，看你某个时期写的东西？你还能看懂代码吗？这涉及标准化您的代码。一、代码标准化的好处1、从根本上降低开发成本：提高代码整体的可读性、可维护性和复用性。2.确保代码一致性：软件系统中最重要的因素之一是代码一致性。如果编码风格一致，也更容易维护，因为团队中的任何人都可以快速理解和修改。3.提高团队的整体效率：开发人员通常需要花费大量时间来解决代码质量问题。如果按照规范来写，也有助于团队尽早发现问题，提高整个交付过程的效率。二、代码不规范的缺点1、增加团队成员协作的负担：由于不规范，导致代码风格不一。在极端情况下，只有一个人可以修改某一段代码。2.团队之间的协作更加困难：由于开发人员必须适应不同的风格，这会导致效率低下。3、复习困难：复习期间，可能经常会有太多关于类似事情的讨论。4、影响和降低团队的整体效率：影响团队的生产力和素质，甚至严重影响团队的和谐。三、为什么很多团队缺乏规范1、当开发人员被要求在短时间内完成任务时，他们通常会回避质量标准。2.长期养成的开发习惯很难在短时间内改变。3.有时即使达成了协议，发展还是我行我素。4.规格包括哪些内容？我们平时理解的前端开发规范，更多的是编码层面的规范，其实远不止这一种。例如技术栈规范、浏览器兼容规范、项目文件结构规范、UI设计规范、前后端协同规范等。下面从这六个方面对前端开发规范做一个简单的介绍。1.技术栈规范目前前端主要有3种框架：Vue、React和AngularJS。每一个框架背后都有一个架构和一个生态。每个框架背后都涉及开发思维、生态系统、配套工具、最佳实践和性能调优。精通和精通一个框架的成本是非常高的。因此，团队的开发效率建立在稳定、熟练的技术栈之上。稳定的技术栈规范，有利于团队协作和沟通；另外，如果团队精通这个技术栈，出现问题或者需要深度调优的时候会相对容易一些。前端技术栈规范主要包括以下几种：①编程语言——Typescript或Javascript。②UI框架及其配套生态（路由、状态管理、组件库、国际化、动画、服务端渲染、脚手架、CLI工具、组件测试等）。③风格。命名约定、预处理器等。④动画引擎。⑤项目建设工具流程。网页包，vue-cli。⑥包管理器。npm，纱线。⑦开发工具、工具库（moment.js）、版本管理（gitlab）等2.浏览器兼容性规范前端团队应根据应用所面临的用户情况、应用程序等因素制定自己的浏览器兼容性规范类型、开发成本和浏览器市场统计数据。但是，确定哪种兼容策略应该取决于用户的比例。如果大多数用户使用现代浏览器，应该使用优雅降级为现代浏览器提供最佳体验，而旧浏览器应该回退，保证功能近似，否则选择渐进增强，保证低版本浏览器的体验，为支持新特性的新浏览器提供稍微好一点的体验。有了浏览器兼容性规范，前端开发和兼容性测试有据可依，避免纠纷；同时也是前端团队的对外声明。除非有特殊要求，前端开发者可以选择忽略。我们还可以根据浏览器市场分布、用户占比、开发成本等因素将浏览器分为多个等级。不同级别表示不同级别的支持：①完全兼容：保证100%正常功能。②部分兼容：只能保证功能、风格和要求大致一致。对于一些不影响主要需求和功能的BUG，将降低优先级或不予处理。③不相容：不考虑相容性。3.项目文件结构规范主要包括项目命名、项目文件结构、版本号规范等。下面简单列举一类项目文件结构：①README.md：项目描述。您可以在此处提供有关项目的关键信息或相关信息的条目。一般包括以下信息：简要说明，项目的主要特点；运行环境/依赖关系、安装搭建、测试指南；简单的示例代码；文档或文档条目、其他版本或相关资源条目；联系方式、讨论组；许可、贡献/开发指南。②CHANGELOG.md：放置各个版本的变更内容，通常描述各个版本的变更内容。方便用户确定应该使用哪个版本。③package.json：前端项目必须描述当前版本、可用命令、包名、依赖、环境约束、项目配置等信息。④.gitignore：忽略不需要的文件，避免将自动生成的文件提交到版本库。⑤docs/：项目的详细文档，可选。⑥examples/：项目示例代码，可选。⑦build：项目工具脚本放在这里，不是必须的。如果你使用unity构建工具，则没有这个目录。⑧dist/：工程构建结果输出目录。⑨src/：源代码目录。-src开发目录-页面视图-module-amoduleA-components私有组件-ComA.tsx-ComB.tsx-index.module.less-index.tsx-Content.tsx-module-bmoduleB-components公共组件-index.tsexportallcomponents-header-index.tsx-index.module.less-User.tsx-useGetBaseInfo.hooks.ts-routers路由文件-将数据存入redux-utils这里后缀为utils-index.ts-a.utils.ts-b.utils.ts-hooks这里是hooks的后缀-index.ts-a.hooks.ts-b.hooks.ts-styles静态资源文件-服务api请求，这里是api的后缀-a.api.ts按照后端微服务划分-b.api.ts-constans常量⑩tests/：单元测试目录。?tests：全局测试目录，通常用于应用集成测试或E2E测试。?.env*：在项目中，我们通常会使用环境变量来影响应用程序在不同运行环境下的行为。可以通过dotEnv从文件中读取环境变量。通常有三个文件：env公共环境变量；env.development开发环境的环境变量；生成环境的env.production环境变量。4.编码标准每个程序员对“好代码”都有自己的看法。统一的编码标准可以避免不必要的争论和争议，有利于团队项目的长期维护。一致的代码规范可以提升团队开发协作效率，提升代码质量，减轻系统维护负担。下面主要从HTML、JS、CSS、代码格式四个方面讨论编码标准：①HTML规范使用HTML5的文档声明类型：DOCTYPE标签是一种标准的通用标记语言的文档类型声明，以及它的目的是告诉标准GML解析器应该使用什么文档类型定义(DTD)来解析文档。使用文档声明类型的目的是防止浏览器怪癖被打开。如果没有DOCTYPE文档类型声明，就会启用浏览器的怪异模式，浏览器会按照自己的解析方式渲染页面，在不同的浏览器下会出现不同的样式。如果你的页面添加了，就相当于开启了标准模式。浏览器会根据W3C标准解析和呈现页面。详细规范可以查看：https://img.ydisp.cn/news/20220902/jk4b1xkqjewJS规范函数变量命名，代码注释等，主流的JS/TS一般有这几种：AirbnbJavaScriptStyleGuide：https：//github.com/airbnb/javascriptGoogleJavaScript风格指南：https://google.github.io/styleguide/jsguide.html]地道的JavaScript风格指南：https://github.com/rwaldron/idiomatic。jsJavaScript标准风格指南③CSS规范ID和类命名，ID的合理使用，避免在css选择器中使用标签名，使用子选择器，尽量使用缩写属性等，具体可以参考以下网址：AirbnbCSS/SassStyleguide:https://css-tricks.com/bem-101/CodeGuide:https://img.ydisp.cn/news/20220902/zg0e2ktf4ya代码格式规范由于每个开发者的IDE不同，即使IDE是一样的，由于每个devel的配置不同，格式化的结果会不一样操作。如何保证团队中的开发人员采用统一的格式配置？这里推荐大家使用prettier，它内置了一套格式化规则，具体可以参考以下网址：https://prettier.io/5。UI设计规范UI规范最大的好处是可以提高质量和效率：①从开发者的角度，研发资产与设计规范同步形成，避免重复造轮子；②从测试的角度，可以避免重复毫无意义的演练；③从UI设计师的角度，降低设计成本，提高设计效率，能够快速承接新的需求；④从产品的角度，可以提高产品迭代优化的效率，降低试错成本；⑤从用户的角度，解决用户体验的一致性。如果团队不打算制定自己的UI设计规范，建议使用现成的开源组件库：AntDesign、ElementUI、iView、WeUI等。6.前后端协同规范时间也比较长。一个常用的前后端协同流程：①需求分析。参与者一般有前后端、测试、产品。由产品主持，解释需求，接收开发和测试的反馈，保证大家对需求的理解一致。②前后端开发探讨。讨论应用程序的一些开发和设计，交流技术要点、难点和分工。③设计接口文件。可以前后端一起设计；也可以由后端设计，前端确认是否符合要求。④并行开发。前端和后端并行开发。这个阶段前端可以先实现静态页面；或者根据接口文档Mock接口，模拟对接后端接口。⑤前后端接口联调。五、前端开发规范举例1、项目情况多人开发同一个项目的不同模块；因为开发前没有规范，每个人的代码都是单独的样式；当其他人修改代码时，他们需要熟悉不同的模块。样式代码浪费了很多阅读代码的时间；而且因为没有全局的样式规范，所以每个人都有自己的样式。如果后期要做统一的界面样式，大家需要修改样式代码，增加很多工作量。2.制定规范根据项目的实际情况，既然项目已经开发到一定程度，选择了开发框架，那么就可以在编码和UI设计方面进行规范。由于项目是管理系统，可以统一前端UI的页面结构；可制定风格统一的模板，开发时可直接使用模板代码进行自适应修改；由于没有统一的样式标准，导致后期统一样式需要花费大量时间，所以进行统一样式分离，提取公共CSS样式供参考，方便后期统一修改;因为有些变量和函数的命名过于简单，比如a、b、c等，规范使用了更多的语义，便于理解和阅读；因为在项目开发中前后端是同一个人开发的，所以把一些可能是后端的工作放到了前端去处理。比如分页功能，虽然这个可以前端和前端都做，但是如果用前端来分页，就需要一次返回所有的数据。当数据量很大时，界面可能会返回很慢，导致页面空白时间很长。因此，建议一些逻辑功能根据实际情况由前端或后端处理。3.最终结果项目的代码结构基本具有统一的风格；每个模块页面也有统一的风格；用户体验更好；也方便开发和维护。总结：一个人可以走得更快，一群人可以走得更远。统一规范最根本的目的是保证团队成员的一致性，从而降低沟通成本，提高开发效率。学会热爱标准，但要确保它们不是一成不变的。如果您制定的规范对您的团队不起作用，请确保您可以调整并推翻所需的任何规则。它并不是要强制执行一种工作方式，而是要帮助促进团队之间的互动。
