引入或执行新的内衬或其他代码质量工具规则的策略

Question

我所处的情况是，有一个具有TypeScript和ESlint的代码库，但是：

• 有很多类型错误(尽管使用Babel存在错误，但代码编译)
• 有很多棉质警告。
• 我们可能需要引入一些新的lint规则来解决我们所遇到的一些特殊问题(例如，循环依赖确实导致了一个问题，因此引入import/no-cycle规则来防止它)。

我们现在正在引入一个构建管道，这样我们就可以防止人们提交错误的代码--但问题是，代码已经无法通过CI质量检查。

我们不能像现在这样在类型错误上失败，我们需要首先修复所有的类型错误。

在不妨碍我们同时使用代码的情况下，采取什么最佳策略来执行代码质量呢？

以下是我试过或考虑过的一些事情：

• 大沙邦现在把所有的错误都清理干净。
  • 这是很多工作。特别是在整理类型错误之后，您可能最终会重构一些东西，然后破坏一些东西。
  • 此外，这也不像“大沙邦”的做法是你“只需要做一次”。例如，补充说，无周期规则将需要另一个大沙邦清理修复进口。

• 使用像哈士奇和林特这样的工具来加强你所接触到的文件的代码质量。
  • 我遇到的问题是让开发人员直接使用--no-verify，然后当人们把主人拉进他们的分支时，他们就会得到所有的错误。
  • 诚然，这是一个只在dev的机器上执行代码样式的问题--大概有一个工具可以在CI服务器上执行‘只对您所接触的文件执行代码质量’的工具。

• 保持一个忽略名单-.把规则放进去，但是保留一个‘这些是当前被破坏的文件’的列表，并慢慢地减少它。
• 这篇文章建议您列出理想的皮棉规则，但在代码基准备好之前将其关闭。
  • 本质上，这是一系列“大沙邦”的解决方案。我不知道这对于类型错误是如何工作的。

是否有经过很好测试的策略来解决这个问题？

Answer 1

本质上，您需要的是一个系统来验证您的代码至少是坏的，因为它没有添加新的修改来增加违反规则的行为。有一些办法来执行这一点：

1. 检查违规事件的数量并核实这些行为不会在合并时增加。
2. 在代码评审阶段进行检查。
3. 做小披肩。所有规则关闭，您激活一个并修复所有违反该规则，您已经有一个将使构建在未来失败。
4. 组合1和3。激活1条规则，检查违规次数，确认合并后该数目是否减少(或不增加)。当该规则有0次违规时，您将转到下一次。

请记住，您需要有一个系统来执行这一点，并有一个团队希望这种情况发生。

Answer 2

听起来你的想法是正确的，但是要提出一些具体的建议：

• 自动修复你能做的一切。ESLint有一个--fix选项，并且知道如何在整个代码库中自动修复许多违反规则的行为。使用它--它比手动修改要可靠得多，而且比开发人员一次花时间(手动或自动)修复一个文件要快得多。您可以在单独提交中一次自动修正ESLint规则，以帮助跟踪更改和减少风险。像细碎这样的工具可以方便一次自动修正一条规则。
• 使用哈士奇和皮棉使单个开发人员可以看到问题，并为解决问题提供鼓励和工具。这里有一些很好的文章：“渐进式JavaScript Linting”，使用亚麻花纹、哈士奇和预提交钩子来快速和早期地失败。一个缺点是，由于任何原因接触一个文件会导致Husky +lint- start开始抱怨该文件中的每一个违反规则的行为。您的目标是朝着一个积极的方向移动，而不影响开发人员的工作流或正在进行的开发；使开发人员感到，每当他们接触一个文件时，他们就必须修复所有与此相反的东西。在本例中使用--no-verify绕过钩子并向前推进是可以的。
• 设置您的CI以强制PRs不添加任何其他警告。这里的细节取决于您的CI系统；例如，SonarQube有一个质量闸门特性。我相信Jenkins的警告下一代插件可以区分新的警告和预先存在的警告。等。
• 作为“维护忽略列表”方法的一个变体，有一些工具可以帮助在粒度基础上自动维护忽略列表。(我第一次遇到这种情况是在Ruby的Rubocop的.rubocop_todo.yml中。在ESLint世界里，有精练-生成-待办。)就我个人而言，我对这种方法不太确定；我希望我的linting /代码质量尽可能少，所以添加一些步骤来维护一个忽略的文件似乎更难让开发人员参与进来。但至少值得注意。
• 使用更漂亮。将其设置为在编辑器/IDE中自动运行；在编程时能够完全忽略格式化和肤浅的编码风格，这是非常神奇的，并且在您访问Ctrl时，一切看起来都很棒。将ESLint设置为忽略任何更漂亮的手柄。通过消除ESLint担心任何格式或表面编码风格的需要，您可以让它专注于它真正擅长的地方，并且您可以减少在husky +林特阶段/ CI中需要担心的规则的数量。

Answer 3

我们在执行代码库上的一些规则时也遇到了类似的问题，这些代码库有很多遗留问题。

我们在主分支中使用合并请求。为我们工作的方法是，当合并请求包含对包含linter警告的行或函数的修改时，可以使用工具来指示。在这种情况下，CI管道是不会通过的(我们无论如何都可以合并，但这已经被证明是非常罕见的，因为devs不修复管道错误)。这样，每个合并请求都必须包含新的干净代码，或者在修改遗留代码时清除其他代码。

我们对这个系统感到非常高兴，因为它实际上是在我们的基础上执行渐进式的变革。唯一的负担是开发工具，使之能够比较线型警告线和修改行。