De Andrew Hunt y David Thomas. 1999. Publicado por Addison-Wesley Professional. 352 páginas
Me habían recomendado mucho este libro y justamente era la propuesta del Club de Lectura de Agile Barcelona, así que lo inicié con muchas ganas. No en vano es una de las primeras influencias del movimiento de Software Craftmanship.
A lo largo de 7 capítulos, los autores presentan 70 consejos (tips) para el desarrollo de software.
Los dos primeros capítulos son fantásticos, propios de esos libros de informática que sabes que no caducan. Pero a partir del tercer capítulo la sensación ha sido "lo he leído diez años tarde".
Sin desmerecer el contenido, que es estupendo, gran parte de las ideas que se presentan ya las tenemos más que asumidas: pruebas unitarias, control de versiones, uso de texto plano, etc.
El consejo que más me ha gustado ha sido el 4, "No vivir con ventanas rotas": reparar los pequeños fallos que van quedando en el código para evitar que otros desarrolladores piensen "puedo hacer esta chapuza, ya que he visto esa otra por ahí".
Los cuentos de la sopa de piedras (ser un catalizador del cambio) y de hervir ranas (nadie se da cuenta de los cambios si vienen poco a poco), también son inspiradores, así como el consejo de good enough software (saber cuándo parar), como un pintor que sabe cuándo dejar de poner pintura.
Los dos primeros capítulos también incluyen como consejo 11 el clásico DRY, Don't repeat yourself, una definición de ortogonalidad, y el consejo de utilizar balas trazadoras (tracing bullets) para tener feedback rápido del cliente. Comentándolo con @jaumejornet, @eidrien y @albertcumplido en el club de lectura, no todos entendimos lo mismo por "balas trazadoras". Los autores presentan la idea en contraposición con la idea de "prototipo": un desarrollo exploratorio construido para posteriormente ser desechado. En ese caso yo entiendo una bala trazadora como el resultado de una iteración en metodologías ágiles. Sin más misterios.
El capítulo tres hace una defensa del uso de ficheros de texto plano y de la línea de comandos. Me recordó mucho la lectura de En el principio fue la línea de comandos (también en inglés) de Neal Stephenson, aunque en otro contexto.
En este capítulo también habla de control de versiones, dominar un editor de texto y "rubber ducking": cuando estás tratando de resolver un bug y estás atascado, comentar tus progresos en voz alta (a un patito de goma). A veces, sólo con tratar de explicarlo te das cuenta de algo que no habías tenido en cuenta. En una empresa en la que trabajé a esto le llamábamos "efecto Furby".
En los capítulos 4, 5 y 6 habla de aserciones, diseño por contrato, la Ley de Demeter, diseñar siempre para concurrencia, diseñar para las pruebas y programar por coincidencia. Esto último es el clásico "si funciona, no lo toques".
En estos capítulos también le dedica una sección a hablar del coste de los algoritmos, con aquello del O(n log(n)), aunque me ha parecido un poco fuera de lugar.
Cuando habla de refactoring propone utilizar la metáfora de la jardinería en lugar de la metáfora de la arquitectura a la hora de hablar del desarrollo de software. Muy interesante.
En el capítulo 7 se ríe de la expresión "recogida de requerimientos" y sugiere que se trata más de "excavar a por los requerimientos". También sugiere separar los requerimientos de las políticas de negocio, porque estas últimas pueden cambiar. Y en el consejo 57 dice que algunas cosas es mejor hacerlas que describirlas (por ejemplo "describe cómo hacerte el nudo de los zapatos").
En el capítulo 8 trata de resumir todo lo descrito en los capítulos anteriores poniéndolo en contexto.
He encontrado que es un libro muy interesante y recomendable, pero tenía las expectativas demasiado altas.
No comments:
Post a Comment