Las 4 Reglas del Diseño Simple de Ken Beck son fundamentales para crear un software bien diseñado, facilitando la emergencia de diseños de calidad.
Continuar leyendo «Diseño Simple y Emergente, Código Limpio»
Pruebas de Unidad, Código Limpio
El Diseño Guiado por Pruebas (DGP) nos pide que primero creemos las pruebas de unidad antes que el código de producción.
Clases en Código Limpio
Organización de Clases
Una clase debe ir declarando sus partes en el siguiente orden:
- Constantes estáticas publicas
- Variables estáticas privadas
- Variables de instancia privadas
- Funciones públicas
Se cumple de este modo la regla descendente y permite que el programa se lea como un articulo de periódico.
Objetos y Estructuras de Datos, Código Limpio
Abstracción de Datos
Intenta no mostrar al usuario los detalles de los datos. Intenta mostrarle términos abstractos.
Continuar leyendo «Objetos y Estructuras de Datos, Código Limpio»
Formato del Código en Código Limpio
Cuando escribimos código debemos seguir unas reglas a la hora de darle forma para que gane en legibilidad.
Comentarios, Código Limpio
Los comentarios siempre son fallos.
Debemos usarlos porque no siempre sabemos como expresarnos sin ellos, pero su uso no es motivo de celebración.
Cuando tenga que escribir uno, piense si no hay otra forma de de expresarse en código.
Funciones, Código Limpio
NOMBRE
- Deben ser verbos y los argumentos sustantivos
- Deben ser pronunciables
- Deben ser descriptivos
- No preocuparse por la extensión del nombre, mas vale un nombre largo y descriptivo que uno corto y enigmatico.
- No preocuparse en dedicarle tiempo a elegir un buen nombre.
ARGUMENTOS
- Numero de argumentos ideal : 0
- Máximo numero de argumentos: 3
- Si hay gran cantidad de argumentos, desde el punto de vista de pruebas resulta muy complejo hacer todas las combinatorias posibles.
- Argumento Indicador. No pasar booleano como parámetro a una función. Indicaría que hace mas de una cosa. Mejor dividir en dos funciones, una para cada caso.
TAMAÑO
- Las funciones deben ser de tamaño reducido.
- Mejor muchas funciones de tamaño reducido (3 o 4 lineas) que sean obvias.
- Todas deben contar una historia y cada una debe llevar a la siguiente como contando una historia en orden atractivo.
- No deben tener estructuras anidadas en su interior.
SWITCH
El buen uso de la instrucción switch se puede admitir si:
- Aparecen una vez
- se utilizan para crear objectos polimorficos
- Se ocultan tras una relación de herencia para que el resto del sistema no las pueda ver.
ALCANCE
- Las funciones solo deben hacer una cosa. Deben hacerlo bien y debe ser lo único que hagan. Sin efectos secundarios.
- Solo debe o hacer algo o responder algo, pero no ambas cosas. O cambia el estado de un objeto o devuelve informacion sobre el mismo.
- Una forma de saber que una función hace mas de una cosa es extraer otra función de ella, con un nombre que no sea una reducción de su implementación.
- Debe mantener el nivel de abstracción dentro de la misma función.
- Una función que procese errores no debe hacer nada mas. Si una función incluye try and catch no debe haber mas código después de ahí.
DUPLICACIÓN DE CÓDIGO
La duplicacion implica:
- El doble de riesgo a errores
- El doble de mantenimiento.
- Con cualquier cambio habra que cambiarlo X numero de veces
- Se empeora la legibilidad del codigo.
SOLO UNA ENTRADA Y UNA SALIDA
Las funciones solo deben tener una funcion return.
REGLA DESCENDENTE
El código debe leerse como un libro, de arriba a abajo. Ir de las funciones menos abstractas a las mas abstractas mientras bajamos en el código.
CREACIÓN DE FUNCIONES LIMPIAS
- Primero se escribe el primer borrador. Este puede estar desorganizado, con funciones extensas y complicadas, con bucles anidados ….
- Se hace va haciendo refactor del código poco a poco, mejorandolo. Se retoca el código, se divide las funciones, se cambian nombres, se elimina los duplicados, se reordena,….
- Al final se consiguen funciones limpias. No se escriben al comenzar a programar. Es un proceso el cual hay que seguir.
Números Mágicos
Los números mágicos son números que aparecen en medio del código, y no se define el origen de ese valor en concreto. Se obvia un nombre que los describa. Si no conocemos la lógica de negocio, nos podemos bloquear pensando que significan esas cifras en medio de la nada.
God Object
God Object
El God Object un objeto muy grande, que conoce demasiado o tiene demasiadas responsabilidades distintas.
En este tipo de objetos , toda la funcionalidad del programa esta codificada él.
Usamos esta técnica ocasionalmente para entornos de programación ajustados, donde el aumento de rendimiento ligero y la centralización es más importante que el mantenimiento y la elegancia de programación.
Crear un God Object se le considera una mala práctica de programación. Es un ejemplo de un antipatrón de diseño. Se le conoce también como el anti-pattern. Contradice y viola todas las reglas de diseño y código limpio.
El principal problema de este tipo de objecto es que nuestro código se volverá débil e inestable. Cualquier cambio en él, podrían suponer la aparición de errores o comportamientos inesperados. Además, se haría muy complejo su mantenimiento a largo plazo.
La solución para que podamos deshacernos de este tipo de objecto es que refactorizar el God Object en varios objectos lo más independientes posibles unos de otros.
Nombres con Sentido
En el software los nombres son omnipresentes, los usamos constantemente, por ello debemos hacerlo correctamente.