前端团队前端开发规范的落地实践

前端团队前端开发规范的落地实践本站　　早期团队较小的时候，没有太多规范，遇到问题用自己最擅长的方式去解决就行

　　早期团队较小的时候，没有太多规范，遇到问题用自己最擅长的方式去解决就行。随着公司发展，团队越来越大，因为没有统一规范而造成的问题也越来越多，例如

　　基于这些问题制定了一个前端开发规范，经过实践，达到了预期的效果。接下来会具体介绍下前端开发规范

　　其中每个大类下，又包含若干个小分类。本文中，我会详细的介绍下一些重点的规范以及其内容，对于非重点的，待后续我们把文档开源到Github上，大家可以自行查阅。

　　使用localforage来实现本地存储，该库会优先使用IndexedDB以扩大本地存储空间，并采用优雅降级方案，处理了异常情况。

　　常见的错误处理方法有：清理过期数据并重试一次；转存至sessionStorage、自定义的全局对象myStorage、Vuex等，但记得在读取时也依次读取。

　　// TODO: 这里还需要做什么// FIXME: 这里的实现有问题，以后需要优化// HACK: 这里的处理是为了兼容低端安卓机的 bug

　　团队应该根据的用户设备占比情况、应用类型、开发成本、浏览器市场统计数据等因素，来制定自己的浏览器兼容规范，设备兼容规范如下

　　Prettier是一个代码格式化工具。在风格统一方案中，Prettier和ESlint配合使用，但是Prettier和ESlint的规则是有冲突的，我们做了很多的努力，尽量保持配置规则的一致性。但是还是有冲突的地方。

　　选择以ESlint为主，所以在修复错误的时候，是Prettier先格式化一遍，ESlint再修复一遍，最终检查以ESlint为准。所以如果遇到无法解决的错误，直接修改ESlint的配置就可以。

　　在团队中代码提交git commit会有各种各样的风格，甚至有些人根本没有commit规范的概念，所以在我们回头去查找在哪个版本出现问题的时候，就会非常尴尬，很难快速定位到问题。为了项目的规范化，代码提交规范就显得尤为重要！

　　规范名描述feat新增 featurefix修复 bugmerge合并分支docs仅仅修改了文档，比如 README, CHANGELOG, CONTRIBUTE 等等chore改变构建流程、或者增加依赖库、工具等perf优化相关，比如提升性能、体验refactor代码重构，没有加新功能或者修复 bugrevert回滚到上一个版本style仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑test测试用例，包括单元测试、集成测试等

　　上面说了一些常规的开发规范，对于不同类型的项目Vue、Vue SSR、React、小程序等等，都有着不同的规范，接下来我会以Vue项目为例来继续说说开发规范

　　ESLint属于一种QA工具，是一个ECMAScript/JavaScript语法规则和代码风格的检查工具，可以用来保证写出语法正确、风格统一的代码。ESLint旨在完全可配置，它的目标是提供一个插件化的javascript代码检测工具。ESlint配置基于Standard规则的基础上做了特定的修改。

　　侵入项目，虽然前端实际工作中一直以对业务无侵入为研究方向。但在实际的业务中偶尔的侵入业务去做一些处理是很有必要的，给业务带来的收益也是可观的，我们能做的就是尽量少的侵入业务代码，导致污染。以下是我们对项目的改造策略：

　　以上方案不止能有效捕获错误，区分错误级别，还能有效防止子组件错误影响整体页面渲染，导致白屏，简直一举两得。

　　到这里，前端开发的核心主要规范就介绍完了，对于不同类型项目会有不用的规范，大家可以根据业务实际情况，制定属于自己的团队的开发规范~