Hector Prats » 13 julio, 2017

Archivos diarios: 13 julio, 2017

Clean Code – Programación clara y comprensible

Clean code

¿No sabes qué es Clean code? Cuando empiezas a programar bastante tienes con aprender las mil cosas que se aprenden y que no tienen sentido hasta que ya te acostumbras y vas memorizando cómo se realizan las cosas. Pero cuando ya te conviertes en profesional, y sobretodo cuando eres tú el que coordina el proyecto a nivel técnico, te das cuenta de que necesitamos un conjunto de buenas prácticas y estándares que nos permita revisar, testear e incluso ampliar la aplicación de una forma sencilla y clara para todos los componentes del equipo.

Robert C. Martin (Robert Martin para los amigos), tiene un conjunto de libros (Clean code y Clean coder) en los que desarrolla la idea de crear un código sencillo de entender y ampliar, e incluso nos detalla algunos trucos para ver de una forma rápida si el código que tenemos delante cumple estas buenas prácticas o no.

Podemos encontrar el libro de Clean code en español y en Inglés. Y se divide en 3 partes:

  1. Explica qué es clean code y cómo realizarlo en nuestros desarrollos.
  2. Nos proporciona ejemplos poco comprensibles y cómo los refactoriza.
  3. En la tercera parte, nos enseña a detectar los casos de código que no siguen estas pautas de clean code.

Os voy a resumir cada capítulo, aunque os sigo invitando a que leais el libro para aprender mejor.

Nombres

Es importante estructurar el código de forma semántica para una fácil y rápida comprensión en la lectura. Un código complejo de leer, nos hará perder muchas horas, nos hará malentendidos y otros retrasos mayores.

Para ello, deberemos prestar atención a la nomenclatura utilizada en variables, métodos, clases, comentarios, tests…etc… y utilizar nombres descriptivos de la tarea que realizan.

Por ejemplo, si quisiera una función que cambia formatos de fecha:

Sin duda, un programador no profesional te pondrá algo como

public function transformaFecha($datetime)

Pero es muchísimo más legible hacer algo así:

public function getMadridDatetimeFromUTCDatetime(Datetime $datetime)

De un rápido vistazo podemos saber que en esta función vamos a recibir un Datetime en formato UTC y con alguna transformación interna va a sacar un Datetime con formato Madrid/Europe.

 

Funciones

Las funciones son mejores cuanto más cortas y testeables son. Una función corta y abstracta, es preferible a una función que realiza todos los pasos de un algoritmo. Además, es muy muy muy dificil hacer un test de una función que sea larga, y además se convierte inútil porque acabamos realizando 40 tests si la función es demasiado específica.

Por ejemplo, si tengo una función que controla si una suma se realiza bien, otra que multiplica, otra que divide y otra que resta, hacer un tests de cada una de ellas (y leer su código) será mucho más sencillo que una en la que haga varias de estas operaciones. En caso de fallo, no me costará nada encontrar qué operación es la que falla y resolverlo.

Comentarios

Si tienes un código que requiere de comentarios, obviamente muy claro no es. Necesitamos que sin ningún tipo de explicación, cualquier programador profesional pueda entender el código de forma rápida. Si este es tu caso, mejor refactoriza tu código.

Sin embargo, sí hay ocasiones en las que necesitaremos comentarios por alguna razón:

  • Comentarios TODO
  • Javadocs en APIs públicas
  • Aspectos legales y posibles consecuencias de cambiar ese código

Formateo

El estilo de formateo es muy importante. Más de lo que pueda parecer. Si eres desarrollador PHP, ya deberias conocer el estandar PSR. Concretamente para este caso, el PSR2.

Objetos y estructuras de datos

por hacer

Manejo de errores

por hacer

Fronteras

por hacer

Tests Unitarios

por hacer

Clases

por hacer

Sistemas

por hacer

Emergencia

por hacer

Concurrencia

por hacer

 

Publicado por: