¿Cómo debería visualizar la estructura de mi código? [cerrado]

StackOverflow https://stackoverflow.com/questions/3871449

Pregunta

Tengo una aplicación escrita en Java. En se almacena en varios archivos. Utiliza diferentes clases con diferentes métodos. El código es grande y complicado. Creo que sería más fácil de entender el código si tengo un modelo gráfico del código (una especie de gráfico dirigido). ¿Hay algunos métodos estándar para la visualización de código. Estoy pensando en el uso de UML (no estoy seguro que es una opción correcta). ¿Alguien puede recomendar algo?

AÑADIDO:

Considero dos posibilidades:

  1. La creación de la gráfica por las manos (explícitamente).
  2. Creación gráfica de una manera automática. Por ejemplo, para utilizar algunas herramientas que leen el código disponible y generar algo de gráfico que describe la estructura del código.

AÑADIDO 2:

Sería bueno tener algo de forma gratuita.

¿Fue útil?

Solución

La herramienta más importante que puedes usar es tu cerebro, y es gratis.

No hay razón por la que tiene que utilizar cualquier tipo de método estándar de visualización, y se puede utilizar cualquier medio que te gusta. Papel, pizarra, photoshop, Visio, PowerPoint, bloc de notas: todo esto puede ser eficaz. Dibuje un diagrama de clases, objetos, métodos, propiedades, variables - lo que usted cree que es útil para ver el fin de entender la aplicación. El público es no sólo a otros miembros de su equipo, sino también a sí mismo. Crear diagramas que son útiles para que usted mire y rápidamente entienda. Mensaje en torno a su espacio de trabajo y la mirada en ellos regularmente para recordarse de la arquitectura general del sistema a medida que construye él.

UML y otros estándares de documentación de código son buenas guías para los tipos de diagramas que puede hacer y la información que debe considerar la inclusión. Sin embargo, es excesivo para la mayoría de aplicaciones y, básicamente, existe para las personas que no pueden tomar la responsabilidad personal para documentar sin normas. Si sigue UML a la carta, que va a terminar gastando demasiado tiempo en su documentación en lugar de crear su aplicación.

Otros consejos

He intentado utilizar una serie de herramientas UML y encontró que las capacidades de ingeniería inversa en la mayoría de las herramientas UML fueron no es útil para la comprensión de código . Se centran en el diseño de las necesidades y capacidades de ingeniería inversa a menudo sólo termina mostrando enormes imágenes de una gran cantidad de información inútil. Cuando estaba trabajando sobre la base de código de Microsoft Office, me encontré con un lápiz y papel más útil que el diseño típico / herramientas de modelado.

Por lo general, quiere pensar en hacer esto de varias maneras:

  1. Utilice su cerebro : alguien mencionó que - no hay sustituto para realmente tratar de comprender una base de código. Puede que tenga que tomar notas hacia abajo y hacer referencia a ella más tarde. Puede herramientas de ayuda? Seguro. Pero no espere que hacer la mayor parte del trabajo por usted.
  2. Encuentra documentación y hablar con los compañeros de trabajo : No hay mejor manera de tener alguna fuente describir las principales conceptos en una base de código. Si usted puede encontrar a alguien para ayudarle, tome un lápiz y papel, ir a él y tomar muchas notas. ¿Cuánto hay que fallo la otra persona? En el principio - tanto como sea práctico para su trabajo, pero ninguna cantidad es demasiado pequeña
    3. .
  3. Piense herramientas : Si eres nuevo en una parte de un proyecto - que se va a pasar una cantidad significativa de tiempo a entender el código, por lo que ver la cantidad de ayuda que puede obtener de forma automática. Hay buenas herramientas y herramientas malas. Trate de averiguar qué herramientas tienen capacidades que pueden ser útiles para usted en primer lugar. Como he mencionado anteriormente, la herramienta UML promedio se centra más en el modelado y no parece no ser el más adecuado para usted.
  4. Tiempo Costo vs : Claro, libre es grande. Pero si una herramienta libre no está siendo utilizado por muchas personas - que podría ser que la herramienta no funciona. Hay muchas herramientas que estaban a crear simplemente como una exploración de lo que podría hacerse, pero no son realmente útiles y, por tanto, que acaba de hacer disponible de forma gratuita con la esperanza de que alguien lo adopte. Otra forma de pensar en ello, decidir la cantidad de su tiempo vale la pena -. Podría tener sentido para pasar un día o dos para conseguir una herramienta de trabajo para usted

Una vez allí, tenga esto en cuenta cuando se va tratar de entender el proyecto:

  1. El Mile High Vista : Un diagrama de arquitectura en capas puede ser muy útil saber cómo el principal conceptos en un proyecto están relacionados entre sí. Herramientas como Lattix y Architexa puede ser muy útil en este caso.
  2. The Core : Trate de averiguar cómo funciona el código con respecto a los conceptos principales . Los diagramas de clases son excepcionalmente útil en este caso. Lápiz y papel funciona bastante a menudo aquí, pero las herramientas no sólo puede acelerar el proceso sino que también ayudará a ahorrar y compartir esos diagramas. Creo AgileJ y Architexa son sus mejores apuestas aquí, pero su herramienta UML promedio a menudo puede ser lo suficientemente bueno.
  3. Clave Casos de uso : Yo sugeriría el rastreo al menos un caso de uso clave para su aplicación. Es probable que pueda obtener el mayor número de casos de uso importante de cualquier persona en su equipo, y paso a paso a través de él va a ser muy útil. La mayoría de IDE son muy útiles aquí. Si intenta dibujar ellos, entonces los diagramas de secuencia arethe más adecuada. Para las herramientas aquí creo MaintainJ , JDeveloper y Architexa son sus mejores apuestas aquí.

Nota: Soy el fundador de Architexa- construimos herramientas para ayudarle a comprender y documentar el código Java , pero he tratado de ser imparcial anteriormente. Mi intención es sugerir herramientas y opciones teniendo en cuenta que esto es lo que me he centrado en como parte de mi tesis doctoral.

  
    

Se almacena en varios archivos. Utiliza diferentes clases con diferentes métodos. El código es grande y complicado.

  

Todo código Java escrito fuera de la escuela es así, sobre todo para un nuevo desarrollador a partir de un proyecto.

Esta es una vieja pregunta, pero como esto está llegando en las búsquedas de Google, añado mi respuesta aquí, así que podría ser útil para los futuros visitantes. También quiero revelar que yo soy el autor de MaintainJ .

No trate de entender toda la aplicación

Permítame hacerle esto - ¿por qué se quiere entender el código? Lo más probable es que está reparando un error o mejorar una característica de la aplicación. La primera cosa que usted no debe tratar de hacer es comprender toda la aplicación. Tratar de entender toda la arquitectura, mientras que empezar de nuevo en un proyecto sólo te abrumará.

Créanme cuando digo esto - los desarrolladores con más de 10 años de experiencia sólida de codificación pueden no entender cómo ciertas partes del trabajo de aplicación incluso después de trabajar en el mismo proyecto durante más de un año (suponiendo que no son los desarrolladores originales) . Ellos no pueden entender cómo funciona la autenticación o la forma en que la gestión de transacciones trabaja en la aplicación. Estoy hablando de las aplicaciones típicas de la empresa con las clases 1000 a 2000 y el uso de diferentes marcos.

dos habilidades importantes que se requieren para mantener grandes aplicaciones

A continuación, ¿cómo sobreviven y se les paga mucho dinero? desarrolladores experimentados suelen entender lo que están haciendo; es decir, si son para corregir un error, se van a encontrar la ubicación del error, a continuación, se fijan y asegurarse de que no se rompa el resto de la aplicación. Si necesitan para mejorar una característica o añadir una nueva característica, la mayoría de las veces, sólo tienen que imitar a una entidad existente que hace una cosa similar.

Hay dos habilidades importantes que les ayudan a hacer esto.

  1. Son capaces de analizar el impacto del cambio (s) que hacen mientras que la fijación de un error. En primer lugar se sitúan el problema, cambie el código y probarlo para asegurarse de que funciona. Entonces, porque saben que el lenguaje Java, así como los marcos 'bastante bien', que pueden decir si va a romper cualquier otra parte de la aplicación. Si no es así, se hacen.

  2. Me dijo que simplemente tienen que imitar para mejorar la aplicación. Para imitar de manera efectiva, es necesario saber de Java bien y entienden los marcos 'bastante bien'. Por ejemplo, cuando se están añadiendo una nueva clase Struts Acción y añadiendo a la configuración de XML, van a encontrar primero una característica similar, tratan de seguir el flujo de esa característica y entender cómo funciona. Pueden tener que ajustar un poco de la configuración (como ser los datos de 'forma' en 'solicitud' que en alcance 'sesión'). Pero si saben los marcos 'bastante bien', que pueden hacer esto fácilmente.

La conclusión es, no es necesario para entender lo que todas las clases 2000 están haciendo para corregir un error o mejorar la aplicación. Sólo entiende lo que se necesita.

centrarse en ofrecer valor inmediato

Así que te estoy desanimando a la comprensión de la arquitectura? No, en absoluto. Todo lo que estoy pidiendo es entregar. Una vez que comience en un proyecto y una vez que haya configurado el entorno de desarrollo en su PC, usted no debe tomar más de una semana para entregar algo, por pequeño que sea. Si usted es un programador experimentado y no entrega nada después de 2 semanas, ¿puede un gestor de conocimientos si realmente trabajando o leyendo noticias deportivas?

Por lo tanto, para hacer la vida más fácil para todos, entregar algo. No ir con la actitud de que es necesario comprender toda la aplicación para ofrecer algo valioso. Es completamente falso. La adición de una pequeña y localizada validatio Javascriptn puede ser muy valiosa para el negocio y cuando lo entrega, el gerente se siente aliviada de que él tiene algún valor para su dinero. Por otra parte, le da el tiempo para leer las noticias deportivas.

A medida que pasa el tiempo y después del parto 5 pequeñas correcciones, que comenzaría a entender poco a poco la arquitectura. No hay que subestimar el tiempo necesario para entender cada aspecto de la aplicación. Dar 3-4 días para entender la autenticación. Puede ser de 2-3 días para entender la gestión de transacciones. Realmente depende de la aplicación y su experiencia previa sobre aplicaciones similares, pero sólo estoy dando los cálculos aproximados. Roba el tiempo entre la fijación de los defectos. No pida ese momento.

Cuando se entiende algo, escribir notas o dibujar el diagrama de clases / secuencia / modelo de datos.

Diagramas

Haaa ... me tomó tanto tiempo para hablar diagramas :). Empecé con la revelación de que yo soy el autor de MaintainJ, la herramienta que genera diagramas de secuencia en tiempo de ejecución. Déjeme decirle cómo puede ayudarle.

La gran parte del mantenimiento es localizar la fuente de un problema o para entender cómo funciona una característica.

diagramas de secuencia MaintainJ generados muestran el flujo de llamada y el flujo de datos para un único caso de uso. Así, en un diagrama de secuencia sencilla, se puede ver qué métodos son llamados para un caso de uso. Por lo tanto, si usted está reparando un fallo, el fallo es más probable que en uno de esos métodos. Sólo solucionarlo, asegúrese de que no se rompa cualquier otra cosa y salir.

Si usted necesita para mejorar una característica, comprender el flujo de llamadas de esa función mediante el diagrama de secuencia y luego mejorarla. La mejora puede ser como la adición de un campo adicional o la adición de una nueva validación, etc Por lo general, añadiendo nuevo código es menos riesgoso.

Si es necesario agregar una nueva función, encontrar alguna otra característica similar a lo que hay que desarrollar, comprender el flujo de llamadas de esa función mediante MaintainJ y luego imitarlo.

Sonidos simple? En realidad, es simple, pero habrá casos en los que va a hacer mejoras más grandes como la construcción de una característica completamente nueva o algo que afecta al diseño fundamental de la aplicación. En el momento en que está intentando algo así, debe estar familiarizado con la aplicación y entender la arquitectura de la aplicación razonablemente bien.

Dos advertencias a mi argumento anterior

  1. Me mencionó que la adición de código es menos riesgoso que cambiar el código existente. Debido a que usted desea tener que cambiar, puede tener la tentación de simplemente copiar un método existente y añadir a ella en lugar de cambiar el código existente. Resistir a esta tentación. Todas las aplicaciones tienen cierta estructura o 'uniformidad'. No lo arruines por malas prácticas como la duplicación de código. Usted debe saber cuando se está desviando de la 'uniformidad'. Haz una programador senior en el proyecto para revisar los cambios. Si tiene que hacer algo que no sigue las convenciones, por lo menos asegurarse de que es local a una pequeña clase (un método privado en una clase de 200 líneas no arruinar la estética de la aplicación).

  2. Si sigue el enfoque descrito anteriormente, aunque se puede sobrevivir durante años en la industria, se corre el riesgo de no comprender las arquitecturas de aplicaciones, que no es bueno en el largo plazo. Esto se puede evitar mediante el trabajo en los cambios más grandes o por un poco menos de tiempo de Facebook. Pasar el tiempo para entender la arquitectura cuando se es un poco libre y documentarla para otros desarrolladores.

Conclusión

Foco en valor inmediato y utilizar las herramientas que ofrecen, pero no seas perezoso. Herramientas y esquemas de ayuda, pero se puede hacer sin ellos. Puede seguir mi consejo con sólo tomar algún tiempo de un programador senior en el proyecto.

Algunos plugins que conozco para Eclipse:

Architexa

http://www.architexa.com/

nWire

http://www.nwiresoftware.com/

Si desea realizar ingeniería inversa del código, se debe tratar de EA

Google CodePro Analytix ?

que puede por ejemplo dependencias de visualización y está libre de (captura de pantalla de cod.google.com):

Captura de pantalla de Google

Aquí es una herramienta no UML que tiene muy buenas características de visualización.

Se puede mapear las líneas de código por clase / método de longitud colores / lado de rectángulos. También puede mostrar las dependencias entre las clases.

http://www.moosetechnology.org/

Lo bueno es que se puede utilizar Smalltalk scripting para mostrar lo que necesita: http://www.moosetechnology.org/docs/faq/JavaModelManipulation

A continuación se puede ver cómo se ve una visualización tales como: http://www.moosetechnology.org/tools/moosejee/casestudy

JUDE Comunidad UML solía ser capaz de importar de Java , pero ya no es el caso. Es una buena herramienta gratuita.

Si su aplicación es muy compleja creo que los diagramas no te llevarán muy lejos. Cuando diagramas se vuelven muy complejas se vuelven difíciles de leer y pierden su poder. Algunos diagramas bien elegidos, aunque genera a mano, podría ser suficiente.

no necesita todos los métodos, parámetro y valor de rentabilidad recogida. Por lo general, se trata sólo de las relaciones e interacciones entre los objetos o paquetes que necesita.

Aquí hay una otra herramienta que podría hacer el truco: http://xplrarc.massey.ac.nz/

Se puede usar JArchitect herramienta , una herramienta bastante completa para visualizar la estructura de su código utilizando el la dependencia gráfico , y que navega el código fuente como una base de datos mediante CQlinq . JArchitect es libre para fuente abierta contribuyentes

Algunos grandes herramientas que uso -

StarUML (permite que el código a la conversión diagrama)

MS Visio

XMind (muy, muy útil para la visión general del sistema)

Lápiz y papel!

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top