Regla KISS – Keep it super simple

Otra de las reglas para escribir software simple y robusto es la regla KISS.

El acrónimo de KISS significa Keep it super simple (manténlo super simple). 

Esta regla indica que la mayoría de las aplicaciones funcionan mejor si se mantienen simples en lugar de complicadas; Esta regla busca que la simplicidad debe ser un objetivo clave en el diseño y se debe evitar la complejidad innecesaria.

Algunas soluciones para seguir esta regla es aplicar código limpio y utilizar algunos paradigmas para abordar la resolución de problemas como pueden ser el de divide y vencerás y las reglas de programación SOLID.

Siguiendo la regla de KISS crearemos un software estructurado en clases y módulos simples donde sea fácil localizar cada dato y función.

Regla DRY – Don’t repeat yourself

En el artículo sobre reglas para escribir software simple y robusto hablamos de 5 reglas para mantener la simplicidad. Una de estas cinco reglas y la más fácil de entender es la regla DRY cuyo acrónimo significa Don’t repeat yourself (No te repitas a ti mismo). Esta regla aparece por primera vez en el libro The pragmatic programmer.

Esta regla implica que cada pieza de conocimiento debe tener una representación única dentro del proyecto. Esto implica que no se deben repetir partes como la lógica de negocio en distintas partes del proyecto.

Esto reduce el código repetido en el proyecto y hace que nuestras clases y módulos sean más reutilizables.

Si no seguimos esta regla y tenemos elementos repetidos para hacer algún proceso del modelo de negocio, el día que tengamos que actualizar esa función o proceso deberemos invertir tiempo en localizar todas las partes donde se repite dicho proceso y actualizar el código.

Reglas para crear software simple y robusto

Se considera que una aplicación software es robusta cuando puede seguir funcionando en condiciones adversas e impredecibles.

A la hora de crear un software robusto una de sus primeras reglas es hazlo simple. Desde su código, escribiendo limpio y legible, hasta su arquitectura utilizando patrones de diseño. Todo esto nos lleva a seguir un estilo de diseño simple a la hora de definir nuestro proyecto software.

La navaja de Ockham

La simplicidad en el software mejora nuestro proyecto en su ejecución y en su mantenimiento. Gracias a que su código es simple de leer podemos entender mejor su estructura y su funcionalidad y gracias a que la relación entre módulos, clases y funciones es simple la detección de errores o la incorporación de nuevas características es menos estresante.

Muchas ramas de la ingeniería buscan esta simplicidad debido a la idea del principio de economía o el principio de la navaja de Ockham.

Este principio dice que en igualdad de condiciones, la explicación más simple suele ser la más probable». Esto implica que, cuando dos teorías en igualdad de condiciones tienen las mismas consecuencias, la teoría más simple tiene más probabilidades de ser correcta que la compleja.

Las cinco reglas para mantener la simplicidad

Con la evolución y la historia de la creación de software han ido apareciendo una serie de reglas que nos ayudan a mantener la simplicidad dentro del diseño de nuestro software. En futuros artículos iremos viendo cada una de estas cinco reglas.

Código limpio con comentarios útiles

Un código con buenos comentarios ayuda a su legibilidad como vimos en el artículo sobre cómo escribir código limpio y legible.

Cada bloque de código tiene un propósito, puede recibir parámetros y puede devolver un resultado. Toda esta información debería estar explicada brevemente en un bloque comentado, preferentemente antes de los bloques de ejecución. Por ejemplo:

// Función calculaPrecioFinalDeCarrito

//    Calcula el precio final del carrito ajustando impuestos y conversión de moneda

//

// Entrada:

//    lista de productos, tipo de impuestos, tipo de moneda

// Salida:

//    precio final a pagar por el cliente

function calculaPrecioFinalDeCarrito(listaProductos, tipoDeImpuestos, tipoMoneda) {

    var precioSinImpuestos = calculaPrecioDeListaDeProductos(listaProductos)

    var precioConImpuestos = calculaImpuestos(precioSinImpuestos, tipoDeImpuestos)

    var precioFinal = convierteAMoneda(precioConImpuestos, tipoMoneda)

    return precioFinal

}

Pero se debe ser breve y evitar comentar todo lo que hace el código línea a línea explicando sólo lo esencial.

Se debe explicar el porqué de las cosas y no cómo se hacen. Un buen código se da a entender por sí solo y no necesita extensos comentarios para ello.

Consistencia y legibilidad para un código limpio

En el artículo sobre cómo escribir código limpio y legible hablamos de la necesidad de coherencia cuando escribimos código.

Legibilidad por encima de la simplicidad

Algunos lenguajes de programación permiten realizar varias operaciones en una sola línea de código. Por ejemplo en Swift, Java o C++ podemos crear una instancia de clase, llamar a uno de sus métodos y realizar una comparación dependiendo del resultado de esa llamada todo en una sola línea de código. Esto reduce el número de líneas que pueda tener una función pero no mejora la legibilidad del código ya que quizás esas características del lenguaje de programación no son conocidas por todos los programadores.

Recuerda escribir el código para que lo pueda leer otra persona, porque incluso hay altas probabilidades que esa otra persona seas tú y puede que no entiendas tu propio código pasado unos meses o años.

Consistencia en la arquitectura de un proyecto

Una de las decisiones principales a tomar cuando empezamos un proyecto software es la de qué patrón de diseño utilizaremos para la arquitectura de nuestra aplicación.

Una vez tomada esta decisión debemos evitar mezclar arquitecturas ya que aumentamos la complejidad a la hora de entender cómo se organiza nuestro proyecto.

Código limpio sin código inutil

En el artículo sobre cómo escribir código limpio y legible hablamos de la necesidad de un código que no tenga bloques de código inútil.

Estos bloques de código inútil se originan normalmente cuando estamos probando un código de forma temporal para hacer un experimento en nuestro proyecto.

Activando y desactivando bloques de código

Dentro de un proyecto de software puede que durante una ejecución de prueba controlada nos interese desactivar un bloque de código y activar otro. Esto se consigue gracias a las instrucciones para añadir comentarios en un código.

Cada lenguaje de programación posee uno o varios métodos para comentar un trozo de código. Por ejemplo la función original sería:

Funcion calcularImpuesto() {

    calcularImpuestosDelCarrito()

}

Y para nuestro experimento quedaría así:

Funcion calcularImpuesto() {

    // Comentamos la siguiente línea para la prueba

    // calcularImpuestosDelCarrito()

    // Usamos el experimento

    calcularImpuestosDelCarritoDeOtraForma()

}

El problema

El problema aparece cuando dejamos esos comentarios porque nos ha gustado más el resultado de la prueba. El código resultante está lleno de bloques inútiles que dificultan la lectura del código.

La solución consiste en quitar esos bloques de código y dejar sólo el código útil. El ejemplo quedaría al final así:

Funcion calcularImpuesto() {

    calcularImpuestosDelCarritoDeOtraForma()

}

¿Cómo no perder esos bloques comentados?

Puede que para nuestro proyecto nos interese no perder ese código alternativo que al principio estaba desactivado con comentarios y que posteriormente borramos para mejorar la limpieza de nuestro código.

Para evitar perder este código alternativo lo mejor es utilizar un sistema de gestión de versiones de código como Git o Mercurial.

Con estas herramientas podemos tener varias versiones de nuestro proyecto e ir manteniendo el código límpio en todo momento sin perder nada ya que con la herramienta de gestión de versiones podemos consultar código más viejo en cualquier momento.