R. Chavarria's Blog

Proud of developing software, proud of being an Engineer

The clean coder

The Clean Coder: a code of conduct for professional programmers

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:

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.

Comments