A veces es útil en mi trabajo modificar el código de fuente abierta de otra persona o descubrir cómo desarrollar cosas específicas para su propia aplicación. Sin embargo, no todo el software tiene buena documentación.
¿Cuál es una buena manera de entender la estructura general de una base de código?
Por ejemplo, qué rutinas llaman qué rutinas, etc. Podría utilizar una herramienta de documentación como Doxygen para este propósito, sin embargo, me preguntaba si hay una mejor estrategia.
software
documentation
Allan P. Engsig-Karup
fuente
fuente
Respuestas:
Los siguientes hilos están relacionados tangencialmente:
Para la primera parte de mi tesis, pasé 18 meses modificando el código Fortran indocumentado, y una de las primeras tareas fue tratar de comprender la estructura general de una base de código. Lo más importante que sugiero que hagas es tomar notas en un archivo de texto cada vez que descubras algo. No querrás tener que volver a aprender o redescubrir cosas durante este proceso frustrante y lento.
En mi caso, no había "API" para hablar, en el sentido de que los argumentos de las funciones no se auto documentaban, porque el programador anterior usaba un estilo similar al de Fortran 77 y, por lo tanto, identificadores cortos con poca o ninguna pista de qué ellos se referían a. No hubo pruebas, y dado que es Fortran, no hay encabezados. Añadiendo aún más diversión a la mezcla, había un par de funciones aquí y allá escritas en C o C ++.
Cosas que funcionaron para mí (suponiendo que trabajes en Linux):
grep. Aprende a amargrep; lo usará en el shell para encontrar dónde se declaran y llaman las funciones, y la salida le dirá en qué archivos buscar.nm. Puede ser útil en las bibliotecas si no tiene código fuente para ellas, pero desea saber si una función que encontró está en esa biblioteca. Sin embargo, solo funciona si los símbolos de la biblioteca no se han eliminado.printdeclaraciones.dddygdbson geniales, y en prácticamente todos los sistemas Linux que existen. Siéntase libre de usar su depurador favorito.Cosas que desearía haber pensado antes, o simplemente no eran opciones para mí:
gcovylcovpara hacer un análisis de cobertura en ejecuciones típicas del código, si tiene ejemplos o ejecutables para trabajar. Si se supone que hay ejemplos que ejecutan grandes partes de la base del código, estas dos herramientas combinadas le dirán cuántas veces se visita cada línea de código. Es más útil con las marcas de depuración habilitadas. Si una parte del código no se visita en absoluto, probablemente sea menos importante entenderlo de inmediato. Si una parte del código se visita mucho, probablemente valga la pena entender de qué se trata. Tal vez el código se ejecuta mucho porque es un bucle sin importancia, o podría ser una función clave en la que se basan muchas otras funciones. No puede decir solo sobre el análisis de cobertura, pero el análisis de cobertura le da una idea de dónde enfocar su tiempo.splintpueden decirle si algo sospechoso está sucediendo en el código, como si algunas variables nunca se usan.dotygraphvizpara generar gráficos de llamadas y ver cuántas veces se llaman las funciones, como el análisis de cobertura. Para códigos complejos, un análisis gráfico podría ser mucho más útil.fuente
Siempre les digo a mis alumnos que lean un código de abajo hacia arriba: comienzas en main () y ves cómo se llama. Por lo general, esto es solo un pequeño número de funciones. Luego, se examinan las funciones llamadas desde main () que generalmente definen el flujo general del algoritmo (bucle de tiempo, ensamblaje, solucionador, salida, etc.). Vaya más o menos dos niveles de profundidad para obtener una visión general del algoritmo de 30,000 pies. El resto a menudo se puede obtener de la documentación de doxygen, etc.
Pero como dije, el mensaje es: lea el código de abajo hacia arriba.
fuente