¿Qué es el código limpio?

En esta entrada vamos a realizar una pequeña introducción a los conceptos principales del libro.

Más lento para ir más rápido

A lo largo de este primer capítulo Martin nos introduce la idea de que en muchos proyectos cuando se trata de ir demasiado deprisa el resultado es exactamente el contrario. Si eers programador probablemente hayas vivido esto en tus propias carnes. En el periodo de uno o dos años en los que los programadores han ido añadiendo cambios al código sin control el resultado es que cada vez se hace más y más difícil avanzar y se dedica la mayoría del tiempo a solucionar incidencias. Para añadir cualquier pequeño cambio es necesario tener en cuenta un sin fin de detalles, efectos y consecuencias, así que cada nueva funcionalidad añade aún más complejidad al proyecto.

La solución que aplican muchos managers en este momento es aumentar la plantilla, pero sin cambiar la forma de trabajar, lo que fragmenta más el código y reduce cada vez más la productividad. Más pronto que tarde el equipo de desarrollo se plantará y exigirá "rehacer" el código para sacar una nueva versión, esta vez sin los problemas de la actual. Pero recuerda que si no cambian su forma de trabajar y de pensar, el mismo equipo que generó el problema volverá a generar un problema parecido de nuevo.

Si te has visto en esta situación te aconsejo leer esta serie de entradas sobre código limpio.

Bien, ¿Pero qué es el código limpio?

El libro autor comienza haciéndose el mismo esta pregunta. Para ello recurre a diversos autores relevantes a los que les traslada esta cuestión.

¿Qué conclusiones sacamos?

De todas estas entrevistas se extraen una serie de ideas más o menos comunes.

Que haga lo que se espera que haga

Nosotros en DEVTIA a esta regla la llamámos: "No me mientas". Es también muy fácil de entender cada función y cada clase tiene que hacer exactamente, lo que se espera que haga. Además esto debe ser evidente, no debo necesitar entrar a ver el método para saber que puedo esperar de el.

Pequeño

Esta es una regla fácil de seguir y fácil de entender. Cuanto más pequeño sea nuestro código más fácil será que podamos modificarlo y mantenerlo. Dependerá de cada proyecto y de cada equipo establecer los límites, pero un buen punto de partida podría ser que las funciones y las clases con sus métodos colapsados deberían poder visualizarse completamente en las pantallas que está usando el equipo.

En los siguientes capítulos veremos muchos ejemplos para mejorar este aspecto.

Sin duplicidad

Un error claro de diseño es cuando necesitas copiar y pegar tu código en diferentes sitios. A la larga esto va a introducir errores, ya que cuando alguien actualize una copia, probablemente olvidará actualizar las demás.

Debe tener tests

Casi todos los autores han introducido la importancia de los tests. Tener una buena batería de test nos va a permitir trabajar con nuestro código y poderlo modificar con seguridad de que si estamos rompiendo alguna cosa, los test nos van a avisar.

La regla del boy scout

La regla del Boy Scout se trata de una regla muy sencilla. Originalmente se refiere a lo que hacen los Boy Scout cuando hacen una acampada: dejan el lugar en el que han estado un poco más limpio de como se lo encontraron.

Aplicado al desarrollo de software nos indica que si en nuestro día a día según estamos trabajando en un proyecto podemos ir introduciendo pequeñas mejoras que el autor original no tuvo en cuenta, pero que para nosotros son evidentes. Estos pequeños cambios, en los que podemos incluir desde cambio de nombres, extracción de métodos, pequeños refactorizaciones, solución de bugs, ect, a lo largo de un periodo de tiempo generará un grado de maduración en el código.