example - radiobutton group java

Entendiendo y modificando grandes proyectos. (8)

Amigo mío, estás en un profundo doodoo. Modificar un código legado grande y mal documentado es uno de esos proyectos que hace que programadores experimentados consideren seriamente la alegría de vender seguros o alguna otra carrera alternativa. Sin embargo, no es imposible, y aquí hay algunos consejos que espero ayuden.

Tu primera tarea es entender el código tanto como sea posible. Estás al menos en el camino correcto allí. Obtener una buena idea de la estructura de la clase es absolutamente importante, y un diagrama es probablemente la mejor manera. La otra cosa que sugeriría es que cuando descubra lo que hace una clase, agregue usted mismo la documentación faltante. De esa manera, cuando vuelvas a él, no habrás olvidado lo que descubriste.

No te olvides del depurador. Si desea saber qué es lo que realmente está sucediendo, repasar el código relevante o simplemente saber cómo se ve realmente una pila de llamadas en un determinado momento puede ser muy útil.

Soy un programador novato y como parte de mi proyecto tengo que modificar una herramienta de código abierto (escrita en java) que tiene cientos de clases. Tengo que modificar una parte significativa de ella para satisfacer las necesidades del proyecto. He estado luchando con él durante el último mes tratando de leer el código, tratando de averiguar las funcionalidades de cada clase y tratando de averiguar la tubería de principio a fin.

El 80% de las clases tienen documentación incompleta / faltante. El 20% restante son aquellos que forman la API de propósito general para la herramienta. Un mes de lectura de códigos me ha ayudado a entender la arquitectura básica. Pero no he podido averiguar los cambios exactos que necesito hacer para mi proyecto. Una vez, comencé a modificar una parte del código y pronto realicé tantos cambios que ya no podía recordar.

Un amigo me sugirió que tratara de escribir la jerarquía de clases. ¿Hay una manera mejor (estándar) de hacer esto?

Aquí hay un par de recomendaciones.

Obtener el código en alguna forma de CVS. De esta manera, si comienza a realizar cambios, siempre puede volver a las versiones anteriores.
Tómese el tiempo para documentar lo que ya ha aprendido / pasado. Javadoc está bien para esto.
Crea una estructura UML para tu código. Hay muchos complementos por ahí y te darán una buena representación del diseño de tu código.

Dos cosas que Eclipse (y otras IDE también) ofrecen para "luchar" contra esto. Los he usado en proyectos muy grandes:

Jerarquía de llamadas: haga clic con el botón derecho en un método y elija "jerarquía de llamadas", o use CTRL + ALT + H. Esto le brinda todos los métodos que llaman al método seleccionado, con la opción de verificar más abajo en el árbol. Esta característica es realmente muy útil.
Tipo de jerarquía: vea la jerarquía de herencia de las clases. En eclipse es F4 o CTRL + T.

También:

encuentre una manera de hacer que los cambios surtan efecto al guardarlos y no tenga que volver a implementarlos
use un depurador - ejecute en modo de depuración, dentro del IDE, para ver cómo avanza el flujo

En mi opinión, no hay un enfoque estándar para entender un proyecto. Depende de muchos factores, desde la comprensión del código / arquitectura que está analizando hasta su experiencia previa en grandes proyectos.

Le sugiero que realice una ingeniería inversa del código utilizando una herramienta de modelado, para que pueda generar algunos modelos UML a partir del código fuente existente. Estos diagramas pueden ser útiles como una guía gráfica durante su análisis del código.

No tenga miedo de usar la depuración para agarrar la lógica de las funcionalidades más complejas del proyecto. Puede ser útil ejecutar la instrucción de código más compleja por instrucción, ver los valores exactos de las variables y las interacciones entre los objetos.

Antes de refactorizar para cambiar el proyecto de acuerdo con sus necesidades, asegúrese de escribir algunos casos de prueba, para que pueda verificar que sus modificaciones no rompan el código de manera inesperada.

Hay un gran libro llamado Working Effectively with Legacy Code , de Michael Feathers. Hay una versión más corta del artículo here .

Uno de sus puntos es que lo mejor que puedes hacer es escribir pruebas unitarias para el código existente. Esto le ayuda a comprender dónde están los puntos de entrada y cómo debería funcionar el código. Luego te permite refactorizarlo sin preocuparte de que lo vayas a romper.

Del artículo vinculado, el resumen de su estrategia:

1. Identify change points 2. Find an inflection point 3. Cover the inflection point a. Break external dependencies b. Break internal dependencies c. Write tests 4. Make changes 5. Refactor the covered code.

La única manera de entender el código es leerlo. Sigue trabajando ese es mi consejo.

Hay proyectos con mejor documentación que otros. Aquí hay un par de proyectos que sé que están bien organizados: Tomcat , Jetty , Hudson ,

Debería consultar java-source para ver más proyectos de código abierto.

Personalmente, creo que es muy difícil tratar de entender una aplicación completa de una vez. En su lugar, trate de enfocarse solo en ciertos módulos. Por ejemplo, si puede identificar un módulo que necesita cambiar (por ejemplo, basado en una pantalla o cierto punto de entrada / salida), comience por hacer un pequeño cambio y probarlo. Vaya desde allí, realice un pequeño cambio, pruebe y siga adelante.

Además, si su proyecto tiene pruebas de unidad (considérese afortunado) y revise las pruebas de unidad del módulo en el que se está enfocando. Eso te ayudará a tener una idea de lo que se espera que haga el módulo.

verifique el código en algún repositorio de código fuente (Subversion, CVS, Git, Mercurial ...)
Asegúrate de que puedes construir el proyecto desde la fuente y ejecutarlo
Si ya tiene una aplicación que utiliza esta herramienta de código abierto, intente eliminar la dependencia binaria e introduzca la dependencia del proyecto en eclipse o en cualquier otro IDE. ejecuta tu código y recorre el código que quieres entender
después de cada pequeño cambio cometer
Si tienes ideas diferentes ramifica el código.