Buenas prácticas

No es posible hablar de Patrones de diseño sin que hablemos de las buenas prácticas. Las buenas prácticas no son patrones de diseño, en realidad cuando las conocemos nos damos cuenta que son la base de los patrones. También son dictadas desde la misma experiencia y conocimiento que se ha acumulado durante años. Seguirlas nos ayudan de la misma forma que usar estándares a la hora escribir código; si quieren llámenlas consejos, desde el punto de vista de la arquitectura de software son principios de diseño.

Cada principio representa una base fundamental para quienes trabajamos en escribir código, son aquellos consejos de la abuelita, que cuando nos topamos con una situación donde aplican nos decimos: “porque no le hice caso…”

Si los seguimos podremos lograr lo que es el sueño de cualquier programador: Código más flexible y adaptable al cambio, código al que es más fácil dar mantenimiento, es más fácil de entender y de compartir con los compañeros del equipo.

A continuación voy a enumerarlos con sus siglas en ingles, porque es más probable que si buscamos en internet los encontremos usando estas.

 

Principios

Keep It Simple Stupid (KISS)

Este principio nos invita a evitar la complejidad innecesaria, problema muy común entre los programadores. Porque existe la falsa creencia de que si el código es muy complejo el autor debe saber mucho. Situación que en vez de ayudar afecta la calidad del código. En pocas palabras: “Fácil de explicar, fácil de entender”.

Don’t Repeat Your Self (DRY)

Con sus siglas en ingles, toca otro punto sensible en la comunidad de desarrollo: Cada pieza de código debe ser única en todo el sistema, así tendremos un solo punto, donde darle mantenimiento al código. Es muy fácil comprender por qué resulta un problema cuando el código esta duplicado. Si tenemos que hacer algún cambio o adaptación, la complejidad se incrementa exponencialmente. Y siempre corremos el riesgo de no hacer los cambios en todos los lugares donde pusimos el mismo código.

 

You Ain’t Gonna Need It (YAGNI )

Es muy común entre los programadores incluir en nuestro código funcionalidades que “creemos” podrían sernos útiles en el futuro. Es muy simple de llevar a cabo este principio, solo debemos codificar lo que se requiera, incluso cuando usemos interfaces solo debemos escribir el código que necesitamos. Se traduce en menor tiempo de desarrollo.

 

Tell, Don’t Ask

Este principio juega un papel muy importante en la prevención de la creación de clases que dependan unas de otras, o sea cohesivas. Nos dice que al crear Clases debemos fomentar el encapsulamiento, asignándole a cada clase la responsabilidad que le corresponde y evitar que otra clase lleve a cabo la misma tarea. Parece fácil, pero representa tener que identificar las acciones que se deben codificar, para que las clases nos digan que pueden hacer por nosotros y no sea necesario tener conocimiento de la lógica interna de ellas para poder usarlas.

 

Separation of Concerns (SoC)

De todos los principios que aquí les comento, este es el que más esfuerzo requiere para poder llevarlo a cabo, y su razón de ser es en aras de encapsular y aislar las funcionalidades a manera de comportamientos únicos dentro de una clase. El beneficio inmediato es la reusabilidad del código.

 

Comentario final:

Si los entendemos, si los hacemos parte de nuestra filosofía, si al codificar los tenemos en cuenta nuestro código podrá soportar cambios, será adaptable y podremos refactorizar sin piedad; sin temor a que en algún lugar oscuro, en las entrañas de nuestro código, un error fatal este a la espera para atacarnos justo después de liberar…