Reflexiones

Check in early, check in offen

Acabo de leer el artículo Check in Early, Check in offen de Jeff Atwood acerca de la metodología de uso del control de versiones para el desarrollo de proyectos.

Aunque coincido con los artículos de Jeff en muchas ocasiones, esta es una de las situaciones en las que no lo hago.

En primer lugar, como por otro lado suele pasar con este tipo de artículos, las reflexiones que hace son demasiado genéricas y sobre caso demasiado simples como para poder extraer verdaderas conclusiones sobre ellos.

Hacer check in pronto y a menudo. Suena bonito, parece un concepto adecuado pero hay muchas cosas que quedan fuera del análisis, cosas que en un proyecto pequeño con dos o tres desarrolladores no tienen importancia pero que en grandes proyectos pueden dar verdaderos dolores de cabeza.

Uno de los ejemplos que cita es empezar con un código pequeño, que no haga nada y que tenga pocos, por tanto, pocos bug... de esta forma, según razona, podemos probarlo y subirlo al control de versiones. Entonces desarrollamos una nueva funcionalidad, la probamos y la subimos al control de versiones. Todo claro y sencillo...

Test Driven Development (Desarrollo dirigido por las pruebas)

Ultimamente, aquí y allá estoy oyendo hablar del llamado Test Driven Development o Desarrollo guiado por las pruebas como nueva metodología de desarrollo.

Dejadme que os explique un poco como funciona el asunto. La metodología se basa en que el desarrollo de los test guie el desarrollo de la aplicación, de esta forma lo primero que hacemos es planear que necesita hacer la aplicación y en función de ello desarrollamos test para cada una de las funciones, de esta forma disponemos de una prueba para cada función (no os entusiasmeis demasiado con esto ...)

El siguiente paso evidentemente es desarrollar la funcionalidad que consigue pasar ese test, y por tanto, funcionalidad hecha y medianamente probada... perfecto.

La descripción de la metodología tiene más pasos y más guías para el desarrollo y como realizar cada paso. La página de la wikipedia tiene más información para los interesados (que espero que después de leer este artículo sean pocos).

Programación Funcional

Si, como yo, habéis tenido la suerte/desgracia (apliquensé los dos términos) de estudiar programación funcional en la carrera (haskell, lisp, hope o variantes) sin duda pensaríais que aquello era lo menos práctico y lo más inútil que había para programar, en especial si antes ya habíais programado en algún lenguaje imperativo como c o pascarl.

El problema, en mi opinión que viene de mi caso concreto, viene del hecho de que en la universidad se limitan a enseñarte el como, dandote una introducción a la programación funcional y la programación en general, sin preocuparse de enseñarte las vent

Comentado de código y documentación.

Table of Contents [hide]

Comentando código

Realizar comentarios en el código es algo fundamental para la mantenibilidad de este cuando lo volvamos a coger más adelante.

Muchas veces, sobre todo en los proyectos esos que son "para anteayer" las prisas y la necesidad de tener la versión o el producto listo para una determinada fecha hacen que los comentarios de código sean escasos, malos o inexistentes.

Al contrario de lo que puedan decir por ahí no voy a decir, "comenta siempre aunque tengas que retrasarte"; nada más lejos de la realidad, acaba el proyecto, entregalo y consigue el dine