de Ron Jeffries
Por qué lo he leído
Como casi todos los libros, por recomendación. Ví que lo recomendaba Carlos Buenosvinos, y no pude resistirme. Además, el autor es una leyenda viva del desarrollo del software y del manifiesto Agile, así que tenía que ser un libro de aúpa.
¿Un libro que trata sobre la naturaleza de la profesión a la que te dedicas? A leerlo casi, casi, sin pensarlo.
Qué esperaba y qué encontré
Esperaba un libro largo, pesado. Tipo como una biblia o enciclopedia. Un compendio de mejores prácticas, de leyes no escritas, los 101 mandamientos del desarrollo del sofware.
De eso nada. The nature of sofware development es un libro que se lee con una facilidad pasmosa. Es increíble como Ron Jeffries simplifica hasta los conceptos más complejos de explicar. Hace que el proceso de desarrollo que él explica parezca el único que debe existir, el natural, al que se debería tender si dejáramos que las fuerzas actuaran solas (tipo naturaleza, no sé si se me entiende la metáfora).
Es un libro relativamente corto, con muchas (y muy buenas) ilustraciones. Dividido en capìtulos digeribles muy fácilmente. Un lenguaje llano, sencillo, pero preciso.
Conclusiones
Por supuesto que es un libro donde se describe muchas mejores prácticas. A mí me parece que describe el ideal de cómo se debería desarrollar un proyecto software. Casi tan bueno, que me parece un sueño.
Es un libro que recomendaría leer a todo aquel que su trabajo esté relacionado con cualquier fase en el desarrollo del software: diseño, programador, dueño de producto,…
Qué he aprendido
Las cosas van mejor si cada funcionalidad, también llamada historia, sólo tardamos dos o tres días en implementarla.
Coincido totalmente con esa visión. La sufro cada día. Si algo dentro del equipo nos lleva más de 2/3 días, comenzamos a perder el foco, empiezan a aparecer pequeñas tareas (pues ya que…) que nos hacen desviarnos del objetivo inicial. Y al final, se hace muy difícil dar una historia por zanjada. Si dividimos el trabajo en pequeñas historias entregables y que podamos materializar en menos de 3 días, todo va mejor la mayor parte del tiempo.
Para obtener la mejor calidad, un progreso continuado y una gran predictabilidad, los tests y las refactorizaciones son la mejor forma conocida de trabajar.
Necesitamos un progreso constante, regular e ininterrumpido. Para mantener un progreso ininterrumpido, necesitamos un diseño claro y limpio todo el tiempo. Y para conseguirlo, necesitamos refactorizar nuestro código.
Dos grandes pilares del desarrollo: tests y refactorizaciones
Frases que quiero recordar
Valor es lo que uno quiere
Un experto excelentemente remunerado no debería ser remunerado solamente porque es un experto. Debería ser excelentemente remunerado por ayudar a otras personas a que se conviertan en expertos.
El estilo de funcionalidad a funcionalidad incluye un ciclo completo de desarrollo en cada iteración: requisitos, diseño, codificación y testeo.
Podemos construir todo el diseño primero, o podemos construir cada funcionalidad completamente de una en una, cada una con su base. Lo que no podemos hacer es construir toda la base al principio, así como tampoco podemos construir todas las funcionalidades al principio. Es de lejos mucho más seguro construir una versión simple pero funcional de cada funcionalidad primero.
Trabajamos incrementalmente. Necesitamos un buen diseño relativamente pronto, pero solo necesitamos un pequeño buen diseño.
Toma cada posible idea como una posible forma de comenzar a hacer cosas durante un tiempo. Luego, haz tuyo el proceso, y construye tus propias ideas. ¡Pero mantenlo simple!
Nuestro trabajo no es ceñirnos al plan, es ir corrigiendo el curso para obtener el mejor resultado, no llegar a algún punto fijo.
Lo hacemos mejor no cuando predecimos cuándo habremos terminado, si no cuando elegimos cuándo está terminado (pero es que debemos mantenernos siempre en un estado de terminado de forma constante)
La palabra refactorizar se refiere al proceso simple y regular de mantener el código limpio. Cuando la carretera se convierte en un camino intrincado, lo enderezamos refactorizando el código.