Últimamente tengo que estar mirando mucho código que no es mío y, como todo el mundo sabe (¡o debiera! xD) el código de un ente y de otro pueden (y serán) muy diferentes, o hasta el mismo estilo de programación de una persona puede variar con el tiempo o con las necesidades/obligaciones/malestares/etc que tuviera en el momento de la creación de dicho código.

Y claro, una de las fases de vida de un proyecto (y la que es la más larga y tediosa), es la manutención de dicho código.

Así que nos encontramos con que hay que ampliar/mejorar/arreglar/etc un cacho de trozo de programa que sabe alguien para que sirve y que no hay alma en pena que entienda las malevolencias que debe hacer (yo perjuro que es una maldición en arameo), pero hay que tragarse el ego (nadie lleva bien que le insulten) y tratar de entender las maldiciones que suelta dicho ente.

Bien, lo que se suele decir es que con una buena documentación previa y con comentarios en el código se puede hacer ésto más o menos bien. Con esta premisa estoy de acuerdo, pero la considero insuficiente.

Lo siguiente, una vez que entiendes un poco lo que hace, es probarlo y ver que rejóspitos hace. Con ésto aprendemos más de la misión del ente y como lo hace. Si encima tenemos una batería de pruebas con el que saturarlo, tendremos todavía más información, dado que nos encontraremos con un contexto “virtual” de dicho ente.

Vale, ya lo tenemos, sabemos que hace y sabemos que queremos modificarlo y, por eso, atacamos al código para ver cómo lo hace… Y aquí nos quedamos con los comentarios anteriores y el saltar de función en función manualmente (o con ayudas del IDE haciendo click encima de la función, o viendo una lista de llamadas)… ¡Y nada más!

No sé si os pasa a vosotros, pero personalmente echo mucho de menos que no haya una herramienta visual para ver como cada función se comunica con otras, ver las llamadas que salen y las que entran, hasta inclusive inclustar eso en un debugger. Sé que hay por ahí una herramienta de pago que hace algo parecido a ésto (creo que está todavía en una versión beta) y que estoy seguro que mejora la interpretación del código antiguo de una manera antológica.

Imaginaros el que estáis viendo una función grande, que no sabéis muy bien como funciona… Encima llama a muchas funciones externas con un montón de parámetros… Tienes que dedicarle mucho tiempo por mucha información que nos den los IDEs actuales (o los grep de toda la vida :D). Con una herramienta que nos mostrara visualmente cada función (o similar) como un ente, con las llamadas a otras y los parámetros pasados y así poder ir navegando a través de las funciones rápidamente y visualmente, nos ayudaría enormemente.

Después de tantos diagramas, comentarios, documentación… ¿por qué una herramienta tan básica no existe?

  1. Yo… he visto cosas que vosotros no creeríais… acceder a variables globales desde más allá de Orión, he visto lanzar consultas a una BD Oracle para saber la fecha actual…

    Todos esos momentos se perderán en el código como lágrimas en la lluvia.

    Es hora de morir (o de matar a quién lo escribió).

  2. Una herramienta asi supongo que ayudaría bastante.

    Aunque yo he trabajado con el debugger de Visual C y la verdadn es que era una maravilla. Podias poner watch en todas las variables que quisieras, probar expresiones regulares, tenias una pila de llamadas a funciones y podias hacer step into en funciones externas.

    No es lo que tu dices, pero la verdad es que aydaba un huevo a entender como funcionaban las cosas.

    Hail to the Hypnotoad!

  3. Sip, el infierno es el código de otro y los IDEs que conozco todavía tienen mucho que recorrer. Lo bueno es que muchos pasos previos ya están dados (Eclipse permite sacar una lista de las clases llamadas y de las llamantes, en cascada), así que es cuestión de que alguien se apoye en hombros de gigantes y vea más lejos.

    Una herramienta también muy útil para averiguar qué demonios hace código ajeno es cambiar las variables/parámetros al vuelo, a ver por donde revienta. Eclipse, el amigo de los desarrolladores, lo permite a partir de algunas versiones de Tomcat y Jboss. Es un gustazo ver desmoronarse un sistema por un inocente null.

  4. Batería de pruebas… Depuradores… debes ejecutar el código de cabeza leñe!! XDDD

    Ahora en serio, el debugger de Eclipse es impresionante. Las pegas vienen cuando no siempre puedes depurar en remoto o local, y hay que recurrir al traceo log4J paranoico

  5. 1. Sinceramente hay veces en que me preocupas un poco… ¿qué fue de ti con el efecto 2000? O_O

    2. Los debugger molan y ayudan mucho… pero no es lo mismo ;)

    3. Cuanta mala leche para ver como revientan las cosas ajenas… si es que hay que ver como os saltáis las condiciones de una caja negra :P

    4. Las trazas son tus amigas… repite el mantra ;)

    5.6. ¡Eso mismo! Y por duplicado además :D

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>