PHP到Java（使用PtoJ） [英] PHP to Java (using PtoJ)

问题描述

我想将代码库从编写糟糕的PHP代码转换为写得不好的Java，因为我相信Java代码更容易整理。有什么利弊，对于那些自己做过的人，你会推荐 PtoJ 对于一个大约30万条丑陋代码的项目？提示和技巧是最受欢迎的;谢谢！

I would like to transition our codebase from poorly written PHP code to poorly written Java, since I believe Java code is easier to tidy up. What are the pros and cons, and for those who have done it yourselves, would you recommend PtoJ for a project of about 300k ugly lines of code? Tips and tricks are most welcome; thanks!

推荐答案

写得不好的PHP可能很难转换，因为PHP中很多不好的东西都没有存在于Java中（尽管如此，反过来也是如此，所以不要因为我说Java更好 - 我将完全清除那场火焰战争）。

Poorly written PHP is likely to be very hard to convert because a lot of the bad stuff in PHP just doesn't exist in Java (the same is true vice versa though, so don't take that as me saying Java is better - I'm going to keep well clear of that flame-war).

如果您正在谈论遗留的PHP应用程序，那么您的代码很可能包含大量的过程代码和内联HTML，这两种代码都不能很好地转换为Java。

If you're talking about a legacy PHP app, then its highly likely that your code contains a lot of procedural code and inline HTML, neither of which are going to convert well to Java.

如果你真的不走运，你会得到像 eval（）这样的语句，动态变量名（使用 $$ 语法），循环 include（）语句，依赖'register_globals'标志，甚至更糟。这种东西会完全阻止任何转换尝试。

If you're really unlucky, you'll have things like eval() statements, dynamic variable names (using $$ syntax), looped include() statements, reliance on the 'register_globals' flag, and worse. That kind of stuff will completely thwart any conversion attempt.

你的另一个主要问题是，即使你有漂亮的代码，转换后调试结果也会很糟糕首先。如果你想避免回归，你基本上需要用精梳梳理双方的整个代码库。

Your other major problem is that debugging the result after the conversion is going to be hell, even if you have beautiful code to start with. If you want to avoid regressions, you will basically need to go through the entire code base on both sides with a fine comb.

你唯一一次得到回归如果您从一个合理的潮汐代码库开始，至少主要是使用最新的OOP代码编写，那么这种类型的自动转换会产生令人满意的结果。

The only time you're going to get a satisfactory result from an automated conversion of this type is if you start with a reasonably tide code base, written at least mainly in up-to-date OOP code.

In我认为，你最好在转换之前进行重构。但是，当然，鉴于你的问题，那宁可打败这一点。因此我的建议是坚持使用PHP。 PHP代码可以非常好，即使是糟糕的PHP也可以通过一些重构来完善。

In my opinion, you'd be better off doing the refacting excersise before the conversion. But of course, given your question, that would rather defeat the point. Therefore my recommendation is to stick it in PHP. PHP code can be very good, and even bad PHP can be polished up with a bit of refactoring.

在评论中回答@ Jonas的问题，'重构可怕的PHP代码的最佳方法是什么？'

In answer to @Jonas's question in the comments, 'what is the best way to refactor horrible PHP code?'

这实际上取决于码。一个庞大的整体代码块（描述了我见过的很多不好的PHP）可能非常难（如果不是不可能的话）来实现单元测试。您可能会发现功能测试是您可以在旧代码库上编写的唯一一种测试。这些将使用 Selenium 或类似工具通过浏览器运行代码，就像它是用户一样。如果您可以编写一组可靠的功能测试，那么有助于您保持自信不会引入回归。

It really depends on the nature of the code. A large monolithic block of code (which describes a lot of the bad PHP I've seen) can be very hard (if not imposible) to implementunit tests for. You may find that functional tests are the only kind of tests you can write on the old code base. These would use Selenium or similar tools to run the code through the browser as if it were a user. If you can get a set of reliable functional tests written, it is good for helping you remain confident that you aren't introducing regressions.

好消息是它可以非常容易 - 并且令人满意 - 撕掉坏代码并重建它。

The good news is that it can be very easy - and satisfying - to rip apart bad code and rebuild it.

我过去接近它的方式是采取两阶段方法。

The way I've approached it in the past is to take a two-stage approach.

第一阶段将单片代码重写为质量合理的程序代码。这相对简单，新代码可以随时删除。这是大部分工作发生的地方，但你仍然会得到程序代码。更好的程序代码。

Stage one rewrites the monolithic code into decent quality procedural code. This is relatively easy, and the new code can be dropped into place as you go. This is where the bulk of the work happens, but you'll still end up with procedural code. Just better procedural code.

第二阶段：一旦你获得了大量合理质量的程序代码，你就可以再次将它重构为OOP模型。这必须等到以后，因为通常很难将旧的劣质PHP直接转换为一组对象。它也必须在相当大的块中完成，因为您将同时将大量代码移动到对象中。但如果你在第一阶段做得很好，那么第二阶段应该相当简单。

Stage two: once you've got a critical mass of reasonable quality procedural code, you can then refactor it again into an OOP model. This has to wait until later, because it is typically quite hard to convert old bad quality PHP straight into a set of objects. It also has to be done in fairly large chunks because you'll be moving large amounts of code into objects all at once. But if you did a good job in stage one, then stage two should be fairly straightforward.

当你把它变成对象时，你就可以开始认真思考单元测试。

When you've got it into objects, then you can start seriously thinking about unit tests.

这篇关于PHP到Java（使用PtoJ）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！