技术债：

我们在CI/CD中也会加入检查。

• 历史代码债务严重：项目已经迭代了多年，代码库非常庞大，存在大量不同时期、不同开发者编写的代码，风格迥异，缺乏统一的规范。

• 低级错误频发：很多本可以在编码阶段就发现的问题，比如未使用的变量、错误的语法、不一致的格式等，都流到了 Code Review 甚至测试阶段，浪费了团队大量的时间和精力。

• 代码冲突率高：尤其是在合并一些大型功能分支时，由于格式不统一，经常出现大量无意义的格式化冲突，增加了合并代码的难度和风险。

• 推行规范阻力大：我们曾尝试过直接引入全量的 Lint 检查，但一次性暴露了成千上万的错误。这对于正在快速迭代的业务来说是不可接受的，因为修复这些问题会完全阻塞正常的开发进度，所以这个方案很快就被放弃了。

lint-stage原理：

• 这东西会执行git命令，获取git的暂存区涉及到的文件列表。

• 妈的，这东西的原理就是git的暂存区，我想到了但是不知道咋表达。

如何量化40%的成果：

• 代码冲突：我们主要统计的是向 develop 分支发起的 Pull Request (或者叫 Merge Request) 中，出现需要手动解决（Manual Resolve）的合并冲突的频率。

• 统计对象： 在代码被合并到主分支之前，CI/CD 流水线中的 Linter 和 TypeScript 编译器所报告的 error 或 warning 的数量。