二、先决条件
在我们开始现代化我们的应用程序之前，我们需要确保我们有必要的先决条件来进行重构工作。这些措施如下：
- 版本控制系统
- 5.0 或更高版本的 PHP
- 具有多文件搜索和替换功能的编辑器或 IDE
- 某种文体指南
- 测试套件
版本控制
修订控制（也称为源代码控制或版本控制）允许我们跟踪先决条件：修订控制“我们对代码库所做的更改。我们可以进行更改，然后将其提交给源代码管理，进行更多更改并提交，并将更改推送到团队中的其他开发人员。如果发现错误，我们可以恢复到代码库的早期版本，直到错误不存在，然后重新开始。
如果您没有使用诸如 Git、Mercurial、Subversion 或其他版本控制系统之类的源代码管理工具，那么这是您需要做的第一件事。使用源代码管理将对您有很大的好处，即使您根本没有更新 PHP 应用程序。
在许多方面我更喜欢 Mercurial，但我认识到 Git 的应用更广泛，因此我必须向源代码管理系统的新用户推荐 Git。
虽然讨论如何设置和使用源代码控制系统超出了本书的范围，但有一些好的 Git 书籍和 Mercurial 书籍是免费提供的。
PHP 版本
为了先决条件：PHP5.0“应用本书中列出的重构，我们至少需要安装 PHP5.0。是的，我知道 PHP5.0 很古老，但我们这里讨论的是遗留应用程序。完全有可能企业主多年来没有升级他们的 PHP 版本。PHP5.0 是最低要求，因为那时类自动加载可用，我们依赖于自动加载作为我们的 v 这是我们的第一个改进。（如果出于任何原因，我们被困在 PHP4.x 上，那么这本书将没有什么用处。）
如果我们能成功，我们应该升级到最新版本的 PHP。我建议您使用所选操作系统可用的最新版本的 PHP。在本书最新更新时，最新版本是 PHP5.6.11、5.5.27 和 5.4.43。
从较旧的 PHP 版本进行升级本身可能需要修改应用程序，因为 PHP 的次要版本之间会发生更改。注意细节：检查版本和所有中间版本的发行说明，查看代码库，发现问题，进行修复，在本地进行抽查，提交，推送，并通知 QA。
编辑/IDE
贯穿先决条件：编辑器/IDE 本书，我们将在遗留代码库中进行大量搜索和修改。我们需要一个文本编辑器或 IDE，它允许我们一次查找和替换多个文件中的文本。这些措施包括：
- Emacs
- PHPStorm
- 崇高文本
- TextMate
- 维姆
- 泽德工作室
可能还有其他人。
或者，如果我们的 CLI 功能强大，我们可能希望在命令行中同时跨多个文件使用 grep 和sed。
风格指南
使用一致的先决条件：风格指南“在中编码风格”代码库是一个重要的考虑因素。我所看到的大多数遗留代码库都是不同作者喜欢的样式。这种类型的 MISHASH 的一个例子是将代码块和空格用于缩进代码块的混合：项目早期的开发人员使用了 2 个缩进空间，开发人员在项目中间。使用制表符，最近的开发人员使用了 4 个空格。这产生了这样的效果将一些子块完全排除先决条件：样式指南“与父块对齐，要么缩进太多，要么缩进不够，使得难以扫描块的开头或结尾。
我们都渴望一种一致的、熟悉的编码风格。很少有比将不熟悉或不想要的编码样式重新格式化为更可取的样式更强烈的冲动了。但是，修改现有样式，不管它有多么丑陋或不一致，都可能导致细微的错误和行为变化，而这些错误和行为变化很简单，比如在条件语句中添加或删除大括号。同样，我们希望代码是一致的和熟悉的，以便我们能够以最小的认知摩擦来阅读它。
在这里很难给出好的建议。我建议修改现有样式的唯一原因是当它在单个文件中不一致时。如果它丑陋或不熟悉，但在整个代码库中保持一致，那么重新格式化可能会导致比它解决的问题更多的问题。
如果您决定重新格式化，请仅在将代码位从一个文件移动到另一个文件时，或者在将文件从一个位置移动到另一个位置时进行。这将提取和重新定位的巨大变化与样式修改的更细微变化结合起来，并使在一次过程中测试这些变化成为可能。
最后，您可能希望转换为全新的样式，即使现有样式在整个代码库中是一致的。抵制这种冲动。如果您想要以 toto 格式重新格式化的愿望是压倒性的，并且不能忽视，那么请使用公开记录的非项目特定的编码样式，而不是尝试创建或应用您自己的个人或项目特定的样式。本书中的代码使用 PSR-1 和 PSR-2 风格的建议作为该建议的反映。
测试套件
因为这是一本关于遗留应用程序的书先决条件：测试套件，所以它期望代码库有一套单元测试是非常乐观的。大多数遗留应用程序，尤其是面向页面的应用程序，对单元测试有很高的抵抗力。没有要测试的单元，只有大量紧密耦合的功能。
然而，测试遗留应用程序是可能的。这里的关键不是测试系统单元应该做什么，而是测试系统作为一个整体已经做了什么。成功测试的标准是系统在更改后生成与更改前相同的输出。这种测试称为表征测试。
本书不讨论如何编写特性测试套件。已经有一些很好的工具可以编写这类测试，比如 Selenium 和 Codeception。在重构代码库之前进行此类测试是非常宝贵的。我们将能够在每次更改后运行测试，以确保应用程序仍能正常运行。
我不会假装先决条件：测试套件“我们可能会花时间编写这些类型的测试。如果我们开始对测试感兴趣，我们已经有了某种类型的测试套件。这里的问题是一个非常人性化的问题，不是为了做正确的事情，甚至不是为了理性的期望，而是基于奖励的激励。编写测试的奖励是长期的，而只是改进现在，即使我们不得不手动检查应用程序输出，对代码库进行 ent 也会立即感到有价值。
如果您有时间、自律和资源，最好的选择是为您知道要重构的应用程序部分创建一系列特性测试。这是最负责任和最专业的方法。作为第二个最好的选择，如果您的 QA 团队已经准备好了一系列应用程序范围的测试，那么您可以将测试过程委托给他们，因为他们无论如何都在这样做。也许它们会向您展示如何在您更改代码库时在本地运行测试套件。最后，作为最不专业但最有可能的选择，在进行更改时，您必须手动对应用程序进行伪测试或抽查。不管怎么说，这可能是你已经习惯了的。随着代码库的改进，改进您自己的实践的回报将变得更加明显；与一般的重构一样，我们的目标是以较小的增量使事情变得比以前更好，而不是坚持立即实现完美。
回顾和下一步
此时，我们应该准备好所有的先决条件，特别是我们的版本控制系统和现代版本的 PHP。现在我们可以从重构的第一步开始：向代码库添加自动加载程序。
版权属于：月萌API www.moonapi.com，转载请注明出处
