language-agnostic legacy-code

language agnostic - La mejor forma de familiarizarte con una base de código heredada



language-agnostic legacy-code (13)

Stacker Nadie preguntó por la cosa más impactante que encuentran los nuevos programadores al ingresar al campo .

Muy alto en la lista, es el impacto de heredar una base de código con la que uno debe familiarizarse rápidamente. Puede ser un verdadero shock encontrarse repentinamente a cargo de mantener N líneas de código que han sido mezcladas por quién sabe durante cuánto tiempo, y tener un corto tiempo para comenzar a contribuir.

¿Cómo absorber eficientemente todos estos nuevos datos? ¿Qué facilita esta transición? ¿Es la única solución real que ya ha contribuido a suficientes proyectos de código abierto que el shock desaparezca?

Esto también se aplica a los programadores veteranos. ¿Qué técnicas usas para facilitar la transición a una nueva base de código?

Agregué la etiqueta Community-Building a esto porque también me gustaría escuchar algunas historias de guerra sobre estas transiciones. Siéntase libre de compartir cómo manejó una curva de aprendizaje particularmente estresante.

Escribir pruebas unitarias Encontrará las verrugas más rápido, y tendrá más confianza cuando llegue el momento de cambiar el código.

Intente comprender el código solucionando errores en él. Corrija o mantenga la documentación. No modifique los comentarios en el código mismo, que corre el riesgo de introducir nuevos errores.

En nuestra línea de trabajo, en términos generales no hacemos cambios al código de producción sin una buena razón. Esto incluye cambios cosméticos; incluso estos pueden presentar errores.

No importa cuán repugnante parezca una sección de código, no se sienta tentado a reescribirla a menos que tenga una corrección de error u otro cambio que hacer. Si detecta un error (o posible error) al leer el código tratando de aprenderlo, registre el error para una clasificación posterior, pero no intente arreglarlo.

Lápiz y portátil (no te distraigas intentando crear una solución no solicitada)

  • Tome notas a medida que avanza y tómese una hora cada lunes para leer y organizar las notas de las semanas anteriores

  • con grandes bases de código, las primeras impresiones pueden engañar y los problemas tienden a reacomodarse rápidamente mientras se familiariza.

  • Recuerde que los problemas de su último entorno de trabajo no son necesariamente válidos o pertinentes en su nuevo entorno. Tenga cuidado con las nociones preconcebidas.

  • Las notas / observaciones que haga le ayudarán a aprender rápidamente qué preguntas hacer y de quién. Esperamos que haya recopilado los nombres de todas las partes interesadas oficiales (y no oficiales).

Lo primero que hago antes de pasar al código es usar la aplicación (como varios usuarios diferentes, si es necesario) para comprender todas las funcionalidades y ver cómo se conectan (cómo fluye la información dentro de la aplicación).

Después de eso, examino el marco en el que se creó la aplicación, de modo que pueda establecer una relación directa entre todas las interfaces que acabo de ver con algún código de vista o UI.

Luego miro la base de datos y los comandos de la base de datos que manejan la capa (si corresponde), para entender cómo se almacena esa información (qué usuarios manipulan) y cómo va y viene de la aplicación

Finalmente, después de aprender de dónde provienen los datos y cómo se muestran, miro la capa de lógica de negocios para ver cómo se transforman los datos.

Creo que cada arquitectura de aplicación se puede dividir de esta manera y conocer la función general (quién es quién en su aplicación) podría ser beneficioso antes de depurarla realmente o agregar cosas nuevas, es decir, si tiene tiempo suficiente para hacerlo.

Y sí, también ayuda mucho hablar con alguien que desarrolló la versión actual del software. Sin embargo, si va a dejar la compañía pronto, mantenga una nota en su lista de deseos (lo que querían hacer para el proyecto pero no pudieron debido a limitaciones presupuestarias).

Mis pasos serían:

1.) Configure una fuente de información (o cualquier buen explorador de código fuente que utilice) área de trabajo / proyecto con todos los archivos fuente, encabezado, en la base de código. Browsly en un nivel superior desde la función más superior (principal) a la función más baja. Durante esta búsqueda de códigos, siga tomando notas en un papel o en un documento de Word que rastree el flujo de las llamadas a funciones. No entres en nitti-gritties de implementación de funciones en este paso, mantenlo para iteraciones posteriores. En este paso, haga un seguimiento de qué argumentos se pasan a las funciones, los valores de retorno, cómo se inicializan los argumentos que se pasan a las funciones, cómo se modifica el valor de los argumentos establecidos, cómo se usan los valores de retorno.

2.) Después de una iteración del paso 1.) luego de que tenga algún nivel de código y estructuras de datos usadas en la base de código, configure un MSVC (o cualquier otro proyecto de compilación relevante de acuerdo con el lenguaje de programación de la base de código), recopile el código, ejecutar con un caso de prueba válido, y un solo paso a través del código nuevamente desde main hasta el último nivel de función. Entre las funciones, las llamadas mantienen moviendo los valores de las variables pasadas, devueltas, varias rutas de código tomadas, varias rutas de código evitadas, etc.

3.) Continúe repitiendo 1.) y 2.) de forma iterativa hasta que se sienta cómodo hasta el punto en que pueda cambiar algún código / agregar algún código / encontrar un error en el código existente / corregir el error.

-ANUNCIO

No sé si esto es "la mejor manera", pero algo que hice en un trabajo reciente fue escribir un código spider / parser (en Ruby) que pasó y se creó un árbol de llamadas (y un árbol de llamadas inversas) que Podría consultar más tarde. Esto fue un poco no trivial porque teníamos PHP que llamaba a Perl que llamaba a funciones / procedimientos SQL. Cualquier otra herramienta de rastreo de código ayudaría de manera similar (es decir, javadoc, rdoc, perldoc, Doxygen , etc.).

Leer cualquier prueba unitaria o especificaciones puede ser bastante esclarecedor.

Documentar cosas ayuda (ya sea para usted o para otros compañeros de equipo, actuales y futuros). Lea cualquier documentación existente.

Por supuesto, no subestimes el poder de simplemente hacerle preguntas a un compañero de equipo (¡o a tu jefe!). Al principio, pregunté con la frecuencia necesaria "¿tenemos una función / script / foo que haga X?"

Repase las bibliotecas principales y lea las declaraciones de funciones. Si es C / C ++, esto significa solo los encabezados. Documenta lo que no entiendas.

La última vez que hice esto, uno de los comentarios que inserté fue "Esta clase nunca se usa".

Trate de entender la lógica comercial detrás del código. Una vez que sepa por qué se escribió el código en primer lugar y qué se supone que debe hacer, puede comenzar a leerlo, o como alguien dijo, prolly arreglando algunos errores aquí y allá.

Una cosa que los usuarios de vi y emacs pueden hacer es usar etiquetas. Las etiquetas están contenidas en un archivo (generalmente llamado TAGS). Usted genera uno o más archivos de etiquetas mediante un comando (etags para vmags de emacs para vi). Luego editamos el código fuente y vemos una función o variable confusa que carga el archivo de etiquetas y que lo llevará a donde se declara la función (no es lo suficientemente bueno). De hecho, he escrito algunas macros que te permiten navegar por la fuente usando Alt-cursor, algo así como popd y pushd en muchos sabores de UNIX.

BubbaT

Una de las mejores formas de familiarizarse con el código heredado es ensuciarse las manos. Comience por corregir algunos errores simples y trabaje en los más complejos. Eso lo calentará al código mejor que tratar de revisar sistemáticamente el código.

Si hay un documento de especificaciones funcionales o de requisitos (que es de esperar actualizado), debe leerlo.

Si hay un documento de alto nivel o de diseño detallado (que, afortunadamente, está actualizado), probablemente deba leerlo.

Otra buena forma es organizar una sesión de "transferencia de información" con las personas que están familiarizadas con el código, donde ofrecen una presentación del diseño de alto nivel y también hacen un recorrido por partes importantes o engañosas del código.

crea documentación para cada cosa que hayas averiguado de la base de código. descubra cómo funciona por exprimentation - cambiando algunas líneas aquí y allá y vea qué pasa. utilice geany ya que acelera la búsqueda de variables y funciones de uso común en el programa y lo agrega a autocompletar. averigüe si puede ponerse en contacto con los desarrolladores originales de la base de códigos, a través de Facebook o buscando en Google para ellos. descubra el propósito original del código y vea si el código todavía se ajusta a ese propósito o si debe volver a redactarse desde cero, en cumplimiento de la finalidad prevista.

averigüe qué marcos usó el código, qué editores usaron para producir el código.

La forma más fácil de deducir cómo funciona un código es replicar realmente cómo una determinada parte habría sido hecha por usted y volver a verificar el código si existe tal parte.

es ingeniería inversa: resolver algo simplemente tratando de rediseñar la solución.

la mayoría de los programadores de computadoras tienen experiencia en la codificación, y hay ciertos patrones que puedes buscar si están presentes en el código.

hay dos tipos de código, orientado a objetos y orientado estructuralmente.

si sabe cómo hacer ambas cosas, está listo, pero si no está familiarizado con una u otra, deberá volver a aprender a programar de esa manera para comprender por qué se codificó de esa manera.

en el código orientado objetado, puede crear fácilmente diagramas que documenten los comportamientos y métodos de cada clase de objeto.

si está orientado estructuralmente, es decir, por función, cree una lista de funciones que documente qué hace cada función y dónde aparece en el código.

No he hecho ninguno de los anteriores, ya que soy un desarrollador web, es relativamente fácil descubrir desde index.php hasta el resto de las otras páginas cómo funciona algo.

buena suerte.

Otro procedimiento ...

Después de leer "Pragmatic Thinking and Learning - Refactor Your Wetware" de Andy Hunt (que no aborda esto directamente), recogí algunos consejos que pueden valer la pena mencionar:

Observar el comportamiento:

Si hay una IU, mucho mejor. Utilice la aplicación y obtenga un mapa mental de las relaciones (por ejemplo, enlaces, modales, etc.). Mire la solicitud de HTTP si esto ayuda, pero no le dé demasiado énfasis; solo quiere un conocimiento ligero y amigable con la aplicación.

Confirme la estructura de la carpeta:

Una vez más, esto es luz. Simplemente vea lo que le corresponde y espere que la estructura sea lo suficientemente semántica; siempre puede obtener información de alto nivel desde aquí.

Analizar Call-Stacks, Top-Down:

Vaya y liste en papel u otro medio, pero intente no escribirlo; esto involucra diferentes partes de su cerebro (construya fuera de Legos si es necesario) - llamadas de función, objetos y variables que son más cercano al nivel superior primero. Mira las constantes y los módulos, asegúrate de no sumergirte en las características detalladas si puedes evitarlo.

¡MindMap It !:

Tal vez el paso más importante. Cree un mapeo de borrador muy aproximado de su comprensión actual del código. Asegúrate de ejecutar rápidamente el mapa mental. Esto permite una distribución uniforme de diferentes partes de tu cerebro (principalmente R-Mode) para opinar en el mapa.

  1. Cree nubes, cajas, etc. Dondequiera que inicialmente piense que deberían ir en el papel. Siéntase libre de denotar cajas con símbolos sintácticos (por ejemplo, ''F'' -Función, ''f'' -cierre, ''C''-Constante,'' V''-Global Var, ''v''-low-level var, etc.). Utilice las flechas: matriz entrante para argumentos, saliente para devoluciones o lo que le resulte más natural.
  2. Comience a dibujar conexiones para denotar relaciones. Está bien si parece desordenado, este es un primer borrador.
  3. Haga una revisión rápida y aproximada. Es demasiado difícil de leer, haga otra organización rápida , pero no haga más de una revisión.

Abra el depurador:

  1. Valida o invalida cualquier idea que tengas después del mapeo. Seguimiento de variables, argumentos, devoluciones, etc.
  2. Rastree las solicitudes HTTP, etc., para tener una idea de dónde provienen los datos. Mire los encabezados por sí mismos, pero no profundice en los detalles del cuerpo de la solicitud.

¡MindMap Again !:

Ahora debería tener una idea decente de la mayor parte de la funcionalidad de nivel superior.

  1. Crea una nueva MindMap que tenga algo que te perdiste en la primera. Puede tomar más tiempo con este e incluso agregar algunos detalles relativamente pequeños, pero no tenga miedo de las nociones previas con las que puedan entrar en conflicto.
  2. Compare este mapa con su último y elimine cualquier pregunta que tuviera antes, anote nuevas preguntas y anote las perspectivas conflictivas.
  3. Revisa este mapa si está demasiado borroso. Revise todo lo que quiera, pero mantenga las revisiones al mínimo.

Finja que no es código:

Si puede ponerlo en términos mecánicos, hágalo. La parte más importante de esto es crear una metáfora para el comportamiento de la aplicación y / o partes más pequeñas del código. Piensa en cosas ridículas, en serio. Si fue un animal, un monstruo, una estrella, un robot. ¿Qué tipo sería? Si fue en Star Trek, para qué lo usarían. Piensa en muchas cosas contra las cuales pesar.

Síntesis sobre análisis:

Ahora quiere ver no ''qué'' sino ''cómo''. Cualquier parte de bajo nivel que pueda atravesar durante un ciclo se puede sacar y poner en un entorno estéril (usted controla sus entradas). ¿Qué tipo de resultados estás obteniendo? ¿Es el sistema más complejo de lo que pensaste originalmente? Más simple? Necesita mejoras?

¡Contribuye algo, amigo !:

Escriba una prueba, corrija un error, coméntelo, resúmalo. ¡Debería tener la capacidad suficiente para comenzar a hacer contribuciones menores y EL NO ESTOY BIEN :) ! Nota sobre cualquier cambio que haya realizado en commits, chat, correo electrónico. Si hiciste algo cobarde, puedes atraparlo antes de que salga a producción: si algo está mal, es una gran manera de conseguir que un compañero de equipo te aclare las cosas. Por lo general, escuchar una conversación de un compañero de equipo aclarará un montón que hizo que tus MindMaps choquen.

En pocas palabras, lo más importante es usar una forma descendente de obtener tantas partes diferentes de su cerebro involucradas como sea posible. Incluso puede ser útil cerrar su computadora portátil y mirar su asiento por la ventana si es posible. Los estudios han demostrado que aplicar una fecha límite crea una "Resaca a presión" durante ~ 2.5 días después de la fecha límite, por lo que a menudo es mejor cumplir los plazos en un viernes. Entonces, SEA RELAJADO, NO HAY UN TIMECRUNCH, Y AHORA PROVEER UN ENTORNO CON UN ENTORNO QUE NO PIERDA . La mayor parte de esto puede acelerarse bastante hasta llegar a los detalles. Asegúrese de no omitir la comprensión de los temas de alto nivel.

Espero que esto te ayude también :)