Je voudrais transmettre notre codeBase d'un code PHP mal écrit en Java mal écrit, puisque je crois que le code Java est plus facile à ranger. Quels sont les avantages et les inconvénients, et pour ceux qui l'ont fait vous-même, recommanderiez-vous PTOJ pour un projet d'environ 300 000 lignes de code laids? Les astuces et astuces sont les bienvenus; merci!
5 Réponses :
Je dirais que la conversion automatique de PHP en Java a les suivantes:
avantages :
code laid: je doute que la conversion automatique de laid php générera autre chose que laide Java
Code systématisable: le code génère automatiquement est susceptible d'être non restauré, ou au moins très difficile de maintenir
mauvaise approche: je suppose que vous avez une application Web PHP; Dans ce cas, je pense que la traduction automatique est peu probable d'utiliser les meilleures pratiques de Java pour l'application Web ou des cadres disponibles
en résumé
J'éviterais la traduction automatique de PHP à Java, et j'envisage au moins que j'envisage au moins de réécrire l'application à partir de la masse à l'aide de Java. Surtout si vous avez une application Web, choisissez un bon cadre Java pour WebApps, effectuez une conception minutieuse et procédez à une implémentation incrémentielle (une fonctionnalité de votre WebApp PHP d'origine à la fois). Avec cette approche, vous vous retrouverez avec un code de nettoyage plus facile à maintenir et à évoluer ... et vous pouvez savoir que le temps requis n'est pas si plus grand que ce dont vous auriez besoin pour nettoyer / déboguer automatiquement le code généré :)
http: // www.numiton.com/products/ntil-ptoj/translation-samples/web-and-db-access/mysql.html
Préférez-vous ne pas utiliser hibernate?
Je le ferais probablement (je l'ai pas utilisé). En fait, je préférerais utiliser presque toute autre chose que ce que nous avons maintenant. :)
PHP mal écrit est susceptible d'être très difficile à convertir, car beaucoup de mauvais trucs dans PHP n'existent pas à Java (la même chose est vrais vice versa, alors ne prenez pas cela comme je disant Java est Mieux - je vais garder bien clair de cette guerre de flamme).
Si vous parlez d'une application PHP Legacy, il est fort probable que votre code contienne beaucoup de code procédural et de HTML en ligne, ce qui ne se convertit pas bien à Java.
Si vous êtes vraiment malchanceux, vous aurez des choses comme Votre autre problème majeur est que le débogage du résultat après la conversion sera l'enfer, même si vous avez un beau code pour commencer. Si vous souhaitez éviter les régressions, vous devez essentiellement passer par la base de code complète des deux côtés avec un peigne fine.
La seule fois que vous obtiendrez un résultat satisfaisant d'une conversion automatisée de ce type est si vous commencez par une base de code de la marée raisonnable, écrite au moins principalement dans le code OPO à jour.
À mon avis, vous feriez mieux de faire de la réception avant la conversion. Mais bien sûr, étant donné votre question, cela préférerait vaincre le point. Par conséquent, ma recommandation est de le coller à PHP. Le code PHP peut être très bon et même Bad PHP peut être polie avec un peu de refactoring.
[modifier]
Répondre à la question de @ Jonas dans les commentaires, "Quelle est la meilleure façon de refacturer un code PHP horrible?"
Cela dépend vraiment de la nature du code. Un grand bloc de code monolithique (qui décrit beaucoup de mauvais php que j'ai vu) peut être très difficile (s'il n'est pas impossible) de mettre en place des tests. Vous pouvez trouver que les tests fonctionnels sont les seuls types de tests que vous pouvez écrire sur l'ancienne base de code. Celles-ci utiliseraient Selenium ou des outils similaires pour exécuter le code via le navigateur comme s'il s'agissait d'un utilisateur. Si vous pouvez obtenir un ensemble de tests fonctionnels fiables écrits, il est bon de vous aider à rester confiant que vous ne présentant pas de régressions.
La bonne nouvelle est que cela peut être très facile - et satisfaisant - déchirer le mauvais code et la reconstruire.
La façon dont je m'approche dans le passé est de prendre une approche en deux étapes.
La phase on réécrit le code monolithique en un code de procédure de qualité décent. Ceci est relativement facile et le nouveau code peut être déposé en place à votre guise. C'est là que l'essentiel du travail se produit, mais vous vous retrouverez toujours avec du code de procédure. Juste un meilleur code procédural.
Étape 2: Une fois que vous avez une masse critique de code de procédure de qualité raisonnable, vous pouvez ensuite le refroidir dans un modèle de POO. Cela doit attendre plus tard, car il est généralement assez difficile de convertir une vieille mauvaise qualité PHP directement en un ensemble d'objets. Il doit également être fait dans des morceaux assez importants car vous allez déplacer de grandes quantités de code dans des objets tout à la fois. Mais si vous avez fait un bon travail sur la scène, alors la deuxième étape devrait être assez simple.
Lorsque vous en avez eu des objets, vous pouvez commencer à réfléchir sérieusement à des tests unitaires. eval () instructions, noms de variable dynamiques (à l'aide de $$ syntaxe), en boucle inclure () déclarations, dépendance du drapeau "register_globals" et pire. Ce genre de choses trompera complètement toute tentative de conversion.
Quel est le meilleur moyen de refactoriser un code PHP horrible? Faites-la vérifier et mettre en œuvre beaucoup de tests d'unité, puis commencez à le déchirer?
@Jonas - ma réponse à votre commentaire est trop gros pour mettre dans les commentaires ici, alors j'ai modifié ma réponse; voir au dessus.
p2j semble être hors ligne maintenant, mais je ' VE écrit une épreuve de protection qui convertit un sous-ensemble de PHP en Java. Il utilise le Transpiler Bibliothèque pour Swi-prolog:
public static String add(String a,String b){
System.out.println(a+b);
return a+b;
}
public static int squared(int a){
return a*a;
}
public static String add_exclamation_point(String parameter){
return parameter+"!";
}
Contrairement à d'autres réponses ici, je suis d'accord avec votre stratégie de convertir "Code PHP en Java mal écrit, puisque je crois que le code Java est plus facile à garder", mais vous devez vous assurer que l'outil que vous utilisez. ne présente pas plus de bugs que vous ne pouvez gérer.
Une énigme optimale serait: 1) faire une conversion automatisée 2) Obtenez un MVP en cours d'exécution avec des tests de base 3) Commencez à utiliser l'étonnant outil Eclipse / Intellij Intellij pour rendre le code plus lisible.
Un IDE Java moderne peut refacturer le code avec zéro bogue lors de la fin. Cela peut également vous dire quelles fonctions ne sont jamais appelées et beaucoup d'autres inspections.
Je ne sais pas comment "PTOJ" était, puisque leur site Web a disparu, mais vous voulez idéalement de vouloir quelque chose qui ne traduit pas seulement la syntaxe, mais la logique. J'ai récemment utilisé php2java.com et ça a très bien fonctionné. J'ai également utilisé divers convertisseurs de "syntaxe" (pas seulement pour PHP à Java, mais aussi Objc -> Swift, Java -> Swift), et même ils travaillent bien si vous mettez le temps de faire fonctionner les choses après. < / p>
Aussi, a trouvé cette entrée de blog intéressante sur ce qui pourrait être arrivé à Numiton PTOJ ( http://www.runtimeconverter.com/single-post/2017/11/14/What-Happened-a-numition ).
Honnêtement, une conversion d'une base laid de code est obligée de le rendre plus laid, que Java soit plus propre ou non (qui, à la manière, n'est pas ;) ).
Vous avez raison, j'espère juste que nous aurons à temps le code Java en meilleure forme que le PHP Idito est en ce moment. Pensez-vous que c'est une cause perdue?
Cela ne devrait-il pas être étiqueté: "ordures dans, ordures"?
Ou peut-être "aide! J'ai besoin de transformer les ordures en ... quelque chose d'autre"? Peut-être trop peu de magiciens sur ce forum cependant.