前端为什么需要规范
规范能给我们带来什么好处，如果没有规范会造成什么后果？这里主要拿代码规范来说。
统一代码规范的好处：
- 提高代码的整体品质：统一的代码规范能够显著提高代码的可读性、可维护性、可复用性、可移植性和可靠性。这从根本上有助于降低开发成本，是非常关键的一点。
- 确保代码一致性：在软件系统中，编码的一致性是非常重要的。如果编码风格统一，团队成员在维护时都能快速理解并进行修改。
- 提升团队效率：开发人员经常需要花费大量的时间来解决代码质量问题，如果都按照规范编写，有助于团队尽早发现并预防问题，从而提高整个交付过程的效率。
- 减少Code Review争议：缺乏标准会在Code Review期间导致很多关于格式和风格的争议，这浪费了宝贵的时间。
若不统一代码规范，可能产生的后果：
- 代码风格混乱：由于缺乏规范，代码风格不统一，增加团队成员间的心理负担。在极端情况下，某段代码可能只有某个人能够进行修改。
- 团队合作困难：因为开发人员需要适应不同的风格，会导致效率降低（阅读代码是我们花费时间最多的地方）。
- Code Review效率降低：可能会经常为类似的事情进行多次讨论。
- 影响团队生产力和质量：严重时甚至会影响团队的和谐氛围。
为什么依然有很多团队缺乏规范
在这方面，达成一致很难是我认为的最主要原因。此外，仅仅拥有规范也是不够的：
- 当开发人员在短时间内被要求完成任务时，通常会回避质量标准。
- 团队中的某些个体可能不愿为了团队而改变自己的习惯。
- 有时在会议上达成的共识，在实际操作时往往会被忽视。
- ...
如何维护和执行规范
尽管尝试过通过会议的方式来达成规范，实际效果并不理想。失败的原因可以归纳为以下几点：
- 会议中，讨论容易偏离主题，虽然讨论了很多内容，但很难产生实质性的成果。在开发过程中，仍有人选择忽略已定规范。
- 定期的正式会议难以组织，因为团队成员难以找到共同的空闲时间。
- 在会议中，即使对实际案例进行了分析并提出了优化建议，也未能明确问题的优先级，导致实际执行效果不佳。
- 组织会议方面存在提升空间。
经过深入的反思和总结，决定采取以下策略：
- 对规范问题进行详细的分析，并通过文档（如wiki）进行记录，参考业界的最佳实践，并在团队中推广。
- 采取“小步快走”的策略，根据问题的优先级和重要性进行分类，并在每个迭代中解决其中的关键问题。
- 保证每个迭代中的规范问题在该迭代中得到解决，避免问题积累。
- 在code review中严格执行规范，确保代码质量。
- 当团队成员对某个规范有异议时，及时进行讨论并达成共识。
- 规范的制定不应仅仅为了有规范，而是为了团队的统一和效率。
- 鼓励团队成员对规范提出质疑，任何不能提高代码质量的规范都应受到挑战。
- 作为团队领导，应带头遵守和执行规范，确保团队的方向始终正确。
开发者应遵循的规范可以分为以下几个方向：
- 开发流程规范
- 代码规范
- git commit规范
- 项目文件结构规范
- UI设计规范
对于开发流程规范，虽然通常由项目经理来定，但开发者也有责任掌握。无论是传统的开发模式还是敏捷开发模式，开发者的核心任务始终是高效地满足用户需求。
有时，开发者在收到需求后立即开始编码，试图展现效率。但由于对需求的理解不足和代码设计的不足，这往往导致了高bug率和重复劳动。
找到适合的开发流程需要经验和不断的反思，目标是高效且高质量地完成任务。
下图是常用的流程规范
2. 代码规范之格式化规范
由于每个开发者的IDE不同，即使IDE相同也会因为每个人的配置不一样导致格式化的结果不一样。如何确保团队内开发人员采用统一的格式化配置呢？
这里给推荐大家使用 prettier，它内置了一套格式化的规则，具体配置：
1). 安装依赖：
npm install --save-dev --save-exact prettier
// or
yarn add --dev --exact prettier
复制代码
2). 创建一个空配置文件，让编辑器和其他工具知道你正在使用 Prettier：
echo {}> .prettierrc.json
复制代码
3). 创建一个.prettierignore文件，让 Prettier CLI 和编辑器知道哪些文件不能格式化，example：
# Ignore artifacts:
dist
build
coverage
复制代码
4). 配置编辑器（VScode为例）
IDE中安装 Prettier-Code Formater 插件：
找到IDE中设置模块，搜索 format On Save，勾上这个就可以了。
现在当我们 Ctrl + S 保存代码时，插件就会帮助我们自动格式化了。
这里有小伙伴要问了，要是有人将没有格式化的代码提交上去怎么办？
这时候就需要在 git commit 的阶段自动将提交的代码进行格式化，这里我们借助工具 husky，它主要可以帮助我们在 git 阶段检查提交消息、运行测试、检查代码等。没接触过的小伙伴可以去官网了解一下，配置如下：
- 安装 husky 和 lint-staged：
npm install --save-dev husky lint-staged
npx husky install
npm set-script prepare "husky install"
npx husky add .husky/pre-commit "npx lint-staged"
// or
yarn add --dev husky lint-staged
npx husky install
npm set-script prepare "husky install"
npx husky add .husky/pre-commit "npx lint-staged"
复制代码
- 然后将以下内容添加到
package.json中:
{
"lint-staged": {
"**/*": "prettier --write --ignore-unknown"
}
}
复制代码
这段配置的意思是：当执行 git commit 阶段前，先执行lint-staged，lint-staged中的内容就是对暂存区的文件执行格式化的命令。
其他：若使用的是脚手架工具搭建的项目，会自带eslint配置（eslintConfig）。prettier 和 eslint 会有一些配置上的冲突，这个时候需要安装eslint-config-prettier 以使 ESLint 和 Prettier 相互配合，安装完后在.eslintrc中配置（Vue App为例）：
"eslintConfig": {
extends: ['eslint:recommended', 'plugin:vue/vue3-essential', 'plugin:prettier/recommended'],
},
复制代码
这样就可以用"prettier"的部分规则覆盖前面的规则，让它们都能正常工作。
