将 CI 添加到现有软件中

如果你在一家公司工作，你不会总是从零开始，即从头开始建立一个新项目。事实上，最有可能出现的情况恰恰相反：当你加入一家公司时，你将加入一个已经在一个或多个项目上工作了很长时间的团队。

你可能已经接触过遗留软件或遗留系统这些术语。在我们的语境中，它们指的是存在已久、仍在关键业务流程中使用的软件。它们不再符合现代开发标准，因此无法轻易更新或更改。随着时间的推移，它变得如此脆弱和难以维护，以至于没有开发人员愿意再碰它。更糟糕的是，由于系统发展的时间较长，它的功能已经多到没有任何利益相关者（即用户）愿意错过的地步。因此，替换遗留系统并非易事。

不难理解，遗留软件有着不好的含义，但系统需要的可能只是一些 "关注"。想想看，这就像修复一台旧机器，用现代零件替换旧零件，而外观却保持不变。有些开发人员甚至认为，开发这样的软件具有额外的挑战性。这些软件已经走过了漫长的道路，赚到了钱，而且很可能（至少部分）为公司的成功做出了贡献，因此值得尊重。

因此，如果你必须参与这样一个项目，请不要轻易放弃。通过这本书，我们为你提供了必要的知识和工具，让你开始重新塑造它—​只是需要更长的时间，而且你可能永远无法达到完美的水平。但无论如何，完美是没有必要的。

一步步

从添加集成测试和 E2E 测试开始。这两种测试类型通常不需要或只需要对代码进行少量修改，但却能带来巨大的好处，因为它们可以间接覆盖大量代码，而无需编写单元测试。一旦通过测试覆盖了应用程序的关键路径（即最常用的工作流），就可以开始重构类并引入更多的单元测试。这些测试将帮助你快速发现错误和副作用，而无需反复点击应用程序。

正如你现在所知道的，引入 PSR-12 这样的代码风格就像在整个代码库中运行 PHP-CS-Fixer 这样的工具一样简单。当然，由此产生的提交将是巨大的，因此在此之前，你需要与其它开发人员达成代码冻结协议。代码冻结意味着每个人都将自己的改动提交到版本库中，这样当他们检查出改动后，你的重构就不会造成巨大的合并冲突。

为了决定哪些代码需要重构，我们打算使用一个或多个你现在已经知道的代码质量工具。在 0 级使用 PHPStan 是一个不错的选择。你也可以考虑使用 Psalm，因为它也能自动解决一些问题。根据项目的规模，错误列表可能会很长，让人望而生畏。使用第 7 章（代码质量工具）中介绍的基线功能可以起到表面帮助作用，但它只能隐藏而不能解决代码问题。

你不必操之过急。如果将 CI/CD 管道配置为只检查修改过的文件，就可以开始逐步改进代码。但这也会给你带来一个问题，那就是一旦你接触了一个文件，你就必须重构它以符合规则。特别是对于古老但庞大的类，这可能会造成问题。不过，在第 7 章 "代码质量工具 "中，我们介绍了如何将文件或部分代码排除在执行的检查之外。你甚至可以设置一个管道，允许你在提交消息中使用特定的关键字（例如，skip ci）来跳过检查。不过，这种方法只能作为最后的手段，否则，你将永远无法开始重构旧代码。开发人员也需要自我约束，避免滥用这一功能。

随着时间的推移，参与项目的团队会积累新的信心，随着测试覆盖率的增加，他们会开始重构越来越多的代码。确保安装本地管道，缩短等待时间。