PHP à Java (en utilisant PtoJ)

PHP mal écrit est susceptible d'être très difficile à convertir car beaucoup de mauvaises choses en PHP n'existent tout simplement pas en Java (la même chose est vraie vice versa, alors ne prenez pas cela comme moi en disant que Java est meilleur - Je vais rester bien à l'écart de cette guerre de flamme).

Si vous parlez d'une application PHP héritée, il est fort probable que votre code contienne beaucoup de code procédural et de HTML en ligne, dont aucun ne va bien se convertir en Java.

Si vous êtes vraiment malchanceux, vous aurez des choses comme les instructions eval(), les noms de variables dynamiques (en utilisant la syntaxe $$), les instructions include() en boucle, la dépendance à l'indicateur 'register_globals', et pire encore. Ce genre de choses va complètement contrecarrer toute tentative de conversion.

Votre autre problème majeur est que le débogage du résultat après la conversion va être l'enfer, même si vous avez un beau code pour commencer. Si vous voulez éviter les régressions, vous devrez essentiellement parcourir toute la base de code des deux côtés avec un peigne fin.

La seule fois où vous obtiendrez un résultat satisfaisant d'une conversion automatisée de ce type est si vous commencez avec une base de code de marée raisonnable, écrite au moins principalement en code de POO à jour.

À mon avis, vous feriez mieux de faire l'exercice de refacturation avant la conversion. Mais bien sûr, compte tenu de votre question, cela préférerait vaincre le point. Par conséquent, ma recommandation est de le coller en PHP. Le code PHP peut être très bon, et même mauvais PHP peut être poli avec un peu de refactoring.

[MODIFIER]

En réponse à la question de @Jonas dans les commentaires, " quelle est la meilleure façon de refactoriser un code PHP horrible?'

Cela dépend vraiment de la nature du code. Un grand bloc monolithique de code (qui décrit beaucoup du mauvais PHP que j'ai vu) peut être très difficile (sinon impossible) pour implémenter les tests d'unité. Vous pouvez trouver que les tests fonctionnels sont le seul type de tests que vous pouvez écrire sur l'ancienne base de code. Ces utiliserait Sélénium, ou des outils similaires pour exécuter le code par le navigateur comme s'il s'agissait d'un utilisateur. Si vous pouvez obtenir un ensemble de tests fonctionnels fiables écrits, il est bon pour vous aider à rester confiant que vous n'introduisez pas de régressions.

, La bonne nouvelle est qu'il peut être très facile et satisfaisante à déchirer les mauvais code et de le reconstruire.

La façon dont je l'ai abordée dans le passé est d'adopter une approche en deux étapes.

La première étape réécrit le code monolithique en code décent code de procédure qualité. C'est relativement facile et le nouveau code peut être mis en place au fur et à mesure. C'est là que se passe la majeure partie du travail, mais vous vous retrouverez toujours avec du code de procédure. Juste un meilleur code de procédure.

Deuxième étape: une fois que vous avez une masse critique de code procédural de qualité raisonnable, vous pouvez le refactoriser à nouveau dans un modèle de POO. Cela doit attendre plus tard, car il est généralement assez difficile de convertir un vieux PHP de mauvaise qualité directement en un ensemble d'objets. Il doit également être fait en morceaux assez gros car vous déplacerez de grandes quantités de code dans des objets en même temps. Mais si vous avez fait du bon travail dans la première étape, la deuxième étape devrait être assez simple.

Lorsque vous l'avez dans des objets, vous pouvez commencer à penser sérieusement aux tests unitaires.