note: 补充笔记

Author: ZhouQiJun

前端项目问题以及改进方案.md

@@ -171,3 +171,83 @@ app.mount('.app-mounted-root')
 您作为公司的架构师，对这些问题会有更深入全面的看法，希望能多多帮助推动这些问题的解决。
 
 能让前端团队认识到以上问题的危害，代码风格和质量对协作的重要性，**最好能综合前端同事的一些意见，在认知上达成统一，制定前端项目可实施的质量标准，并结合上面我提到的两个工具自动化地落实。**
+
+### 目前没有强制统一风格，文件改动会可能会经历这样的典型过程：
+
+```bash
+a.js # A 同事编写的 风格A
+b.js # B 同事编写的 风格B
+c.js # C 同事编写的 风格C
+```
+
+修复一个 bug，B 同事改动了 a.js
+
+```bash
+a.js  # B 同事改动，风格变成 B，可能有大量格式上的改动
+```
+
+又修复一个 bug , A 同事改动 a.js
+
+```bash
+a.js  # A 同事改动了，风格又变成 A，可能有大量格式上的改动
+```
+
+新增一个功能，D 同事新增一个文件：
+
+```bash
+d.js # D 同事新入的代码，风格是 D
+```
+
+修复一个 bug， B 同事去改动了 d.js：
+
+```bash
+d.js # B 同事改动，风格变成 B
+```
+
+可看到，不强制统一风格，已经存在的文件，会随着代码改动，风格越来越乱；
+
+新增的文件，不同的人也有不同的风格；
+
+所以，风格不一致引发的协作问题，没有解决，反而会越来越严重。
+
+### 强制统一风格后，不管谁来改动文件，代码风格最多有一次变化，此后谁来改动，都一致
+
+统一风格后，文件改动可能会经历这样的过程：
+
+```bash
+a.js # A 同事编写的 风格A
+b.js # B 同事编写的 风格B
+c.js # C 同事编写的 风格C
+```
+
+修复一个 bug，B 同事改动了 a.js
+
+```bash
+a.js  # B 同事改动，风格变成 W，可能有大量格式上的改动
+```
+
+又修复一个 bug , A 同事改动 a.js
+
+```bash
+a.js  # A 同事改动，风格还是 W
+```
+
+新增一个功能，D 同事新增一个文件：
+
+```bash
+d.js # D 同事新入的代码，风格是 W
+```
+
+修复一个 bug， B 同事去改动了 d.js：
+
+```bash
+d.js # B 同事改动，风格还是 W
+```
+
+统一风格后，代码风格会随着文件的改动，逐渐统一，**一个文件最多发生一次风格上的变化，此后风格都一样了**，所以代码风格引发的协作摩擦也会越来越少，逐渐消除了。
+
+> 不会特意去格式化老文件，而是需要修复 bug 了，才去改动，此时改动，会引发一次格式上的变化，但是此后不管谁来改动，格式都是一致。
+
+> 风格的统一，引入 bug 的可能性非常低。又因为有 bug 才去改动老文件，会经历测试的过程，因此引发 bug，也会发现。
+
+> 格式化引发 bug，我从来没遇到过，除非像 uniapp ，使用特定的注释，作为条件编译的情况。