de Rober C. Martin
Por qué lo he leído
Me decidí a leer este libro porque leyendo varios blogs en español encontré más de una referencia, por lo que parecía un buen libro para leer. Además, conseguí que un amigo me dejara un ejemplar. Todos los requisitos cumplidos.
Qué esperaba
La verdad es que el propio título ya dice bastante: “clean coder”. Esperaba encontrar una guía de buenas prácticas para aplicar en mi día a día profesional, una serie de consejos sobre cómo desarrollar software de calidad, limpio, que sea fácil de leer. Estaba incluso decidido a soportar una lista de tópicos sobre el desarrollo del software, pero estaba seguro de que iba a encontrar consejos/prácticas nuevas y, por supuesto, iba a aprender técnicas útiles.
Qué encontré
La verdad es que no encontré exactamente lo que buscaba. Robert C. Martin nos cuenta más batallitas que otra cosa, pero no nos miente, desde el principio del libro nos advierte que éste es un libro de experiencias personales.
El libro es un conjunto de experiencias, unas buenas y otras malas, del autor, de las cuales, Uncle Bob ha aprendido todo lo que sabe.
El libro también es un conjunto de consejos, una guía, de cómo Robert cree que se debe comportar un desarrollador de software profesional.
Conclusiones
El libro me ha encantado.
El tono que usa Uncle Bob para relatar sus experiencias es informal y cercano. En algunas de ellas puedo ver reflejados a compañeros míos o incluso a mí mismo (aunque ya no trabajamos con tarjetas perforadas, pero la esencia sigue siendo la misma).
Algunos consejos son, para mi gusto, un poco extremistas, pero el autor da sus razones de porqué él cree que debe ser así. Al fin y al cabo, han sido y son sus vivencias y no las impone a nadie. Con otros consejos no estoy muy de acuerdo, pero siempre es bueno conocer otras opiniones.
En definitiva, si te preocupa tu trabajo, éste es un buen libro para conocer qué piensa una de las personas más importantes en el mundo del desarrollo del software. Así es como Robert C. Martin cree que debe ser un profesional:
- Es responsable: cuando un profesional comete un fallo, arregla el desorden que ha provocado
- Usa su conocimiento para construir, no para destruir
- Debe estar seguro de que funciona (tests)
- Conoce el campo en el que trabaja (banca, transporte, …)
- Nunca ridiculiza a los demás
- Trabaja duro para encontrar caminos creativos para decir “si”, para entregar funcionalidad
- La actitud que tiene hacia las interrupciones es de mostrarse voluntarios de poder ser de ayuda. Se ofrece a ayudar a los compañeros si ven que están teniendo problemas
- Programa en parejas
- Mantiene la mente abierta a nuevas tecnologías, ideas, diseños, y acepta que estas novedades pueden ser incluso mejor que las actuales
Pasajes que quiero recordar de este libro
Debes ser responsable de tus imperfecciones, lo primero que debes aprender es a pedir perdón, después debes hacer que tu ratio de errores tienda a cero
Entregar funcionalidad a coste de romper la arquitectura es un error de principiante. Comprometer la arquitectura es comprometer el futuro
Regla del Boy Scout: deja siempre el código un poquito más limpio de lo que te lo encontraste
Tu carrera es tu responsabilidad, no culpes a tu empresa
La mejor forma de aprender, es enseñando. Otra forma de aprender es colaborar con otra gente
Los problemas de tu empresa (quien te paga) son tus problemas
Programar es un acto de creación. Cuando escribes código, estás creando algo de la nada
(Sobre estimaciones y compromisos) Negocia para alcanzar el máximo de las dos partes enfrentadas
La promesa de “lo intentaré” es la aceptación de que guardas un esfuerzo extra, y además es un compromiso de que necesitarás aplicar ese esfuerzo extra para conseguir el objetivo
Agresión pasiva: dejar que tu compañero falle públicamente cuando sabes de antemano que lo que está haciendo fallará
Dilo, comprométete y hazlo. (no lo intentes, hazlo
Programar es una actividad agotadora, que reta tu inteligencia […], si estás cansado o distraído, no programes
Las estimaciones tienen que estar basadas en datos, no incorpores esperanza en tus estimaciones. Y no dejes que los demás tengas esas esperanzas
No aceptes hacer horas extras, excepto si: te lo puedes permitir personalmente, es para un período corto y tu jefe tiene un plan B por si no funciona
La única forma de mejorar la planificación, es reducir el alcance. No caigas en la tentación de correr
Los tests te dan la certeza suficiente para entregar
TDD (desarrollo dirigido por tests) es una disciplina que mejora la certeza, el coraje, reduce los defectos, la documentación y mejora el diseño
Katas:
- http://katas.softwarecraftsmanship.org
- http://codekata.pragprog.com
- http://thecleancoder.blogspot.com/2010/10/craftsman-62-dark-path.html
Tom DeMarco: Una ambigüedad en los requisitos, refleja un conflicto en el cliente
Los tests unitarios y de aceptación, primero son documentos y luego tests
Nada tiene un efecto tan negativo a largo plazo en la productividad de un equipo desarrollador como la deuda técnica
Programar conlleva trabajar con gente. Si quieres pasar tus días desarrollando software, deberás aprender a hablar con la gente
Lleva tiempo que un equipo funcione, por eso, las empresas profesionales, organizan proyectos alrededor de equipos que funcionan, nunca forman equipos alrededor de proyectos nuevos