Tuesday, July 14, 2009

La programacion es como un juego de ajedrez

Por mucho tiempo he pensado que el desarrollo de software es como un juego de ajedrez, pero aparentemente nadie ha hecho esta analogia antes, solo basta *bingearlo* para ver que hay exactamente (al tiempo de escribir este post) cero resultados (los mismos resultados en Google), afortunadamente esta situacion esta a punto de revertirse al tiempo que escribo este post y todo mundo vee la luz... o talvez no


Y bien, permitanme explicarles un poco sobre mi analogia

El programador mediocre
Uno podria argumentar que este es el programador promedio, pero eso es otra historia, este hace un movimiento sin pensar en los efectos secundarios, su capacidad de analisis es muy poca, hay tantos efectos secundarios (introducir nuevos bugs, seguridad, etc) pero este jugador ni siquiera esta enterado de ello, basicamente se basa en el debugueador y si corre en su maquina entonces esta listo; cuando las cosas inevitablemente no funcionan en produccion el simplemente hace otro movimiento que parece corregir el problema, este ciclo es frecuentemente repetido, si le das un proyecto grande a este tipo muy seguramente hara un movimiento estupido que resultara en Jaque Mate en el proyecto

El buen programador
Este analiza diferentes rutas y escoge la que cree adecuada, este jugador puede hacer un buen juego, de vez en cuando su analisis falla y comete algunos errores, pero el puede aprender de estos, este tipo normalmente entrega buen software con pocos errores que puede corregir rapidamente sin muchos problemas

El mejor
Genio, Guru o como quieras llamarle, este tipo puede hacer una gran cantidad de movimientos rapidamente, y todo en su cabeza, esta informado siempre de las mas recientes tecnicas para vencer a su oponente, pero no cae en el error de simplemente usarlas en su juego, sino que las prueba primero en sus proyectos privados y una vez que el mismo comprobo que son utiles entonces las usa en proyectos reales, conoce las tecnicas mas rapidas, cortas y que le dan el mayor beneficio, sabe las tecnicas para usar en los proyectos pequeños y las que debe usar en proyectos grandes, y sabe tambien que son muy diferentes, este jugador sabe lo que el oponente esta pensando, sabe como respondera el oponente a cada uno de sus movimientos asi que escoge cuidadosamente el mejor movimiento, este jugador conoce los efectos secundarios; las palabras "funciona en mi maquina" no estan dentro de su vocabulario.

Como podran ver las diferencias principales en mi analogia son la capacidad de analisis (seleccionar el movimiento) y los efectos secundarios (que pasa despues de hacer el movimiento). El oponente es tu proyecto de software, el movimiento es escribir el codigo, los efectos secundarios son todo lo demas que es afectado por este.

Cuando fue la ultima vez que creaste un nuevo bug cuando arreglabas aquel otro o agregabas funcionalidad a tu applicacion? o cuando *ellos* encontraron errores en la aplicacion justo despues de lanzarla a produccion? o cuando funciono en tu maquina pero no en el servidor?

Cada vez que vas a hacer un movimiento, detente un momento y piensa en los efectos secundarios, siempre hay efectos secundarios, si no puedes identificarlos, hay herramientas que te pueden ayudar a pensar, como las pruebas unitarias, y entre mas lo practiques, mejor jugador seras, y eso es una promesa

No comments: