from journeyman to master
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.
De Eric Ries. 2011. Publicado por Crown Business. 336 páginas
