¿Cómo entender los proyectos/bibliotecas de código abierto?

Question

Hay pocos proyectos de código abierto/API/bibliotecas que utilizamos en nuestro proyecto (Spring, Struts, iBatis etc.) y quiero entender su diseño y cómo funcionan internamente.

¿Cuál es la mejor manera de entender estos proyectos? Tenga en cuenta que ya estoy usando estas bibliotecas en mi proyecto. Y sé la interacción/configuración de entrada-salida para estas bibliotecas. Lo que no entiendo es cómo estas API/bibliotecas funcionan internamente.

Los problemas que enfrentamos es:

1. Encontrar la clase de entrada de la biblioteca. ¿Hay alguna manera de que pueda conocer la clase de entrada de la biblioteca, algo que está impulsando toda la API?
2. Herramientas/Complementos para usar en Eclipse para obtener una visión general del diseño de la biblioteca. Pasar por todas y cada una de las clases de la biblioteca puede ser una tarea muy desalentadora. ¿Hay alguna herramienta que le gustaría recomendar que pueda generar los diagramas de clase de la API en Eclipse?

¡¡¡Gracias de antemano !!

---

ACTUALIZACIÓN: Necesito algunas entradas de plugins de Eclipse que me puede ayudar a obtener un diagrama general/clase de la biblioteca

Answer 1

Siempre uso la misma estrategia para esto: nunca trato de "entender" la base de códigos como un todo, y generalmente trato de seguir el flujo de solicitudes. Leo lo suficiente de la documentación para determinar qué es necesario para usar la aplicación, y leo ese código (mantenga todo el código fuente cargado en su IDE).

Por ejemplo, en struts instalará un filtro de servlet en web.xml. Comience a leer el filtro y siga la ruta que una sola solicitud toma a través de su pila.

Del mismo modo para la primavera, hay dos puntos de entrada principales, el filtro y "getBean", los cuales se mencionan muy al principio de la documentación. Lee esos dos.

Para estos dos casos, encontrará una o dos clases que representan el "núcleo" del marco real rápidamente. Léalos realmente bien y deje que los casos de uso real & necesiten impulsar su exploración adicional.

Acercarse a la "comprensión" de una biblioteca de código abierto (o cualquier otra base de código para ese asunto) al tratar de encontrar todas las piezas generalmente no es una buena forma de abordar estas cosas, por lo general no conduce a nada porque Muchas de estas cosas contienen demasiado código. Cuando sigo el flujo de solicitudes, encuentro que hacer diagramas también puede distraer bastante, tiende a llamar la atención/enfoque lejos de la comprensión (y dado que mi comprensión aumenta rápidamente, la mayoría de ellos están desactualizados incluso antes de que lleguen a la impresora).

Answer 2

Niza pregunta !!!, lo que he hecho, especialmente en El caso de Spring, además de consultar la Documentación y sus API es adjuntar las fuentes del proyecto a mi proyecto en Eclipse, de esa manera puedo navegar a través del código fuente, no solo de la API. Ha sido muy útil especialmente en el caso del proyecto Spring-Security, había algunos conceptos que no podía entender hasta que inspeccioné el código fuente.

Esa es una de las ventajas de utilizar las bibliotecas de código abierto.

Atentamente.

Answer 3

La mejor opción para esos tres sería consultar la documentación oficial (asegúrese de que está buscando la versión que está utilizando) u obtener un libro sobre la tecnología.

Answer 4

La mayoría de las API no tienen una clase con un método principal; se están ejecutando en el servidor web llamado por el servidor en sí. A menos que se estén ejecutando como su propio servidor, no tendrán un método principal.

Answer 5

Las herramientas como Structure101 (http://www.headwaysoftware.com/products/structure101/index.php) y Lattix (http://www.lattix.com/) le permiten analizar el código y producir diagramas de arquitectura/matrices de dependencia.

Esto no es exactamente un diagrama de clase: el foco principal está en la estratificación. Entonces, el punto de entrada suele ser la capa superior.

Pero una vez más, como he especificado anteriormente, notará que algunas librerías son solo un desastre, y estas herramientas no serán lo suficientemente útiles.

Ver la demostración en línea S101: http://www.structure101.com/java/ Esto por ejemplo es la arquitectura del proyecto Sonar: http://www.structure101.com/java/tracker/sonar/1.11.1/arch.html