Desarrollando con principios

O cómo construir una arquitectura de código robusta, limpia y fácil de mantener.

La pureza sí importa

Este principio no siempre puede llevarse a cabo pero es recomendable tratar de basar el diseño de nuestro código en funciones puras, de manera que la dependencia de unos métodos sobre otros sea lo menor posible y el sistema no se vea alterado constantemente por los efectos colaterales de estas funciones.

Una buena manera de conseguir funciones puras es construir métodos simples que sólo se dediquen a implementar una pequeña parte del código. Es decir, que cada una de nuestras funciones tengan una sola responsabilidad. Cuánta más complejidad metamos en nuestro código, más propenso al error se volverá.

Call me by my name

Tal vez unos de los pasos más importante a la hora de escribir código sea el nombrado. Aunque a priori parece la tarea más sencilla a la que nos podemos enfrentar, no siempre resulta fácil llamar a las cosas por su nombre. Uno de los principios básicos del diseño es que los nombres han de ser específicos, representativos y explicativos. Debo entender a la perfección lo que hace esa función o lo que representa esa variable sólo con leer su nombre. Por coherencia y por solidaridad con quien tenga que tratar con mi código en el futuro.

Si me encuentro ante una función a la que le he cambiado el nombre 3 veces y sigue sin explicar bien su funcionalidad, tal vez ese método no sea el más correcto porque, por ejemplo, se dedique a más de una funcionalidad.

Cada oveja con su pareja

Siguiendo la línea de enfrentar los problemas de uno en uno, teniendo tantas funciones puras como pueda y separando responsabilidades, también deben separarse las funcionalidades, ya sólo por sí mismas, sino también por a qué parte de nuestra aplicación afectan.

Generalmente tendremos dos partes muy diferenciadas en nuestro código: una que afecta a la lógica de negocio (a la aplicación en abstracto, lo que pasa por debajo y no veo en la página), y otra que se encarga de la interfaz de usuario, como por ejemplo todo lo relacionado con los elementos del DOM.

Lo más recomendable es evitar a toda costa que un mismo método tenga responsabilidad sobre dos aspectos diferentes de la aplicación, de manera que escribiremos métodos que sólo afecten a la lógica de negocio y otros que sólo afecten a la interfaz de usuario para mantener siempre esas dos partes bien diferenciadas.

(Este artículo se irá ampliando)