Código limpio

El libro de "Código Limpio: Manual de estilo para el desarrollo ágil de software", escrito por Robert C Martin, uno de los coautores del más que famoso Manifiesto Ágil, es un libro que todo programador debería tener, y ojo, no solo programador, sino que algún responsable de proyecto le vendría bien su lectura para concienciar a todo el mundo, lo fundamental que es desarrollar un código con calidad, bien estructurado, entendible y la necesidad de refactorizar e invertir este tiempo en ello, con el fin de conseguir hacer un código más mantenible. Es tan importante prestar atención a esto, que el propio autor destaca: 

"La programación es un arte, más que una ciencia"

Fui programador durante muchos años y siempre intenté seguir muchos de los consejos que se comentan en el libro, incluso usando patrones de diseño en aquellos casos donde pudieran aportar. Mi gran salto de calidad fue al empezar a trabajar como becario en una start up. Tuve la suerte de tener como responsable a un crack. Durante la carrera no era muy bueno, tengo que reconocerlo, de hecho si tuviera que rehacer ahora mismo mi proyecto de fin de carrera, no aprovecharía ni una sola línea de código que tiré. Mi punto flaco siempre fueron las pruebas unitarias, muchas veces no teníamos tiempo y ni las exigían. Los tiempos han cambiado para bien, ahora, al menos yo, soy consciente de que tenemos que invertir el tiempo en hacerlas, y nuestra tarea no estará finalizada hasta que las pruebas estén también implementadas. 

Os daré unas frases que más me han llamado la atención del libro, como hago con todos los resúmenes. 

Crear código legible es tan importante como crear código ejecutable. Tenemos que ver la refactorización como algo bueno, un tiempo invertido para mejorar el código y debería realizarse cada cierto tiempo, en ciclos cortos de tiempo y este cuidado del código no acaba nunca. 

Crear código limpio es complicado, no se aprende de un día para otro, ni siquiera al día siguiente de haber leído este libro. Como todo, la maestría te lo da la experiencia. Lo ideal es entrenar, tirar líneas, fallar pronto y aprender del error. Ojo, fundamental aprender del error, no volvamos a cometer los mismos errores una y otra vez. 

Invierte el tiempo tener buen código. La frase de después lo hago, más adelante lo hago, lo ponemos en PRO y después lo mejoramos, y un largo etcétera... Ese "Después" es igual a nunca, es lo que nos dice la experiencia y la realidad.

Tenemos que ser capaces de hacer un código entendible, para ti mismo o para otros que puedan venir. Constantemente tenemos que leer código antiguo como parte del esfuerzo de crear código nuevo. La proporción es de más de 10:1 del tiempo, muy elevada, por eso queremos que la lectura del código sea sencilla, aunque eso complique su creación, por eso es tan importante hacer código entendible. Los programadores experimentados piensan en los sistemas como en historias que contar, no como en programas que escribir.

Respecto a los comentarios, me ha caído un mito, a mi al menos, me ha convencido. Siempre insisto en que se documente el código, pero ahora mi prioridad ha cambiado, después de estas explicaciones. 

No hay  nada más útil que un comentario bien colocado. No hay nada que colapse más un módulo que comentarios innecesarios. No hay nada más dañino que un comentario antiguo que propague mentiras y desinformación. Lo ideal, es que tenemos que expresar lo que queremos en código antes que en comentario. El código cambia y evoluciona, y los comentarios deberían  ir a la par, por eso al autor no les gusta, porque son fuentes de mentiras ya que no.se suelen actualizar. El único comentario realmente bueno es el que no se tiene que escribir, ya que con código se explica. Solo el código tiene  la autentica verdad. No dejar código comentado, eliminarlo, es mejor. Lo podemos recuperar con los controles de versiones. 

Todo programador tiene su estilo, pero el del equipo manda. Se debe acordar un estilo único de formato y todos los integrantes deben aplicarlo. El objetivo es que el software tenga un estilo común. 

El control de errores es importante y fundamental, pero si oscurece la lógica, es incorrecto.  A veces es imposible ver o entender qué hace en código debido a todo ese control de errores. En el libro encontramos técnicas que ayudan a esto de una forma elegante y con estilo.

Límites limpios. Debemos evitar que nuestro código conozca los detalles de terceros, no lo podemos controlar ni debemos dejar que nos controle. De cara al mantenimiento es mejor por si hay cambios en el código de terceros que sea lo más transparente posible para el nuestro. Esto es muy importante, ya que en el día a día es muy normal que usemos librerías de terceros casi como algo normal, no mezcles tu lógica de la aplicación con lógica dependiente de algo que no controlas.

Pruebas. El código de pruebas es tan importante como el de producción. Requiere concentración, diseño y cuidado. Misma calidad y limpieza que el de producción y debe mantenerse siempre para que funcionen, debe ir acorde siempre con modificaciones de algo ya existente y para lo nuevo. Sin pruebas cada cambio es un posible error.

No es necesario hacer un buen diseño por adelantado, de hecho, puede ser negativo ya que impide la adaptación al cambio debido a la resistencia fisiológica de descartar esfuerzos previos. En el caso del software la adaptación y mejora continua es más importante. 

Refactorización. Una de las mejores formas de acabar con un programa es realizar cambios masivos con la intención de mejorarlo. Solución: TDD para garantizar que el comportamiento no ha cambiado. Ya hemos hablado que es una inversión buena, pero con cabeza y poco a poco, para garantizar que los cambios son correctos, y recuerda, cada refactorización implica refactorizar las pruebas para asegurarnos de que siguen funcionando. 

Libro muy recomendado, obligatorio diría yo para programadores. Con tan solo leer el índice te puedes hacer una idea de lo que es necesario hacer para empezar a hacer código limpio.