后端开发规范(浅谈前端开发规范管理)

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