Tengo un proyecto complejo sin comentarios. El proyecto está programado en Java pero tiene más de una clase principal, usa varios archivos .txt como una plantilla y usa varios archivos .bat. No sé por dónde empezar y cómo comenzar a descubrir el proyecto, porque necesito hacer algunos cambios en ese proyecto.la mejor o más rápida forma de entender un proyecto complejo y sin comentarios
Un comienzo es utilizar una herramienta de modelado uml automatizada (si usa eclipse puede usar un plug-gin), y comenzar a crear diagramas UML de las diferentes clases para ver cómo se relacionan en un alto nivel y visualizar el código. Esto ha ayudado muchas veces
Si este complemento reconocerá los archivos .bat y .txt. – Gogoo
@GoGoo: me refiero a las clases de Java. Pruebe este http://www.soyatec.com/main.php tiene una versión gratuita. Usted crea diagramas uml visuales del código java y comienza a visualizar el proyecto. Una vez que comprenda el código en el nivel alto, será más fácil encontrar qué parte del código hace qué, y dónde bucear. – Cratylus
Si se están generando archivos de registro, échele un vistazo para comprender el flujo desde el punto de partida (clase principal). De lo contrario, ponga declaraciones de depuración para comprender el flujo.
Encuentra la clase Principal principal. El punto de partida. Comience a dibujar una imagen de las clases y los objetos que poseen y las entidades externas a las que hacen referencia. Sigue todas las ramas hasta que encuentres una final lógica.
He utilizado herramientas de ingeniería inversa UML en el pasado y aunque una imagen visual es buena, recorrer el código siempre ha sido la metodología más difícil y, sin embargo, la mejor para mí.
Y, a medida que paso a través de cada pieza se puede añadir en sus propios comentarios ..
y la forma más fácil de encontrar esto es con los archivos .bat; vea a qué clases se llama desde el comando línea, ese es tu punto de entrada. – KevinDTimm
me gustaría tratar de encontrar el primer punto de entrada en el código más cercana a su sospecha que necesitará para comenzar a hacer su cambios, establecen un punto de interrupción y comienzan a depurar. Consulte los contenidos de las variables locales y profundice más a medida que se familiarice con lo que está sucediendo. Luego, cuando tenga una comprensión básica del área de código con la que va a trabajar, comienza a alterar algunos pequeños cambios. Pon a prueba tu comprensión de eso. Intente diagramar lo que ve pasar. Si puede hacerlo con confianza, podrá decidir si necesita regresar y continuar aprendiendo más sobre el código, o si sabe lo suficiente como para terminar lo que necesita hacer.
Auch. Me temo que no hay una forma rápida de hacer esto. Comente una línea (o dos) -> prueba -> vea qué se rompe. También podría poner declaraciones de interrupción aquí y allá y ejecutar el depurador. Eso debería darte una indicación de cómo llegaste allí (es decir, cuál es la jerarquía entre las clases).
Afortunadamente, los desarrolladores originales utilizaron algunos patrones que puedes reconocer y tomar notas. Haga muchas notas de todo. Comience tratando de entender la estructura de alto nivel y trabaje desde allí.
Prepárese para pasar horas interminables sin comprender qué está haciendo.
Hable con el cliente y trate de entender para qué es el proyecto y qué es lo que hace. Alguien en algún lugar tiene que poner algunos requisitos para las cosas que están ahí, aunque solo sea en un correo electrónico.
Ya, que suena como un muy mal lugar para estar en.
Yo diría que la mejor forma de hacerlo es simplemente caminar a través de la línea de programa para la línea. Intente captar la imagen completa del código y escriba muchas notas, tanto en papel como en comentarios en el código.
Como con otros, digo que este es un proceso lento.
Sin embargo, habiendo hecho esto en el pasado muchas veces, esta es mi metodología:
identificar tantos requisitos que cumple el código. Esto puede darle algunas razones de por qué ciertas cosas son como son cuando miras más profundamente. Una forma común de encontrar estos es buscar cualquier prueba que esté disponible. Los automatizados son los mejores, pero generalmente están tan perdidos como los comentarios.
Encuentra los puntos de entrada al código. Estos le darán lugares donde puede introducir el código para ver cómo las diferentes entradas afectan el flujo. Los puntos de entrada comunes son funciones de tipo 'Principal' de carga de código, interfaces de servicio, respaldos de la página web, etc.
Diagrame el código. Busque herramientas que puedan crear imágenes en blanco y negro del código. Para mí esto es invaluable. En ocasiones he imprimido grandes listados y luego los ataqué con marcadores y reglas. Tiene el objetivo de crear su propio diagrama de flujo (mental u otro) del flujo de código.
Utilizando el anterior (iterativa) construir un conjunto de salidas al código que cree que debería ocurrir, y añadir a éstas las salidas que usted ya conoce acerca de como los registros, archivos de datos, bases de datos graba etc ..
Finalmente, si tiene tiempo, cree algunas pruebas manuales, preferiblemente en arneses de prueba automatizados para verificar lo anterior. Aquí donde empiezo a involucrar al depurador para ver detalles en el código.
Esta metodología generalmente me da confianza para realizar cambios.
Tenga en cuenta que este es un proceso iterativo y se puede hacer con partes del código o general como mejor le parezca. Normalmente, prefiero un enfoque de arriba hacia abajo y luego, a medida que obtengo alguna información, profundizo hasta que los detalles se vuelven abrumadores y luego repito. Sin embargo, esto es solo porque mi mente funciona de esta manera: puede ser diferente. Buena suerte.
6. Comience a agregar los documentos faltantes –
Yo diría que un buen enfoque sería generar documentación utilizando la función de diagrama de clases de javadoc o doxygen, luego, cuando ejecute el código recorra los diagramas de clases generados con doxygen y vea quién llama qué. Esto funciona maravillosamente para mí cada vez que estoy trabajando en un proyecto así.
Acepto completamente la mayoría de las respuestas publicadas.
Puedo agregar el uso de una herramienta de desarrollo que revierte la ingeniería del código y crea un diagrama de clases, para tener una idea general de lo que está involucrado.
Entonces usted necesita paciencia. Pero serás un desarrollador más fuerte e inteligente cuando superes ...
¡Buena suerte!
Normalmente comienzo con doxygen, activando todas las opciones de extracción (especialmente EXTRACT_ALL y EXTRACT_PRIVATE), y habilito las opciones SOURCE_BROWSER, HAVE_DOT, CALL_GRAPH y CALLER_GRAPH (también necesita tener dot instalado). Esto le da una buena vista del software. Para cada función, las llamadas se muestran y se vinculan en un gráfico, también las fuentes se vinculan desde allí.
Mientras que doxygen está diseñado para C y C++, también funciona con fuentes Java (establezca la opción OPTIMIZE_OUTPUT_JAVA).
Una de las mejores y primeras cosas para hacer es intentar construir y ejecutar el código. Puede sonar un poco simplista, pero el problema cuando tomas el código no documentado es que ni siquiera puedes construirlo y ejecutarlo. Cuando no tenían ni idea de comenzar.
Creo que esta situación se llama "Infierno". –
Hable con el cliente. Solo ellos probablemente saben lo que querían. – leppie
La recomendación número uno es: ser sincero con el cliente, decirles que llevará tiempo descifrar y pedir más tiempo del que cree que necesitará. –