Me gustaría transferir nuestra base de código de código PHP mal escrito a Java mal escrito, ya que creo que el código de Java es más fácil de poner en orden. ¿Cuáles son los pros y los contras, y para aquellos que lo han hecho, recomendarían PtoJ para un proyecto de aproximadamente 300k líneas de código feo? Consejos y trucos son bienvenidos; ¡Gracias!PHP a Java (usando PtoJ)
PHP mal escrito es probable que sea muy difícil de convertir porque muchas de las cosas malas en PHP simplemente no existen en Java (lo mismo es cierto al revés, así que no lo tome como diciendo Java es mejor, me mantendré alejado de esa guerra de llamas).
Si está hablando de una aplicación PHP heredada, entonces es muy probable que su código contenga muchos códigos de procedimiento y HTML en línea, ninguno de los cuales se convertirá bien a Java.
Si usted es realmente mala suerte, tendrá cosas como eval() declaraciones, nombres de variables dinámicas (utilizando $$ sintaxis), en bucle include() declaraciones, la dependencia de la bandera 'register_globals', y peores. Ese tipo de cosas frustrará por completo cualquier intento de conversión.
Su otro gran problema es que depurar el resultado después de la conversión va a ser un infierno, incluso si tiene un código hermoso para empezar. Si desea evitar regresiones, básicamente tendrá que pasar por la base de códigos completa en ambos lados con un peine fino.
La única vez que obtendrá un resultado satisfactorio de una conversión automática de este tipo es si comienza con una base de código de marea razonable, escrita al menos principalmente con código OOP actualizado.
En mi opinión, será mejor que realice el ejercicio de reexpresión antes de la conversión. Pero, por supuesto, dada su pregunta, eso preferiría derrotar el punto. Por lo tanto, mi recomendación es incluirlo en PHP. El código PHP puede ser muy bueno, e incluso el PHP malo puede pulirse con un poco de refactorización.
[EDIT]
En respuesta a la pregunta de @ Jonas en los comentarios, '¿cuál es la mejor manera de refactorizar código PHP tan horrible?'
Realmente depende de la naturaleza del código. Un gran bloque monolítico de código (que describe una gran cantidad del PHP malo que he visto) puede ser muy difícil (si no imposible) para implementar las pruebas de una unidad. Puede encontrar que las pruebas funcionales son el único tipo de pruebas que puede escribir en la antigua base de códigos. Estos usarían Selenium o herramientas similares para ejecutar el código a través del navegador como si fuera un usuario. Si puede escribir un conjunto de pruebas funcionales confiables, es bueno para ayudarlo a mantener la confianza de que no está presentando regresiones.
La buena noticia es que puede ser muy fácil y satisfactorio desmantelar el código incorrecto y reconstruirlo.
La forma en que lo he abordado en el pasado es adoptar un enfoque en dos etapas.
La etapa uno reescribe el código monolítico en un código de procedimiento de calidad decente. Esto es relativamente fácil, y el nuevo código se puede colocar en su lugar a medida que avanza. Aquí es donde ocurre la mayor parte del trabajo, pero igual terminará con el código de procedimiento. Simplemente mejor código de procedimiento.
Segunda etapa: una vez que tiene una masa crítica de código de procedimiento de calidad razonable, puede volver a configurarla en un modelo de OOP. Esto tiene que esperar hasta más tarde, porque normalmente es bastante difícil convertir PHP antiguo de mala calidad directamente en un conjunto de objetos. También tiene que hacerse en trozos bastante grandes porque moverá grandes cantidades de código a todos los objetos a la vez. Pero si hiciste un buen trabajo en la etapa uno, entonces la segunda etapa debería ser bastante sencilla.
Cuando lo tienes en los objetos, entonces puedes empezar a pensar seriamente en las pruebas unitarias.
¿Cuál es la mejor manera de refactorizar código PHP horrible? ¿Es comprobable e implementa muchas pruebas unitarias y luego comienza a destrozarlo? –
@Jonas - mi respuesta a su comentario es demasiado grande para poner los comentarios aquí, así que he editado mi respuesta; véase más arriba. – Spudley
diría que la conversión automática desde PHP a Java tienen las siguientes:
pros:
contra:
código feo: Dudo que la conversión automática de fea PHP generará cualquier cosa menos fea de Java
código imposible de mantener: el código generará automáticamente es probable que sea imposible de mantener, o, al menos, muy difícil de mantener
mal enfoque: asumo que usted tiene una aplicación web PHP; en este caso, creo que la traducción automática es poco probable que el uso de Java mejores prácticas para la aplicación Web, o marcos disponibles
En resumen
que evitaría una traducción automática de PHP a Java, y Al menos consideraría reescribir la aplicación desde cero utilizando Java. Especialmente si tiene una aplicación web, elija un buen marco de trabajo de Java para webapps, haga un diseño cuidadoso y proceda con una implementación incremental (una característica de su aplicación web original de PHP a la vez). Con este enfoque, terminará con un código más limpio que es más fácil de mantener y evolucionar ... y puede descubrir que el tiempo requerido no es tan grande como para lo que necesitaría para limpiar/depurar el código generado automáticamente :)
Omg, ojalá estuviera muerto. :) –
http://www.numiton.com/products/ntile-ptoj/translation-samples/web-and-db-access/mysql.html
¿Prefiere no usar Hibernate?
Probablemente (no lo he usado). De hecho, prefiero usar casi todo lo que tenemos ahora. :) –
P2J parece estar fuera de línea ahora, pero he escrito una prueba de concepto que convierte un subconjunto de PHP en Java. Utiliza la biblioteca transpiler de SWI-Prolog:
:- use_module(library(transpiler)).
:- set_prolog_flag(double_quotes,chars).
:- initialization(main).
main :-
Input = "function add($a,$b){ print $a.$b; return $a.$b;} function squared($a){ return $a*$a; } function add_exclamation_point($parameter){return $parameter.\"!\";}",
translate(Input,'php','java',X),
atom_chars(Y,X),
writeln(Y).
Ésta es la salida del programa:
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+"!";
}
A diferencia de otras respuestas aquí, yo estaría de acuerdo con su estrategia de convertir "código PHP para mal Java escrito, ya que creo que el código de Java es más fácil de poner en orden ", pero debe asegurarse de que la herramienta que está utilizando no presente más errores de los que pueda manejar.
Un stategy óptima sería: 1) Haz conversión automatizada 2) Obtener un MVP se ejecuta con algunas pruebas básicas 3) comenzar a usar la herramienta increíble refractoring Eclipse/IntelliJ para hacer el código más legible.
Un moderno IDE de Java puede refactorizar el código sin errores cuando se hace correctamente. También puede decirle qué funciones nunca se llaman y muchas otras inspecciones.
No sé cómo era "PtoJ", ya que su sitio web se ha desvanecido, pero lo ideal es que desee algo que no solo traduzca la sintaxis, sino la lógica. Usé php2java.com recientemente y funcionó muy bien. También utilicé varios convertidores de "sintaxis" (no solo para PHP a Java, sino también para ObjC -> Swift, Java -> Swift), e incluso funcionan bien si pones el tiempo para que todo funcione bien.
También encontró esta interesante entrada de blog sobre lo que podría haberle sucedido a numiton PtoJ (http://www.runtimeconverter.com/single-post/2017/11/14/What-happened-to-numition).
Honestamente, una conversión de una base de código feo lo hará más feo, si Java es más limpio o no (que, por cierto, no es **;) **). – Christian
Tienes razón, solo espero que con el tiempo obtengamos el código de Java en mejor forma que el ídem de PHP en este momento. ¿Crees que es una causa perdida? –
¿No debería etiquetarse esto como "basura, basura"? –