una poner para manejo insertar imagenes imagen fondo ejemplo como colorear color codigo java schema uml code-structure code-visualization

java - poner - ¿Cómo debería visualizar la estructura de mi código?



poner color de fondo a un jlabel en java (10)

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 (algún tipo de gráfico dirigido). ¿Hay algunos métodos estándar para la visualización del código? Estoy pensando en el uso de UML (no estoy seguro de que sea una elección correcta). ¿Alguien me puede recomendar algo?

ADICIONAL:

Considero dos posibilidades:

  1. Crear el gráfico por las manos (explícitamente).
  2. Creando gráficos de forma automática. Por ejemplo, para usar algunas herramientas que leen el código disponible y generar algún gráfico que describa la estructura del código.

AGREGADO 2:

Sería bueno tener algo gratis.

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

Todo el código de Java escrito fuera de la escuela es así, especialmente para un nuevo desarrollador que comienza en un proyecto.

Esta es una vieja pregunta, pero como esto está apareciendo en las búsquedas de Google, agrego mi respuesta aquí para que pueda ser útil para los futuros visitantes. Permítanme también revelar que soy el autor de MaintainJ .

No trates de entender toda la aplicación

Déjame preguntarte esto: ¿por qué quieres entender el código? Lo más probable es que esté solucionando un error o mejorando una característica de la aplicación. Lo primero que no debes hacer es comprender toda la aplicación. Tratar de comprender toda la arquitectura mientras se comienza de cero en un proyecto simplemente lo abrumará.

Créanme cuando digo esto: los desarrolladores con más de 10 años de sólida experiencia en codificación pueden no entender cómo ciertas partes de la aplicación funcionan incluso después de trabajar en el mismo proyecto durante más de un año (suponiendo que no sean los desarrolladores originales). Es posible que no entiendan cómo funciona la autenticación o cómo funciona la gestión de transacciones en la aplicación. Estoy hablando de aplicaciones empresariales típicas con clases de 1000 a 2000 y utilizando diferentes marcos.

Dos habilidades importantes requeridas para mantener aplicaciones grandes

Entonces, ¿cómo sobreviven y se les paga mucho dinero? Los desarrolladores experimentados generalmente entienden lo que están haciendo; es decir, si van a arreglar un error, encontrarán la ubicación del error, luego lo arreglarán y se asegurarán de que no rompa el resto de la aplicación. Si necesitan mejorar una característica o agregar una característica nueva, la mayoría de las veces, simplemente tienen que imitar una función existente que hace algo similar.

Hay dos habilidades importantes que los ayudan a hacer esto.

  1. Pueden analizar el impacto de los cambios que realizan al corregir un error. Primero ubican el problema, cambian el código y lo prueban para asegurarse de que funciona. Entonces, debido a que conocen bien el lenguaje Java y los marcos "lo suficientemente bien", pueden decir si romperá otras partes de la aplicación. Si no, están hechos.

  2. Dije que simplemente necesitan imitar para mejorar la aplicación. Para imitar efectivamente, uno necesita conocer bien Java y entender los marcos lo suficientemente bien. Por ejemplo, cuando agregan una nueva clase de acción de Struts y agregan al xml de configuración, primero encontrarán una característica similar, tratarán de seguir el flujo de esa característica y comprenderán cómo funciona. Es posible que tengan que ajustar un poco la configuración (como que los datos del ''formulario'' están en ''solicitud'' que en el ''alcance'' de la sesión). Pero si conocen los marcos lo suficientemente bien, pueden hacerlo fácilmente.

La conclusión es que no es necesario que comprenda qué hacen todas las clases de 2000 para corregir un error o mejorar la aplicación. Solo entiende lo que se necesita.

Enfócate en entregar valor inmediato

Entonces, ¿te estoy desanimando para que no entiendas la arquitectura? No, en absoluto. Todo lo que te pido es que entregues. Una vez que inicie un proyecto y una vez que haya configurado el entorno de desarrollo en su PC, 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, ¿cómo puede saber un gerente si realmente está trabajando o leyendo noticias sobre deportes?

Entonces, para hacer la vida más fácil para todos, entregue algo. No vaya con la actitud de que necesita comprender toda la aplicación para entregar algo valioso. Es completamente falso. Agregar una validación de Javascript pequeña y localizada puede ser muy valiosa para el negocio y, cuando lo entregue, el gerente se siente aliviado de haber obtenido algún valor por su dinero. Además, te da tiempo para leer las noticias deportivas.

A medida que pasa el tiempo y después de entregar 5 pequeñas correcciones, comenzaría a comprender lentamente la arquitectura. No subestimes el tiempo necesario para comprender cada aspecto de la aplicación. Dedique 3-4 días para comprender la autenticación. Puede ser de 2 a 3 días para comprender la gestión de transacciones. Realmente depende de la aplicación y de su experiencia previa en aplicaciones similares, pero solo estoy dando las estimaciones del estadio de béisbol. Robar el tiempo entre la reparación de los defectos. No preguntes por ese momento.

Cuando comprenda algo, escriba notas o dibuje el diagrama del modelo de clase / secuencia / datos.

Diagramas

Haaa ... me tomó tanto tiempo mencionar diagramas :). Comencé con la revelación de que soy el autor de MaintainJ, la herramienta que genera diagramas de secuencia de tiempo de ejecución. Déjame decirte cómo puede ayudarte.

La gran parte del mantenimiento es localizar el origen de un problema o comprender cómo funciona una característica.

Los diagramas de secuencia generados con MaintainJ muestran el flujo de llamadas y el flujo de datos para un caso de uso único. Entonces, en un diagrama de secuencia simple, puede ver qué métodos son necesarios para un caso de uso. Por lo tanto, si está solucionando un error, probablemente el error esté en uno de esos métodos. Solo corrígelo, asegúrate de que no rompa nada más y sal de ahí.

Si necesita mejorar una característica, comprenda el flujo de llamadas de esa característica usando el diagrama de secuencia y luego realce. La mejora puede ser como agregar un campo adicional o agregar una nueva validación, etc. Por lo general, agregar código nuevo es menos arriesgado.

Si necesita agregar una nueva característica, busque alguna otra característica similar a la que necesita desarrollar, comprenda el flujo de llamadas de esa característica usando MaintainJ y luego imítelo.

Suena simple? En realidad es simple, pero habrá casos en los que realizará mejoras más grandes, como crear una función completamente nueva o algo que afecte el diseño fundamental de la aplicación. En el momento en que intentas algo así, debes estar familiarizado con la aplicación y entender la arquitectura de la aplicación razonablemente bien.

Dos advertencias a mi argumento anterior

  1. Mencioné que agregar código es menos riesgoso que cambiar el código existente. Como desea evitar el cambio, puede tener la tentación de simplemente copiar un método existente y agregarlo en lugar de cambiar el código existente. Resista esta tentación. Todas las aplicaciones tienen cierta estructura o ''uniformidad''. No lo arruines con malas prácticas como la duplicación de código. Debe saber cuándo se está desviando de la ''uniformidad''. Pídale a un desarrollador sénior sobre el proyecto que revise los cambios. Si debe hacer algo que no sigue las convenciones, al menos asegúrese de que sea local para una clase pequeña (un método privado en una clase de 200 líneas no arruinaría la estética de la aplicación).

  2. Si sigue el enfoque descrito anteriormente, aunque puede sobrevivir durante años en la industria, corre el riesgo de no comprender las arquitecturas de la aplicación, lo cual no es bueno a la larga. Esto puede evitarse trabajando en cambios más grandes o con menos tiempo de Facebook. Dedique un tiempo para comprender la arquitectura cuando esté un poco libre y documentarla para otros desarrolladores.

Conclusión

Concéntrese en el valor inmediato y use las herramientas que lo brindan, pero no sea flojo. Las herramientas y diagramas ayudan, pero puede prescindir de ellos también. Puedes seguir mi consejo simplemente tomando un tiempo de un desarrollador sénior en el proyecto.

¿Has probado Google CodePro Analytix ?

puede, por ejemplo, mostrar dependencias y es gratuito (captura de pantalla de cod.google.com):

Algunas excelentes herramientas que uso -

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

MS Visio

XMind (muy, muy útil para una descripción general del sistema)

¡Pluma y papel!

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

Puede asignar las líneas de código por clase / método a colores / longitud lateral de rectángulos. También puede mostrar las dependencias entre las clases.

http://www.moosetechnology.org/

Lo bueno es que puedes usar scripts de Smalltalk para mostrar lo que necesitas: http://www.moosetechnology.org/docs/faq/JavaModelManipulation

Aquí puede ver cómo se ve una visualización así: http://www.moosetechnology.org/tools/moosejee/casestudy

Intenté usar varias herramientas UML y descubrí que las capacidades de ingeniería inversa en la mayoría de las herramientas UML no eran útiles para entender el código . Se enfocan en el diseño de las necesidades y las capacidades de ingeniería inversa a menudo acaban mostrando enormes imágenes de mucha información inútil. Cuando estaba trabajando en la base de código de Microsoft Office, encontré que usar un lápiz y papel era más útil que las herramientas típicas de diseño / modelado.

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

  1. Usa tu cerebro : alguien más lo mencionó; no hay sustituto para tratar de entender una base de código. Es posible que deba tomar notas y volver a consultarlas más adelante. ¿Pueden las herramientas ayudar? Seguro. Pero no esperes que hagan la mayor parte del trabajo por ti.
  2. Encuentre documentación y hable con compañeros de trabajo : no hay mejor manera que tener una fuente que describa los conceptos principales en una base de código. Si puede encontrar a alguien que lo ayude, tome un bolígrafo y papel, vaya a él y tome muchas notas. ¿Cuánto molestar a la otra persona? Al principio, tanto como sea práctico para su trabajo, pero ninguna cantidad es demasiado pequeña.
  3. Piense en herramientas : si es nuevo en una parte de un proyecto, va a pasar una cantidad significativa de tiempo comprendiendo el código, así que vea cuánta ayuda puede obtener automáticamente. Hay buenas herramientas y malas herramientas. Trata de descubrir qué herramientas tienen capacidades que podrían ser útiles para ti primero. Como mencioné anteriormente, la herramienta UML promedio se enfoca más en el modelado y no parece ser la adecuada para usted.
  4. Tiempo versus costo : Claro, gratis es genial. Pero si muchas personas no utilizan una herramienta gratuita, es posible que la herramienta no funcione. Hay muchas herramientas que se crearon solo como una exploración de lo que se podría hacer, pero no son realmente útiles y, por lo tanto, están disponibles de forma gratuita con la esperanza de que alguien más las adopte. Otra forma de pensar al respecto, decidir cuánto vale su tiempo, podría tener sentido pasar un día o dos para que una herramienta funcione para usted.

Una vez allí, tenga esto en cuenta cuando intente comprender el proyecto:

  1. La vista Mile High : un diagrama arquitectónico en capas puede ser realmente útil para saber cómo los conceptos principales de un proyecto están relacionados entre sí. Herramientas como Lattix y http://www.architexa.com/ pueden ser realmente útiles aquí.
  2. El núcleo : Trate de descubrir cómo funciona el código con respecto a los conceptos principales . Los diagramas de clases son excepcionalmente útiles aquí. El papel y el lápiz funcionan con frecuencia aquí, pero las herramientas no solo aceleran el proceso, sino que también ayudan a guardar y compartir dichos diagramas. Creo que AgileJ y http://www.architexa.com/ son sus mejores apuestas aquí, pero su herramienta UML promedio a menudo puede ser lo suficientemente buena.
  3. Casos de uso clave : Sugeriría encontrar al menos un caso de uso clave para su aplicación. Es probable que pueda obtener los casos de uso más importantes de cualquiera en su equipo, y dar un paso al frente será realmente útil. La mayoría de los IDE son realmente útiles aquí. Si intenta dibujarlos, entonces los diagramas de secuencia son los más apropiados. Para herramientas aquí, creo que MaintainJ , JDeveloper y http://www.architexa.com/ son sus mejores apuestas aquí.

Nota: Soy el fundador de Architexa: creamos herramientas para ayudarlo a http://www.architexa.com/ , pero he tratado de ser imparcial anteriormente. Mi intención es sugerir herramientas y opciones dado que esto es en lo que me enfoqué como parte de mi doctorado.

JUDE Community UML solía poder importar Java, pero ya no es el caso. Es una herramienta buena y gratuita.

Si tu aplicación es realmente compleja, creo que los diagramas no te llevarán muy lejos. Cuando los diagramas se vuelven muy complejos, se vuelven difíciles de leer y pierden su poder. Algunos diagramas bien elegidos, incluso si se generan a mano, podrían ser suficientes.

No necesita que se describan todos los métodos, parámetros y valores devueltos. Por lo general, solo son las relaciones e interacciones entre objetos o paquetes lo que necesita.

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

No hay ninguna razón por la cual tenga que usar ningún tipo de método estándar de visualización, y puede usar cualquier medio que desee. Papel, pizarra, photoshop, visio, powerpoint, bloc de notas: todos estos pueden ser efectivos. Dibuje un diagrama de clases, objetos, métodos, propiedades, variables, lo que sea que sea útil ver para comprender la aplicación. La audiencia no es solo otros miembros de tu equipo, sino también tú mismo. Crea diagramas que sean útiles para que los mires y entiendas rápidamente. Colóquelos alrededor de su área de trabajo y mírelos regularmente para recordar la arquitectura general del sistema a medida que la construye.

UML y otros estándares de documentación de códigos son buenas pautas para los tipos de diagramas que puede hacer y la información que debe considerar incluir. Sin embargo, es excesivo para la mayoría de las aplicaciones y básicamente existe para las personas que no pueden asumir la responsabilidad personal de documentar sin estándares. Si sigues el UML al pie de la letra, terminarás gastando demasiado tiempo en tu documentación en lugar de crear tu aplicación.