“La vida es muy simple, pero insistimos en complicarla”.
Confucio
¿Qué es Clean Code?
Siempre podemos perfeccionar nuestro código. Nada es perfecto, aunque siempre habrá fallas, pero usted, como desarrollador profesional, puede esforzarse por hacer que el código sea lo más “limpio” posible. Es por eso que aquí contemplaremos algunos puntos rápidos para ayudarlo a comprender todos los factores involucrados para hacer que su código sea un “código limpio”…
El Clean Code o código limpio, es un código que es fácil de leer, como un libro donde cada palabra se transforma en una imagen y en realidad puede visualizar todo. Como ver una película, en resumen, debe ser legible por humanos.
El código debe ser fácil de cambiar.
El código solo hace una cosa a la vez.
La persona que escribe el código está realmente ‘Preocupada’ por quién lo lee y/o lo mantiene.
La lógica es sencilla y no deja espacio para que aparezcan errores. No tienta a otros a modificarlo, lo que empeorará el código.
El código está enfocado en cada función, las clases exhiben la responsabilidad que tienen, y esta permanece completamente independiente de las clases/funciones circundantes.
El código debe tener pruebas unitarias.
El código hace que el lenguaje de programación parezca hecho para resolver el problema en particular.
Estos son los principios de Clean Code que debe conocer.
“El código sucio es difícil de entender, más complejo de lo que debería ser, no es fácil de probar y hace que otros desarrolladores se llenen de frustración. Si bien puede llevar más tiempo escribir un código limpio a corto plazo, está más que comprobado que escribir un código limpio ahorrará a todos tiempo y esfuerzo, esto significa a la larga menos dinero”.
Es importante también aclarar que el código limpio no se basa en reglas específicas del idioma. En su lugar, se basa en principios independientes del lenguaje acordados por la comunidad de desarrolladores.
Principios universales a seguir:
Siga las reglas estándar: los experimentos siempre terminan en desastre.
Evita la duplicidad en el código (DRY principio o No te repitas).
Debemos aplicar la regla de los Boy Scouts en nuestra profesión: «Intenten dejar este mundo mejor de como lo encontraron». (lectura complementaria de Robert Baden)
Siga SOLID para escribir clases limpias y API bien organizadas.
S = Principio de responsabilidad única: una clase solo debe tener un propósito.
O = Principio abierto-cerrado: una clase debe estar abierta para la extensión, pero cerrada para la modificación.
L = Principio de sustitución de Liskov: la abstracción debe poder satisfacer todas las necesidades de la clase infantil.
I = Principio de segregación de interfaz: una interfaz pequeña es mejor que una grande.
D = Principio de inversión de dependencia: una clase debe depender de la abstracción, no de la implementación.
En este artículo anterior, Dario realiza un recorrido más extenso sobre los 5 principios que todo programador debe conocer para exponer los principios SOLID.
- No lo vas a necesitar. “You aren’t gonna need it” Un desarrollador no debe agregar funcionalidad a menos que lo considere necesario. YAGNI
Hablemos un poco de las reglas para los nombres:
Use nombres que se puedan pronunciar bien.
Elige nombres descriptivos y claros.
Utilice nombres buscables.
Haz que sea fácil recordarlos.
Usa nombres de acuerdo al contexto.
Use nombres que sean consistentes entre sí. Por ejemplo, es confuso tener “buscar” y “obtener” como métodos equivalentes en distintas clases.
Usar el mismo idioma en los nombres de las variables, funciones: inglés, francés, etc. En nuestro caso, los cecropianos preferimos usar el inglés porque es un estándar.
Evite las codificaciones y no añada prefijos ni escriba información.
Como hacer los comentarios:
El código es la mejor documentación.
Los comentarios son difíciles de mantener y no dicen la verdad sobre el código, así que trate de evitarlo. Casi siempre están desactualizados.
No seas redundante. Evite los comentarios innecesarios.
Úselos solo como una aclaración del código.
…Y que sobre las reglas de diseño:
Declare las variables de instancia en la parte superior de la clase.
Declare las variables locales lo más cerca posible de su uso.
Las constantes deben declararse en la parte superior de la clase o en una clase de solo constantes.
Siga la Ley de Deméter: una clase debe conocer solo sus dependencias directas.
Codificar es como escribir; tratar de expresar el propósito del programador y el código.
Utilice inyección de dependencia (DIP).
Si usa bibliotecas de terceros, envuélvalas, de modo que si cambian, solo la implementación de su envoltorio debe cambiar.
Es una buena idea separar los conceptos verticalmente.
Coloque los métodos en una dirección de arriba hacia abajo.
Legibilidad del código:
Evite archivos demasiado largos.
Los buenos archivos tienen un encabezado, coloque las funciones principales primero y los utilitarios o detalles después.
Aunque ahora tenemos pantallas grandes y con alta resolución, evita que las líneas se hagan demasiado largas (80 a 140 caracteres es perfecto, en mi caso 120). Te acostumbrarás a ser más conciso y tu código será más legible.
Sea consistente, mantenga las mismas reglas en todo su equipo.
Clases:
- Las clases deben ser pequeñas.
- Las clases deben tener una sola responsabilidad y una sola razón para cambiar (SRP).
Mantenga privados los métodos de utilidad y las variables, excepto en algunos casos para realizar pruebas.
Utilice correctamente los niveles de paquete: público, protegido o paquete.
Objetos y Estructuras de Datos:
Ocultar estructura interna.
Si puede, llame solo a los métodos de su clase, de los objetos que ha creado, y evite llamar a los métodos accesibles a través de estos objetos (Ley de Deméter).
Mejorar el desacoplamiento de objetos.
Las variables deben ser privadas y deben ser manipuladas por getters y setters, pero recuerde que no es necesario agregar getters/setters a cada variable para exponerlas como públicas.
La clase base no debe saber nada acerca de sus derivados.
Los objetos exponen el comportamiento y ocultan datos. Por el contrario, las estructuras de datos exponen datos y carecen de comportamiento (significativo).
Manejo de excepciones:
Utilizar excepciones para lanzar errores hace que el código sea más limpio que verificar los valores de estado en todo el código.
Proporcione suficiente significado para determinar la causa y la ubicación de un error.
Envuelva las API de bibliotecas de terceros para reasignar sus excepciones según sea necesario.
El manejo de la concurrencia:
La concurrencia, aunque puede mejorar el rendimiento del programa, es difícil, así que utilícela sabiamente y sólo cuando sea necesario.
Mantenga el control de concurrencia separado de otro código.
Conocer conceptos básicos y modelos básicos de programación como exclusión mutua, inanición o puntos muertos.
Crea secciones cerradas pequeñas.
Pruebas Unitarias:
Rápidas: Las pruebas unitarias deben ser rápidas y ejecutarse en poco tiempo.
Independiente: las pruebas no deben depender unas de otras.
Repetible: las pruebas deben ser reproducibles en cualquier entorno.
Si tiene el código cubierto por pruebas, no tendrá miedo de modificarlo y romperlo.
TDD: construya su software utilizando pruebas que guíen su desarrollo.
No dejes de estar atento a nuestras próximas publicaciones, tendremos un artículo más desarrollado sobre pruebas unitarias.
Vayamos haciendo conclusiones, en este resumen, dejaré un poco “más de lo mismo” pero es que vale la pena repetirlo, y estas son algunas de las cosas que me han ayudado en mi carrera. Estoy seguro de que podrás leerlas muy rápido, pero aplicarlas, es otra cosa, bien puede llevarte toda la vida. Llevo más de 20 años desarrollando aplicaciones, y todavía, a veces, tengo que parar y pensar en ellas como parte de las partes esenciales de esta profesión.
Toma el código y divide grandes piezas de código en pequeñas funciones.
Si al salir del trabajo no has solucionado el problema. Apaga el ordenador y déjalo para el día siguiente. No pienses más en el problema.
Principio YAGNI: “You aren’t gonna need it” no codifiques más de lo que te han pedido. No anticipes el futuro, simplemente crea algo que funcione lo antes posible. Codifique solo las partes necesarias para resolver el problema actual.
No necesitas saberlo todo, ni todos los frameworks existentes. Lo más importante es tener una buena base. Conoce el lenguaje en profundidad antes de empezar con un Framework.
KISS: “Mantenlo simple, estúpido” o “mantenlo estúpidamente simple” es un principio de diseño que establece que la mayoría de los sistemas funcionan mejor si se mantienen simples en lugar de complicados. Y si bien esto es lógico, a veces es difícil de lograr.
No lo pienses demasiado.
Si está demasiado tiempo con un problema o un error, aléjese y vuelva a él más tarde. A menudo, las mejores soluciones a los problemas se me ocurren en el camino de mi oficina al baño. También es recomendable dar un paseo cuando estás enojado con un cliente o con un compañero de trabajo, especialmente si quieres conservar tu trabajo.
Primero resuelve el problema y luego escribe el código. No empiece a codificar sin saber qué hacer.
Si quieres aprender algo, práctica. Haz ejemplos y haz que funcionen porque leer sobre algo no es suficiente.
Nunca te rindas, al final, de una forma u otra lo resolverás. Hay días malos, pero pasarán.
Descanso, descanso y descanso. La mejor manera de resolver un problema es tener una mente tranquila.
Aprende a usar patrones de diseño de Software. Los patrones de diseño son soluciones a problemas comunes en el diseño de software. Cada patrón es como un modelo que se puede personalizar para resolver un problema de diseño común en su código. (No reinvente la rueda)
Pide ayuda cuando la necesites. No pierdas el tiempo.
La práctica hace la perfección.
Aprende a Reutilizar componentes.
Siga los estándares documentados.
Los usuarios no son personas técnicas. Piénsalo cuando desarrolles tu interfaz de usuario.
Utilice siempre un sistema de control de código fuente como Github o bitbucket y realiza commits de git pequeños y frecuentes.
Y por último, ten paciencia y amor por lo que haces.
Estoy seguro de que si estás iniciando como desarrollador, estas líneas te servirán de mucho en tu camino, también, si eres un desarrollador experimentado seguro te han servido para refrescar algunas recomendaciones que todos conocemos, pero a veces olvidamos, toma las que te interesen y pregunta si necesitas el resto.
