参加几个前端项目后，发现了一些能改进的问题，并提出了一些改进方案，希望能帮助提升项目的质量和效率，保证项目的可维护性。
代码风格不统一会导致代码难以阅读和维护。不同人可能有不同的编码习惯，导致代码风格混乱。
- 大家不敢合并代码，害怕引起冲突。
- 他人不在时，你修复一个紧急的 bug，他说风格又变了，自己又不习惯了，引发不必要的协作摩擦。
- 不方便追溯 git 历史，因为 commit 里可能有大量格式改动。
- 有的成员习惯不好，该缩进的不缩进，该换行的不换行，导致代码可读性差，难以维护。
- 代码风格不统一，当需要全局搜索，然后再替换的时候，会非常棘手。
该有空格的没有空格，单双引号混用。
当需要全局搜索的时候，不方便
优化后
优化后
264 列太长了，建议不要超过 100 列。 太长的行宽会导致代码难以阅读，编辑器出现横线滚动条，建议控制在 80-110 列之间。
业务代码和依赖导入混在一起，相互穿插，读起来头大。
更好的方式：
依赖导入放在文件最上方，且对不同来源的依赖进行按照距离远近分组，在依赖导入后才写代码。
美观一致的代码排版是可读性的基础，能有效提高代码可读性，降低认知负担，提高协作效率。
团队成员可能水平不同，或者细心程度不同，偶尔写错误语法。
type 拼写成 types。
把 js 数组的内置函数重置了。
希望组件 props 支持多种类型的数据，前两种是错误语法，第三种才是对的。
多了>。
代码异味虽然不算严重的问题，但是它非常容易引发 bug，也要引起重视，否则会导致代码难以维护。
13个参数，导致这个函数难以使用，有一个参数顺序不对，就可能导致 bug。
其他例子不再举例。
forEach 的第一次循序，把 顶部的 key 重置了，导致第二次循环出问题。
这个问题开发登录功能，导致前端后排查了挺久。
改进方案，统一采用 const 声明变量，除非需要再次赋值才使用 let，能避免变量意外重置导致 bug。
js 中需要再次重置变量的场景很少，正因为 let 变量存在这样的风险，很多代码规范都优先使用 const。
比如质量检查工具 eslint -- prefer-const
使用 const 就能有效避免这个问题。
为何不应该使用 id?
id 选择特异性很高，一旦写了很多样式，哪天需要重置样式，会非常棘手。
如何避免呢？不在项目使用 id，应用挂载使用类名：
// NOTE 不要使用 id 挂载应用，否则有人在 #app 选择器里写了很多样式，导致样式优先级过高，难以重置
// app.mount('#app')
app.mount('.app-mounted-root')在四预项目里看到过if 语句和循环语句，嵌套了 7 层，就不贴代码了。
当发现这些问题时候，我积极寻找解决办法，我建议这样改进：
- 项目里加入 prettier，在代码提交前执行 prettier，强制格式化代码，轻松实现统一风格。
新老项目都适用，因为他只会格式化提交的文件，即有修动的文件。对老项目而言，随着文件改动得越来越多，风格不统一的问题就逐渐缓解了。
- 新项目加入 eslint 质量检查
eslint 是前端项目常用的质量检查的工具，可以防止不好的编码实践，避免代码异味，从而保证团队的编码质量。
一些常见的代码异味，会自动修复，无法自动修复了，需要手动修复。
老项目也可以加入 eslint，可以设置在提交前对改动的文件进行检查，不会影响不改动的文件。但是可能会增加项目成员负担，因为已经存在的文件，可能有很多代码异味，需要手动修复。
当我提出这些问题和改进方案时，得到反馈非常消极，主要有四种：
- 公司代码的风格 10 多年了，熙哥都没统一过，我不能统一，不要自作聪明。
- 没必要统一风格，我喜欢自己的风格，各人的代码各人改。但是不可避免要去阅读和修改他人的代码，比如修复紧急bug。
- 不了解 prettier 和 eslint 这类保证代码质量的工具，认为统一代码风格和质量检查是无用功。
- 公司没要求，就没必要整这么复杂，有人从外面来公司，就是希望躺平，做一天和尚撞一天钟，不能要求别人什么质量怎样。这导致劣币驱逐良币。
以上问题在我们前端项目应该说是长久以来普遍存在的，也切切实实影响项目维护和协作，还会导致其他问题。
您作为公司的架构师，对这些问题会有更深入全面的看法，希望能多多帮助推动这些问题的解决。
能让前端团队认识到以上问题的危害，代码风格和质量对协作的重要性，最好能综合前端同事的一些意见，在认知上达成统一，制定前端项目可实施的质量标准，并结合上面我提到的两个工具自动化地落实。
a.js # A 同事编写的 风格A
b.js # B 同事编写的 风格B
c.js # C 同事编写的 风格C修复一个 bug，B 同事改动了 a.js
a.js # B 同事改动，风格变成 B，可能有大量格式上的改动又修复一个 bug , A 同事改动 a.js
a.js # A 同事改动了，风格又变成 A，可能有大量格式上的改动新增一个功能，D 同事新增一个文件：
d.js # D 同事新入的代码，风格是 D修复一个 bug， B 同事去改动了 d.js：
d.js # B 同事改动，风格变成 B可看到，不强制统一风格，已经存在的文件，会随着代码改动，风格越来越乱；
新增的文件，不同的人也有不同的风格；
所以，风格不一致引发的协作问题，没有解决，反而会越来越严重。
统一风格后，文件改动可能会经历这样的过程：
a.js # A 同事编写的 风格A
b.js # B 同事编写的 风格B
c.js # C 同事编写的 风格C修复一个 bug，B 同事改动了 a.js
a.js # B 同事改动，风格变成 W，可能有大量格式上的改动又修复一个 bug , A 同事改动 a.js
a.js # A 同事改动，风格还是 W新增一个功能，D 同事新增一个文件：
d.js # D 同事新入的代码，风格是 W修复一个 bug， B 同事去改动了 d.js：
d.js # B 同事改动，风格还是 W统一风格后，代码风格会随着文件的改动，逐渐统一，一个文件最多发生一次风格上的变化，此后风格都一样了，所以代码风格引发的协作摩擦也会越来越少，逐渐消除了。
不会特意去格式化老文件，而是需要修复 bug 了，才去改动，此时改动，会引发一次格式上的变化，但是此后不管谁来改动，格式都是一致。
风格的统一，引入 bug 的可能性非常低。又因为有 bug 才去改动老文件，会经历测试的过程，因此引发 bug，也会发现。
格式化引发 bug，我从来没遇到过，除非像 uniapp ，使用特定的注释，作为条件编译的情况。