¿Qué es el código limpio?

¿Qué es el código limpio?

Este es el primero de una serie de artículos donde vamos a analizar el contenido capítulo a capítulo del libro clean code publicado en 2008 y que es una precuela del libro Principles, patterns and practices publicado en 2002 ambos por Robert C Martin. Si quieres pueder ir a ver el índice de la serie. También puedes ver la versión en video de esta entrada en nuestro canal de youtube.

Se han escrito mil entradas sobre el que se considera uno de los más importantes libros sobre filosofía de desarrollo de software, pero nosotros en esta serie de entradas queremos profundizar un poco más en cada uno de los capítulos. Si te dedicas a programar y te interesa mejorar en tu profesión quedate. A lo largo de esta serie de entradas vamos a aprender un montón de cosas.

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

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.

Bjarne stroustrup

Bjarne stroustrup

Ha destacado por desarrollar el lenguaje de programación C++ y por ser el autor del libro que se considera de referencia en dicho lenguaje: "programming principles and practice using c++".

Bjarne indica que el código debe ser elegante y eficaz, la lógica debe ser sencilla para evitar errores, el procesamiento de errores debe ser completo, el rendimiento debe ser óptimo. Bjarne concluye que el código limpio hace bien una única cosa.

Grady Booch

Es conocido entre otras cosas por ser uno de los diseñadores del Lenguaje Unificado de Modelado UML.

Grady define que el código limpio debe ser simple y directo. Además el código debe exponer la intención del diseñador.

Grady Booch

Dave thomas

Dave thomas

Es el autor del libro pragmatic programmer que también nos gustaría analizar.

Dave introduce la idea de que el código limpio debe ser fácil de modificar para alguien que no es el autor original. En su opinión el código debe tener tanto pruebas unitarias cómo de aceptación. Los nombres deben tener significado. El código ofrece una única forma de hacer una determinada cosa a través de una API clara.

Michael Feathers

Es el autor del libro working effectively with legacy code.

Michael considera que el código limpio es aquel al que se le ha dado importancia y al mismo tiempo se ha mantenido sencillo. Según Michael cuando te enfrentas a un código limpio no existe una forma fácil de mejorarlo, ya que el autor pensó en todos los aspectos posibles.

Michael Feathers

Ron Jeffires

Ron Jeffires

Es uno de los tres desarrolladores de la metodología eXtreme programming.

Ron nos indica que el código limpio debe seguir las indicaciones de Ken Beck. En orden de prioridad debe contener pruebas, debe evitar la duplicidad, debe expresar los conceptos del diseño y debe mantenerse tan pequeño cómo sea posible.

Ward Cunningham

Es uno de los impulsores de la identificación y estandarización de los patrones de diseño.

Según Ward sabemos que estamos ante código limpio cuando el código hace lo que se espera que haga.

Ward Cunningham

¿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

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.

¿Quieres ser una bestia del desarrollo de software?
¡Continúa con nosotros en YouTube!

Todas las semanas un nuevo vídeo sobre desarrollo de software en tu bandeja de entrada.

Tranquilo, no te vamos a enviar spam.