如何处理PHP中的过程代码、业务逻辑和查询

我的任务是支持和维护几个PHP/MySQL web应用程序（我经常使用“app”一词），它们似乎违反了所有已知的编码标准

PHP代码包含例程、过程、业务逻辑，甚至查询——都在代码中。没有面向对象的编程，甚至没有MVC，当然也没有表示层与应用层的分离。也没有使用任何框架来构建这些应用程序，我正在为新项目使用Yii框架

虽然这很耗时，但我应该重写这些应用程序吗？我每周至少有一半的时间需要修复它们，在我的新工作中，更新必须与这些现有的应用程序配合使用

---

有人对此有什么建议吗

这些产品会持续很长时间吗？其他用户会看到代码并认为是你做的吗？如果这些答案是肯定的，那么您最好重写代码。试着从你的公司获得一些支持，让他们知道这些好处，也许你甚至会因此而受到关注。

这是一个被问了很多的老问题

基本上，如果它起作用，就不要弄坏它。如果您使用它，并且可以在不破坏代码的情况下进行更改来清理代码，那么就这样做。重写代码？我的想法是，投资的回报是什么，需要多少时间，你能在不引入新版本的情况下避开旧版本的缺陷吗。诸如此类的事情

---

祝你的项目好运，希望这对你有所帮助。

我要提醒你不要全盘重写。如果应用程序正在工作并且有用户，则前进的路径是修改现有的代码库

是的，您可以将框架实现到现有的无框架代码库中。这需要很多努力，但这是可能的（我已经做了好几次）。重新开始会让你失去宝贵的时间。这已经被一次又一次地证明了（还记得网景吗？）

显然，您足够聪明，知道存在问题，并且知道解决方案是通过实现框架并清理它们来改进应用程序。这让你在比赛中领先

分阶段实施新框架。从一个MVC框架开始——把它放到代码库中，但不要担心层之间还没有分离。获得一个新版本，它构建在MVC框架之上，但并不真正遵守MVC约定。这是一个开始。然后采取下一步-将业务逻辑移动到模型层。或者让它保持原样，但让它成为OO

---

请记住，您的工作是生产用户可以使用的产品。你的工作不是坚持最佳实践。意思-是的，最佳实践是正确的行动方针。但如果用户不能使用你的应用程序，或者你的应用程序无法与竞争对手竞争，那么它们就无关紧要了。别忘了这一点。努力改进应用程序，使其成为一款优秀的产品，但不要让完美成为好的敌人。

虽然表示层和业务层之间没有分离显然是不好的，但其他选择也有一些优点。如果维护代码是一件痛苦的事情，只需在执行过程中重构代码即可。因为您熟悉良好的设计模式，所以应该能够相当轻松地完成它。此外，这还将帮助您减少代码中的错误。但请记住，在重构代码时，事情在变得更好之前会变得更糟。所以，不要过早放弃。

以我的经验，这通常是一个商业决策。你的老板知道你花了多少时间维护这些系统吗？有多少用户实际使用这些系统？它们对业务有多重要？你能以重写的方式推销管理吗？你能证明它是有用和有益的吗

---

您可以在日常维护中开始一些基本的重构。每当您需要进行更新时，即使可能需要一点额外的时间，也要找到一种方法来使用某种OOP解决方案，或者清理那里的代码以使其更易于处理。全面重写通常不是一个好主意，而且很难销售，但如果您已经在维护和添加新功能，那么没有理由不能使用新代码或修复来改进已有的功能。

我建议这取决于这些应用的用户负载量，他们真的在现场场景中分裂了吗？你每天在这些固定装置上浪费了多少时间

---

重写总比在一堆乱七八糟的东西上乱撞要强。

是的，这些产品构成了我公司的工作方式。然而，它们是建立在“只需完成”的授权之上的，这一授权将在以后得到纠正。大多数最初的程序员早已不在了，这些应用程序以后再也没有被更正过。在我之前的一些团队成员似乎只满足于推敲报告，并不断地寻找bug（即使是周而复始的相同问题），而不是站出来做点什么。似乎我在这里读得越多，我就越发现我的处境并不独特。谢谢迈克，我完全同意完美不是我想要的，只是可靠的、有良好文档记录的代码，它可以完成它应该做的事情，并且对于我之后的下一个家伙来说很容易跟随和支持。我喜欢你的想法，当我能做到的时候，我会尽我所能，但仍然遵循合理的原则。关于重构代码，我从来没有想过这一点，但这是我选择完全重写的原因之一。我有很多好的建议和一些阅读材料等着我。谢谢你的回复。