Código limpio, software mantenible

La elaboración de un software mantenible recae cien por ciento en el desarrollador, para él es súper importante que el código sea legible, mínimo, elegante, eficaz y en la medida de lo posible, construido para un objetivo en específico.

Para lograr lo expresado en el párrafo anterior es de gran utilidad aplicar los principios SOLID, Clean Code y Scout.

Los cuales menciono a groso modo, de los mismo podemos detallar de mejor forma en la web:

·       S – Single Responsibility Principle (SRP) – Principio de responsabilidad única.

·       O – Open/Closed Principle (OCP) – Principio Abierto/Cerrado.

·       L – Liskov Substitution Principle (LSP) – Principio de sustitución de Liskov.

·       I – Interface Segregation Principle (ISP) – Principio de segregación de la interfaz.

·       D – Dependency Inversion Principle (DIP) – Principio de inversión de dependencias.

Clean code: Código limpio, cuyo principal enemigo es el código duplicado, y similar a solid, necesitamos que sea entendible, mínimo y eficaz.

Scout: La regla del Boy Scout dice: «deja el campamento más limpio de cómo te lo encontraste». Es decir, en caso de mantenimientos o de continuar el desarrollo de otro ingeniero de desarrollo, se debe dejar el código igual o mejor que como lo encontramos, siempre hay oportunidades de mejora.

Aplicando los principios de las metodologías mencionadas, aseguramos que Consulting Group desarrolla software que sea mantenible a través del tiempo y las mejoras que con el paso de este se deban implementar, así mismo un código limpio y mantenible hace posible que cualquier especialista entienda de manera más rápida y eficaz lo que el desarrollador anterior realizó en el método o clase que se esté cambiando. Un pequeño ejemplo siguiendo un flujo de desarrollo normal, sería el siguiente:

Se requiere una función que reciba dos variables, las sume y luego divida, retornando como resultado la suma de ambas operaciones, a dicho calculo le llamaremos exponente Consulting. En un inicio se podría desarrollar un método como este:

//método que se encarga de tomar la variable 1 y la variable 2 la suma y divide, y suma el resultado de ambas operaciones.

        private static int Calcular(int v1, int v2)

        {

            return (v1 + v2) + (v1 / v2);

        }

Tenemos inicialmente un comentario explicando que realiza el método en cuestión, el nombre del método y que recibe dos variables v1 y v2. El código anterior al ser un método pequeño y fácil podría ser entendible para la mayoría de los desarrolladores, el detalle es que cuando un método es muy complejo y se desarrolla de esta manera, las variables pueden tomar distintas interpretaciones o dificultar el entendimiento del código. Ahora aplicaremos los principios mencionados al inicio del post.

//método que se encarga de tomar la variable 1 y la variable 2 la suma y divide, y suma el resultado de ambas operaciones.

        private static int Calcular(int variableUno, int variableDos)

        {

            var suma = variableUno + variableDos;

            var division = variableUno / variableDos;

            return suma + division;

        }

Luego de este primer filtro, observamos que aún tenemos un comentario explicándonos que realiza la función, y el principal cambio es que las variables ya nos indican de entrada que se esta realizando y obteniendo con cada una de las operaciones.

private static int CalcularExponenteConsulting(int laVariableUno, int laVariableDos)

        {

            var resultadoDeLaSuma = Sumar(laVariableUno, laVariableDos);

            var resultadoDeLaDivision = Dividir(laVariableUno, laVariableDos);

            return resultadoDeLaSuma + resultadoDeLaDivision;

        }

private static int Dividir(int elDividendo, int elDivisor)

        {

            return elDividendo / elDivisor;

        }

 private static int Sumar(int laVariableUno, int laVariableDos)

        {

            return laVariableUno + laVariableDos;

        }

En esta última extracción del código, vemos como separamos los métodos encargados de realizar las operaciones a métodos nuevos, lo que permite poder reutilizarlos de ser necesario en otros sectores del código, como también en su efecto, si se necesitara realizar algún cambio se haría en un solo sector y afectando a todo el sistema. También observamos que al escribir en prosa se hace innecesario tener comentarios que con el paso del tiempo puede que no se actualicen y sean obsoletos, en cambio al incluir la explicación en el nombre del método, eso hace que el propio código sea el encargado de explicarse.

            En conclusión, al inicio y al final del código, tenemos un código mas legible, más eficaz y eficiente y por tanto más fácil de mantener al través del tiempo. Con la seguridad de que cualquier compañero con o sin conocimiento del código podrá entenderlo de una mejor y más rápida manera. De igual forma, cualquiera podría mejorar lo existente, por lo que el código mismo evolucionaría interactivamente.