Clean Code: Capítulo 1

TLTR: Escribir buen código supone una mayor inversión inicial de tiempo, pero se recupera a la hora de mantenerlo e implementar nuevas funcionalidades.

Visto con perspectiva, un código no es más una representación extremadamente concreta de unos requisitos específicos. Aunque los lenguajes de programación evolucionen y utilicemos lenguajes con un mayor grado de abstracción, siempre seguirá siendo necesario mantener esa precisión y rigurosidad: Siempre habrá código.

“Sabemos apreciar el código bueno porque hemos trabajado con código malo.”

Un código malo es aquél que fue programado con prisa y que muy probablemente carezca de esa precisión. Añadir una nueva funcionalidad será una tarea difícil, el código se volverá cada vez más confuso y la productividad del equipo se reducirá significativamente.

Diferentes programadores reconocidos señalan que un código bueno, además de ser eficiente, debe ser elegante, legible y contener tests, entre otras características.

“Para que un código sea más fácil de leer, escribirlo será más complejo. Y aún así, si es fácil de leer, también será más sencillo continuar escribiéndolo.”

Aunque el concepto de clean code sea subjetivo y cada programador tenga su propia concepción del mismo, sí que hay algunas ideas que en conjunto se consideran buenas practicas entre la comunidad: nombres de clases, métodos y variables pronunciables, métodos que realicen acciones concretas, que el código sea fácil de testar…

En conclusión, tal y cómo adelantaba el autor en la introducción del libro, escribir buen código dependerá del tiempo y de las ganas que se dediquen a asimilar y aplicar estas buenas prácticas.