Al igual que ayer estrené la sección de Meetups, hoy inauguro la sección de “Libros de Desarrollo”. Si hay dos cosas creo que son esenciales en un desarrollador, una es asistir a charlas y eventos de nuestra profesión y la otra leer literatura técnica. Existen multitud de lecturas recomendadas y clásicos que no pueden faltar en tus estanterías como el clásico libro de Sistemas Operativos de Tanenbaum o el Clean Code de Robert Martin.

En los últimos meses estoy mucho mas comprometido en invertir tiempo en libros de desarrollo y me gustaría recomendar los libros de desarrollo más interesantes y útiles para aplicar los conceptos en nuestro día a día como desarrolladores.

Para comenzar fuerte con esta categoría, el primer libro sugerido es la gran obra maestra “Clean Code” de Robert. C Martin.

El Autor: Robert Cecil Martin

Robert Cecil Martin ( conocido en el mundo de desarrollo como el Tio Bob) es un ingeniero de software y autor de varios libros de desarrollo. Robert es co-autor del Manifiesto Ágil junto a Martin Fowler y otros gurús, que han marcado un antes y un después en el desarrollo de software y ha impulsado la penetración de las metodologías ágiles en el mercado del software.

Robert es el culpable de que en tus desarrollos apliques conceptos como los principios SOLID, Test Driven Development, Arquitectura Clean o movimientos como el Craftmanship Software.

El Libro: Clean Code

Clean Code es un libro de referencia que todo desarrollador de software debería de leer una vez en la vida y aplicar las filosofías de trabajo que se describen en este libro. Clean Code se trata de una filosofía del desarrollo del software que reúne un conjunto de ideas que pretenden conseguir que el código que implementemos esté bien estructurado, y sea comprensible, mantenible, extensible y  robusto.

¿Cuantas veces te ha tocado enfrentarte a realizar cambios en un Código Legado y has encontrado cantidad de código dificilmente entendible y sin ningún tipo de documentación? Robert propone que el propio código fuente sea autodescriptivo y se comporte como la propia documentación. ¡Escribir código como si de un libro se tratara!

Este libro está dirigido a todo desarrollador de software que desee dar un salto de calidad  profesional y mejorar en el diseño de su software. Estoy seguro que este libro te enseñará a aplicar muchos conceptos y crear código de calidad. En todo momento el libro intenta inculcar la importancia de que el código sea entendible por otros desarrolladores.

Entre las reglas y principios que reúne y propone Clean Code nos encontramos con los siguientes:

• Nombra adecuadamente las variables, los métodos y las clases. Como hace poco escuché en mi último empleo y creo que llevaba razón el autor de la frase, “Dar nombres a las cosas es una de las cosas mas dificiles de la profesión”.  Se debe de intentar dar semántica a todos los elementos siendo nombres claros y concretos de la responsabilidad que tiene.
• Unidades de código pequeñas:  Se recomienda que las funciones no tengan más de 20 lineas (un palmo de mano) y unas 500 por clase. El objetivo es hacer funciones y clases fáciles de entender y con una responsabilidad clara.También se recomienda no superar más de un nivel de anidamiento y cada bifucarción de un if sea una sola llamada a otra función
• Principio de Responsabilidad Única. Este principio es uno de los principios SOLID que se proponen el libro y algo que tenemos que tener en cuenta en todo momento para mantener un acoplamiento bajo y que las clases desarrolladas hagan una sola cosa.
  Si tu clase realiza mas de una cosa quizás debas de dividirla en dos clases, antes de que crezca de forma descontrolada. ¡REFACTORIZA!
• Controla el número de argumentos. Robert recomienda tener un máximo de 3 parámetros y apuesta por la encapsulación de éstos en objetos que modelen estas entradas de una forma más semántica (Data Transfer Objects)
• Don’t Repeat Yourself. Un buen desarrollador debería de evitar el copy paste (duplicidad de código). Este principio de diseño software es básico. Hay que evitar el código duplicado a toda costa y existen herramientas nos ayudan a identificar estas porciones de código (hasta el propio IDE).Apoyate en la refactorización, la abstracción y el uso de patrones de diseño para desarrollar mejor soluciones. Es absurdo testear lo mismo repetidas veces, y un cambio implica cambiarlo en el resto de porciones de código idénticas.
• Evita los comentarios. ¿Cuantas veces has visto trozos de código comentados en medio de una clase o funciones ultra comentadas explicando paso a paso que realizan? Robert propone que añadir un comentario en el código debe estar muy justificado e implica que el código no es auto-explicativo.
  Robert propone reescribir el código y nombrar las cosas de una forma que le de valor semántico
• Coding Style. Robert trata conceptos como la densidad vertical, la ubicación de los conceptos, la longitud de las lineas y el estilo del código para adecuarse al estándar del equipo siendo el código lo más homogéneo posible.
• Ley de Demeter. Nuestros objetos no deberían conocer como funcionan sus dependencias y llamarles como si de una caja negra se tratara.
  Si queremos realizar una acción nos la debería de ofrecer la misma clase y no sus clases relacionadas haciendo llamadas anidadas de métodos.
• Trabaja con excepciones en lugar de códigos de retorno. Esto consigue separar la lógica del camino adecuado realizando una gestión  de errores robusta manejada por los try catch adecuados. El nombre de las excepciones deberían de dar un significado semántico y ofrecer mensajes de error descriptivos.
• Testing. Robert hace énfasis en el testing y en los frameworks xUnit para validar que tu software funciona correctamente. Hace leves referencias a trabajar aplicando Test Driven Development que ayuda a definir tu software.
• Regla del Boy Scout. Esta regla dice “deja las cosas mejor de como te las encontraste”. Un código desordenado, con poca semántica y poco intuitivo, nos incitará a realizar la primera ñapa que se nos ocurra.Sin embargo un código limpio, ordenado y bien estructurado nos provocara justo lo contrario, y desearemos no mirar a otro lado si vemos algo que podamos refactorizar a su paso. Atrévete a mejorar el software, la responsabilidad es de todo el equipo no de la persona que implementó que parte del software. Apóyate en los Code Review para homogeneizar el equipo y que todos se sientan parte de él.

Capítulos del libro

• Capítulo 1: Clean Code.
• Capítulo 2: Meaningful Names.
• Capítulo 3: Functions.
• Capítulo 4: Comments.
• Capítulo 5: Formatting.
• Capítulo 6: Objects and Data Structures.
• Capítulo 7: Error Handling.
• Capítulo 8: Boundaries.
• Capítulo 9: Unit Tests.
• Capítulo 10: Classes.
• Capítulo 11: Systems.
• Capítulo 12: Emergence.
• Capítulo 13: Concurrency.
• Capítulo 14: Successive Refinement.
• Capítulo 15: JUnit Internals.
• Capítulo 16: Refactoring SerialDate.
• Capítulo 17: Smells and Heuristics.