¿Cómo realiza un seguimiento de los grandes proyectos?

Cuando trato con un proyecto que tiene muchos archivos diferentes, siempre parezco perder la noción de cómo las partes interactúan entre sí. En realidad, nunca tuve un gran problema para comprender los componentes más pequeños de forma aislada, pero a medida que aumenta la complejidad del proyecto, me siento incapaz de construir mentalmente una comprensión de lo que está sucediendo. Noto esto especialmente con los proyectos OOP, a medida que aumenta el número de métodos y archivos fuente.

Mi experiencia: soy un programador web autodidacta. He tratado principalmente con python para scripts rápidos y sucios, pero también he realizado algunos proyectos básicos de django . Me gustan los marcos web como el matraz , porque en la simplicidad de un diseño de un solo archivo, puedo hacer un seguimiento fácil (principalmente) de lo que está sucediendo.

Ahora me encuentro en una situación en la que necesito interactuar con un gran proyecto PHP Zend Framework que alguien más desarrolló, y estoy abrumado por tratar de entender el código extendido a numerosos archivos.

¿Qué técnicas y procesos le han resultado útiles para comprender una gran base de código que alguien más ha desarrollado? ¿Hay algún diagrama en particular que encuentre que lo ayude a comprender la imagen más grande?

El truco para comprender una base de código grande es no tratar de comprenderlo todo. Después de un cierto tamaño, no puedes tener un modelo mental en tu cabeza de todo. Comienza con un punto de anclaje que tiene sentido para cualquier tarea en la que necesite trabajar primero, luego se ramifica desde allí, aprende solo las partes que necesita y confía en que el resto funciona como se anuncia. Es como entender la recursividad. Si intentas mantener toda la pila en tu cabeza, tu cerebro explota.

Grep, depuradores e intellisense son tus amigos aquí. Si no sabe cómo se llama una función, establezca un punto de interrupción y avance por el seguimiento de la pila.

La otra cosa a tener en cuenta es que las bases de código grandes no surgen de la nada. Cuanto más grande es, más programadores hay con experiencia en él, así que pregúntales dónde comenzar, pero sé específico. Haga preguntas como "Necesito agregar un nuevo proveedor de pagos. ¿En qué parte del código debo buscar?" Concéntrese solo en esa tarea en lugar de tratar de comprender todo el código base, y pieza por pieza su familiaridad crecerá.

No hay ningún atajo. Solo tienes que sufrirlo.

Para responder a su pregunta sobre cómo obtener diagramas, doxygen es lo que desea. AFAIK funciona con PHP.

En términos más generales, paso por las etapas más o menos siguientes cuando encuentro una nueva base de código:

1. Comprenda lo que hace desde el punto de vista del usuario. Realmente puede usar la aplicación usted mismo como un usuario avanzado. Comprenda cómo los usuarios finales reales trabajan con él. Esto podría requerir sentarse con ellos hasta que obtenga una sólida comprensión de lo que hacen.

2. Comuníquese con los desarrolladores originales, si es posible. Al principio, tendrá preguntas arquitectónicas estimuladas por la experiencia del usuario final. Más adelante, tendrá preguntas de implementación sobre casos límite y detalles. Ser capaz de obtener respuestas de los desarrolladores ayudará mucho más que cualquier comentario o documentación (que es, en el mejor de los casos, incompleta y, a menudo, engañosa o totalmente ausente).

3. Aprenda sobre cualquier marco que esté utilizando. Como mínimo, debería poder crear un "hola mundo" u otra aplicación simple con ese marco antes de sumergirse en la aplicación de producción.

4. Controle todo el proceso de implementación (mejor hacerlo mientras los desarrolladores originales lo sostienen). Si no puede tomar la base de código actual y compilarla e implementarla a través de un entorno de prueba / validación / producción, está brindis. Incluso el cambio más pequeño requerirá saltar a través de todos los aros de implementación, entonces, ¿por qué no eliminar esta parte de inmediato? Al hacerlo, conocerá todos los encantadores servidores, bases de datos, servicios y scripts utilizados por la aplicación; sabrá "dónde vive".

5. Controle las pruebas funcionales (si las hay). ¿Cómo saber si la cosa está funcionando correctamente? ¿Qué tienen que hacer las operaciones para el cuidado y la alimentación de la aplicación?

6. Comprende los registros de la aplicación. Aunque nunca he trabajado con PHP, adivinaré y diré que cualquier aplicación PHP seria tendrá algún tipo de registro. Si comprende los registros, tendrá un buen punto de partida cuando llegue el momento de los problemas de depuración.

---- Tenga en cuenta que hasta aquí, ni siquiera he mencionado mirar de cerca la base de código. Hay MUCHO que puede aprender sobre un gran proyecto sin siquiera mirar el código. En algún momento, por supuesto, debe sentirse cómodo con el código. Esto es lo que me ayuda:

7. Para los diagramas, doxygen es una herramienta excelente que generará gráficos de llamadas y otras relaciones para usted. Resulta que tiene capacidad PHP! Si no ha probado el doxygen, absolutamente tiene que darle una vuelta. Aunque no puedo garantizar cuán inteligible será para el código dentro de un marco, pero podría ayudar. Los desarrolladores originales a menudo se sorprenden de lo que ven cuando se les presentan documentos de su código generados por doxygen. La buena noticia es que realmente ayuda a refrescar su memoria y a ayudarte mejor.

8. Si tiene un conjunto de pruebas unitarias, echar un vistazo de cerca debería proporcionar una ventana al funcionamiento interno de la aplicación. Estos también serán el primer lugar para buscar errores que pueda haber introducido al hacer cambios.

9. Los marcadores IDE son invaluables para etiquetar puntos calientes en la base de código. Ser capaz de alternarlos rápidamente promoverá la comprensión.

10. La lectura de informes de errores recientes y sus resoluciones también son valiosos para comprender los puntos críticos y le ayudarán a ponerse al día sobre las partes más relevantes de la base de código.

Según lo solicitado, aquí está mi comentario como respuesta.

Cuando trabajo con el código de otras personas, tiendo a crear o, si es posible, generar diagramas de clase UML para darme una visión general de la estructura estática. El diagrama visual me ayuda especialmente cuando tengo que volver más tarde y ya olvidé el contexto de una clase. A veces también lo hago por comportamiento dinámico para delinear las interacciones entre colaboradores, pero no lo hago tan a menudo.

Si la base de código contiene pruebas (integración o unidad), a veces vale la pena verificarlas.

De hecho, voy a comenzar a hacer esto durante el transcurso de esta semana, donde un nuevo cliente necesita mejoras para un producto que dejó otro desarrollador. A continuación se detallan los pasos a seguir:

a) Identifique el marco de programación utilizado, que ayuda a saber cómo fluye la aplicación.

b) Identifique servicios comunes: registro, manejo de excepciones, MVC, conexión de base de datos, auditoría, vista (generación de páginas) ya que estas son las partes donde más usaremos.

c) Ejecute los flujos de usuarios comunes (en la aplicación) y luego intente alinearlos con la forma en que se presenta el código

d) Intente hacer algunos cambios y ver cómo salen. Este es el paso más importante porque hasta que comience a hacer cambios, el código sigue siendo un cuadro negro ...

Te dejaré saber qué otras ideas tengo en el transcurso de las próximas dos semanas.

Mi pensamiento es que deberías leer la documentación. Sé que a los piratas informáticos les encanta decirte "el código es la documentación" y usarlo como una excusa para no escribir ninguna documentación, pero están equivocados. Mire el kernel de Linux, un proyecto de software masivo de muchos millones de líneas de código: no creo que alguien realmente pueda llegar fresco sin haber leído un libro y simplemente recogerlo. Si el código con el que está trabajando no está documentado (o bien comentado si se trata de un proyecto más pequeño), entonces probablemente no sea un buen código.

Si está trabajando con algo realmente grande con cero documentación (¡yo también he estado allí, es difícil!), Lo que he encontrado que ayuda es tratar de aislar la parte en la que está trabajando. En esa parte del código, descubra cómo los datos / eventos / mensajes / interacciones pasan dentro y fuera de esa unidad. En otras palabras, aplique ingeniería inversa a la interfaz. Escríbelo. La próxima vez que trabajes en otra unidad (bonificación si habla con la que trabajaste primero), haz lo mismo. Guarde toda su documentación. Después de unos meses de esto, tendrá una buena imagen de cómo fluye la cosa.

Calcule la interfaz de una unidad pequeña en la que está trabajando y regístrela para su posterior consulta. Con el tiempo, unirás la mayor parte de cómo funciona. Encuentre lo que hace su programa y rastree cómo fluye ese mensaje. Por ejemplo, si su sistema toma algún mensaje de red de entrada y envía un mensaje de salida, rastree cómo fluye ese mensaje a través del sistema, sin preocuparse por todos los detalles, solo vea a dónde va.

Lo que hago es crear un único modelo UML a partir de todos los archivos que se han invertido de Java a UML. Este enfoque significa que el modelo ya no es solo una vista abstracta del proyecto, sino que el proyecto en sí está completamente mapeado a MOF y, por lo tanto, a UML.

Lo que obtengo es un modelo único grande compuesto por múltiples submodelos, cada uno compuesto por paquetes compuestos por clasificadores, etc. Trabajar a nivel de proyectos múltiples también me permite rastrear cada clasificador y llamadas a métodos en niveles multiproyecto. Quiero decir que el mismo método puede llamar a un clasificador en el proyecto A y a otro clasificador en el proyecto B. La única forma de ver la estructura completa del proyecto es revertir ambos al mismo tiempo. No tengo tiempo para crear diagramas de componentes y la información no es realmente precisa. Prefiero pedirle a la computadora que revierta el proyecto completo por mí. Hago un reverso en cada iteración con el equipo y todos mis diagramas se actualizan de inmediato. La ingeniería inversa es incremental y utiliza la asignación de Java a UML Ids. Quiero decir que cada elemento de Java se asigna a un elemento MOF único y único que permanece igual durante toda la vida del proyecto, incluso si se refactoriza. Hacer eso no da más límite al modelado UML y permite un modelado de proyectos muy grande y complejo. Para su información, trabajo con proyectos que tienen más de 5 000 000 líneas de código OOP. Todos mis proyectos se invierten correctamente y es posible la navegación gráfica

Solo uso diagramas de clases porque desde mi modelo UML puedo crear tantas vistas como sea necesario, que siempre están actualizadas. También puedo modelar proyectos muy complejos.