使用Laravel可以部分重构旧的大型PHP应用程序吗?

时间:2018-05-28 15:55:05

标签: laravel eloquent

从我读过的内容来看,由于Laravel的模块化特性,这应该是可能的,但我需要有更多Laravel经验的人的保证:

我有一个非常大的(500k loc)古老的PHP应用程序。如此古老,它的某些部分可以追溯到PHP3次(约2000年,PHP4已经发布,但PHP3用于向后兼容的原因)。

重构这是一个巨大的项目,合理地做到这一点的唯一方法是部分。替换此部分,然后替换该部分等。幸运的是,“古老”部分派上用场,因为没有使用框架,基本上每个页面都是自己的脚本,有一些用于共享功能的中央库。

是否可以启动一个可以将新/重构页面路由到新站点的Laravel应用程序以及其他所有内容(如果可能的话,通配符)到古代代码?所有数据都存储在数据库中,因此除了用户身份验证和会话信息之外,它们之间不会出现同步问题。

是否有可能在古老的数据库设计上雄辩地运行或以这样的方式重构数据库以使其适用于两者?之前曾尝试将数据库接口移动到Doctrine,而我知道在部分成功之后中止了该接口(即通过Doctrine访问许多数据库对象,但也有很多直接的SQL代码并行)。

这是一个巨大的混乱,但有问题的软件仍在使用并且成功,所以之前用其他东西替换它的尝试已经失败。

其他详细信息

感谢@ maiorano84提出的好问题:

  

首先,您的遗留应用程序是否有测试?

否定。 PHPUnit于2004年发布。当时,这个应用程序已经生产了四年。

  

其次,你能让它在更新版本的PHP上运行吗?

是的,当前的代码库在PHP 5.6.33上运行 - 多年来一直在维护,并且对PHP 4和PHP 5之间的转换进行了重大更新。

3 个答案:

答案 0 :(得分:1)

有可能吗?是。

是否需要花费很短的时间? 绝对不是

对于任何类型的遗留代码库,您将需要花时间弄清楚其所有移动部件并确定需要更改哪些部分才能使现代代码工作平台。

最新版本的Laravel需要PHP 7.1.3,因此即使尝试将整个代码库转储到Laravel应用程序中也很可能会导致失败。

首先,您的遗留应用程序是否有测试?这些可以是单元测试,集成测试或功能测试。如果没有,并且您希望能够在不破坏未来事项的情况下实现应用程序的现代化,那么您将需要编写测试以确保在开始升级时不会出现任何问题。仅此一点可能需要很长时间,尤其是代码库使得首先进行测试变得困难。拥有经过全面测试的应用程序将允许您在开始重新处理应用程序时查看哪些测试开始失败,因此这些信息将非常有价值。

其次,您是否能够在更新版本的PHP上使用它?如果此代码已经投入生产,那么您将需要通过Vagrant使用一些硬件虚拟化,或者更好的是,通过Docker进行容器化,以便在不破坏生产的情况下启动并运行本地安装代码。

一旦准备就绪,那么你应该能够开始重构了。获取整页代码并将它们直接转储到Laravel应用程序中并不会直接发挥作用。你想要开始变小。查找所有移动部件,找出每个部件的责任,并使用适当的方法将它们封装在类中。

使用Composer的PSR-4 Autoloader帮助删除所有额外的includerequire语句,并在整个应用程序中加载新类。

使用合适的Router将所有网址更改为SEO友好路径,并为所有请求明确定义入口点。

将所有业务逻辑移出webroot:创建一个/public文件夹,其中只有您的index.php入口点和所有面向公众的资产(图像,CSS,JavaScript等)。由于此时所有请求都被路由到此文件,因此您应该能够处理请求并返回您的响应。

一旦你实际上已经将应用程序放入一个定义良好的组件和模块的系统中,那么迁移到Laravel - 或任何其他完善的框架 - 应该会容易得多。

如果您计划正确行事,这将带您 时间。希望这对你有帮助,祝你好运。

答案 1 :(得分:1)

如果它在PHP 5.3+上运行,则可以使用即时重构

我是Rector的作者,该工具可以在几秒钟内迁移大量PHP文件。例如。将PHP 5.3升级到PHP 7.4,将Symfony 2.8升级到4.2或从Nette迁移到Symfony(read the case study)。

1。安装神父

composer require rector/rector --dev

2。然后,从PHP集开始,因为您有旧的PHP代码

vendor/bin/rector process src --level php52
vendor/bin/rector process src --level php53
vendor/bin/rector process src --level php54

您还可以 write your own rules ,因此可以将代码转换为Laravel / MVC方法。这个想法是写一个规则,例如将100多个文件转换为控制器。

Read more on Github repository

答案 2 :(得分:0)

重构当然是可能的,但我有一些疑问,如果在这种情况下部分可行。部分在这里,我的意思是,应用程序的某些部分有时会在旧的,有时在生产中的新代码上运行。

我为旧项目做了一次,但不像你那样古老和大。

在我的情况下,它是在php 5.3上运行的自定义应用程序(没有任何框架),我将它转换为Laravel 4.2。

我必须承认,路上有一些真正的挑战。 这只是冰山一角,但我会试着用我记忆中的一些来命名:

  1. PHP版本兼容性,或者说在这种情况下不兼容。您可以重写现有代码以在最新的PHP 7版本上运行。然而,这可能是很多工作 - 最终没有使用。
  2. 路由和资产处理 - 您需要检查是否可以修改网址,以便它们适合Laravel路由引擎。这可能真的很难,特别是如果旧的应用程序使用Laravel标准路径,并且如果您不想打破谷歌索引。我还看到了用于url的自定义生成器的系统,然后在视图中大量使用。试图为这些路线做完美匹配将是一场噩梦。
  3. 验证即可。更改身份验证必须在一个步骤中完成,因此使Laravel适应旧系统中的会话(尽管可行)会使新代码混乱。
  4. 数据库即可。如果数据库设计得很好,你会很幸运,但我认为它甚至不会接近Laravel Eloquent惯例。虽然您可以在没有任何数据库架构修改的情况下在Laravel上运行它,但您的新代码也会在新应用中变得臃肿。这个和其他东西可以在完整的系统中再次重构,但这是另一个工作量。
  5. 考虑到所有可能的,而不是最佳的解决方法,为了拥有设计合理的应用程序(使用最佳实践构建),可能最好从头开始重建。

    希望它有所帮助...