Conforme uno programa, uno se va haciendo de gajes el oficio, algunos son malas mañas, otras son malas costumbres, no creo que haya una sóla práctica en el mundo de la programación que sea universalmente tomada como cierta.
La que estoy por contar no creo que sea excepción.
Cuando uno comienza a programar uno utiliza la ejecución de ese programa como método de depuración. Uno escribe unas diez líneas de código, las revisa, las ejecuta e imprime sus resultados. Si el comportamiento es el esperado uno sigue adelante, escribe otras diez o quince líneas de código y vuelve a ejecutar. Es normal cuando uno está iniciándose en el mundo de la programación que uno repita las ejecuciones sólo para cerciorarse de que el código corrió mal y no sólo el resultado se haya impreso mal por casualidad.
La -ejecución- ya sea un lenguaje interpretado o compilado es parte del herramental de la programación, es tan importante como el editor o entorno con el que uno está trabajando. Muchos primerizos eligen ó elegimos el algún momento un IDE en parte por la facilidad de ejecutar el código que teníamos en pantalla. Es de alguna forma el el acercamiento más inocente mientras que también es el más eficaz: probar usando.
Mientras los programas son pequeños uno puede darse el lujo de probar cada puñado de nuevas líneas de código que escribe. Al inicio uno prueba el código cada cinco o seis líneas de código; ejecuta. Conforme uno se siente más cómodo con el entorno y el lenguaje de programación empiezan a ser diez o veinte líneas de código; ejecuta. Sin embargo, veinte, treinta, cincuenta líneas de código empiezan a ser pocos cambios en cuanto a la escala de cosas que a veces hay que cambiar o mejorar. Un claro ejemplo de esto es un motor de videojuegos. Uno puede programar por separado varios componentes, los que siente que serán indispensables para ese motor; sistema de dibujo, sistema de sonido, cola de eventos de periféricos, cola de eventos de las entidades en pantalla. Uno puede programar todas estas cosas por separado, uno puede probarlas por separado y saber más o menos cómo se están comportando. Uno puede escribir y probar en fragmentos de cincuenta o setenta líneas nuevas a la vez. El problema real llega al momento de integrar.
En el ejemplo del motor de videojuegos el verdadero problema recae en la interdependencia de estas diferentes partes móviles. Si bien uno puede programar varias APIs por medio de las cuales se pueden reducir y gestionar las interacciones entre diferentes secciones de código, en el momento en el que uno debe integrar todas éstas partes móviles es donde he encontrado que se da a sentir la experiencia del programador.
Aunque son pocos, existen los programadores ordenados, éstos, aun cuando son novatos son capaces de realizar pruebas unitarias, fragmentar cada uno de los pasos que dan y logran avanzar en un proyecto más y más grande. A pesar de que el orden pueda ser nuestro mejor aliado, no es necesariamente la manera más veloz o eficiente de hacer las cosas. Cuando hay prisa, uno compila menos. Con la experiencia llega una extraña habilidad (y mala costumbre) de poder llevar quince, cincuenta, cien, quinientas, incluso mil líneas de código en la cabeza sin tener que ejecutar ese código una sola vez.
No estoy muy seguro de qué tan conveniente sea programar de esta forma. Por analogía, es como cuando un escalador de montañas empieza a usar menos y menos protección, se asegura en intervalos más y más distantes entre sí. Esto aligera el ritmo de trabajo, indudablemente, ¿pero a qué costo? ¿Habrá algo que debamos recordar de cuando éramos más novatos?
Puede ser que esta reflección sea algo autoevidente para muchos programadores que ya hayan alcanzado esa capacidad de programación y abstracción. En mi caso, aún siento muchas veces esa ansiedad que me dice "no has probado el código desde hace como dos días ¿seguro te acuerdas de todos los cambios que había que hacer?" pero supongo que es, como todo, parte de crecer.
-Marroja