Archive | octubre 2011

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.

Anuncios

Mi retrospectiva de la XPWeek 2011

Puede ver una versión activa de este post en mi nuevo blog. He decidido dejar de publicar en este blog por éstas razones. Su filosofía es la misma que éste, pero espero no tener los problemas que me he encontrado aquí.

El lunes 19 asistí como oyente al día de conferencia que formó parte de la XPWeek. Fue una lástima que no pudiera asistir a ninguno de los cursos sobre TDD que se impartieron en los días siguientes :-(.

Hacía mucho tiempo, mucho, que no participaba en alguna conferencia así, y la experiencia me encantó (pienso seguir hacer proposiciones indecentes a mi empresa para poder asistir a todas aquellas que pueda).

Me encantó poder conocer en persona a Carlos Blé, ver en vivo y en directo a Jose Manuel Beas (la lástima es que se me escapó y no pude presentarme, otra vez será). De Enrique Amodeo también había oído hablar, y me gustó mucho su presentación. De los demás ponentes no tenía referencias, pero sentí la pasión que tienen sobre el mundo del software. Encantado de conoceros.

Las presentaciones fueron las siguientes:

  • TDD con el stack Objective-C, por Alejandro Pérez, diapositivas, más material
  • 9 rules to better OO, por Sebastián Hermida, diapositivas
  • BDD de fuera a dentro, por Luismi Cavallé, diapositivas
  • CoffeeScript, por Guillermo Pascual, diapositivas
  • No metodologías, por León, diapositivas
  • CSS orientado a objetos, por Enrique Amodeo, diapositivas
  • BDD y arquitectura Javascript, por Carlos Benítez, diapositivas
  • Testing con Spring 3, por Israel Alcázar, diapositivas

(Sigo atento a que los ponentes vayan colgando sus diapositivas, y algún que otro vídeo que se grabó).

La sensación general con la que me quedo de la conferencia es positiva. No necesitaba que nadie me convenciera de las virtudes de TDD y BDD, pero ver que se pueden llevar a cabo con muy distintas tecnologías, y conocer a gente apasionada por ellas, me motivó bastante para seguir intentando seguir estas metodologías y continuar atrayendo a mis compañeros hacia ellas.

Pero (sí, lo siento, tengo un “pero”) eché de menos que se hablara más de metodologías ágiles, más acerca de las metodologías en general. Tengo la sensación de que sólo se habló de TDD y BDD, aunque sé que hubo una charla sobre metodologías en general, que tuvimos tiempo de hablar con quien quisiéramos de lo que quisiéramos, pero, no sé, es una sensación, y tengo claro que me encantaría repetir.

De la conferencia me llevo unos contactos (@fperezsorrosal, @jalbertopaz), unos cuantos fans de groovy (@yurenaghm, @juanmagomer y @arturoherrero) y las ganas de volver a ser parte de eventos como éste.