Comencemos con ¿Que es clean code? Clean code son los principios y buenas practicas para que nos ayudan a escribir códigio, mantenible, legible y comprencible. El concepto de Clean Code se describio en el libro del mismo nombre escrito por Robert C. Martin y busca como objetivo que el código que escribamos no solo funcione, sino que sea mantenible.
Cambio de mentalidad
Los que llevamos ya algunos años en el negocio de tirar lineas de código podemos llegar a car en la trampa de pensar que “un mal programa que funciona es mejor que nada”. Sin embargo, un código desordenado genera deuda técnica que, tarde o temprano, paralizará el desarrollo.
Adoptar una mentalidad de “artesano del software” es crucial. Si queremos escribir código de calidad. Todos hemos querido culpabilizar a managers, PM, directores de no darnos el tiempo suficiente para crear código de calidad porque “urge” entregar el sotware funcional pero miralo desde este otro punto de vista ¿Un doctor entregaria un mal dianostigo porque el paciente quiere que la consulta sea breve?
Clean Code nos enseña que la mejor manera de entender la calidad de software es darnos cuenta que escribir código de calidad no es una etapa que se pueda dejar para despues (despues es igual que nunca).La calidad es el resultado de un millón de acciones cuidadosas, no de un método mágico.
El arte de nombrar
Los nombres son el primer indicio de la calidad del código. Por lo tanto Clean Code nos dice que un buen nombre ahorra horas de depuración y análisis. “El nombre correcto en el lugar correcto puede hacer que el código sea casi autoexplicativo”. Elegir buenos nombres toma tiempo, pero ese tiempo se recupera con creces en mantenimiento y colaboración.
- Usa nombres que revelen la intención: El nombre debe responder a las preguntas: ¿qué hace?, ¿por qué existe?
- Evita la desinformación: No llames accountList a una variable si no es una List. La precisión es clave.
- Haz distinciones con sentido:
- Usa nombres pronunciables y buscables:
- Coloca Constantes
- Sigue convenciones claras:
- No añadas contexto innecesario: Si estás en la aplicación “Gas Station Deluxe”, no es necesario prefijar cada clase con GSD. GSDAccount es redundante; Account es suficiente.
Funciones Pequeñas y Enfocadas
Las funciones son los verbos de nuestro lenguaje de programación. Si las clases son los sustantivos, las funciones son las acciones. La clave es que hagan una sola cosa, que la hagan bien y que no hagan nada más.
Reglas para Funciones de Calidad usando Clean Code
Para escribir funciones, legibles, reusables y mantenibles Clean Code nos da las siguientes pautas:
- Tamaño Reducido: Una función idealmente no debería superar las 20 líneas. Los bloques dentro de
if,else,while, etc., deberían tener una sola línea, que usualmente es una llamada a otra función. - Haz una sola cosa (Principio de Responsabilidad Única):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
// MALO: Mezcla niveles de abstracción public void processAndEmailReport() { // Nivel alto var data = fetchDataFromDatabase(); var report = generateReport(data); // Nivel bajo (detalle) Properties props = new Properties(); props.put("mail.smtp.host", "smtp.example.com"); Session session = Session.getInstance(props, null); // ... más código de configuración de email // Nivel alto sendEmail(session, report); } // BUENO: Niveles de abstracción consistentes public void processAndEmailReport() { var data = fetchDataFromDatabase(); var report = generateReport(data); emailReport(report); } private void emailReport(Report report) { // Todos los detalles de bajo nivel están aquí var emailService = new EmailService(); emailService.send(report); } |
Argumentos de funcion
- Tres o más argumentos (Triádica): Evítalas. Si necesitas más de dos argumentos, considera agruparlos en un objeto.
- Cero argumentos (Niládica): Es la situación ideal.
- Un argumento (Monádica): Muy común. Puede ser para preguntar sobre el argumento (
fileExists("report.txt")) o para operarlo (InputStream fileOpen("report.txt")). - Dos argumentos (Diádica): A veces necesario (
Point(0, 0)). Úsalas con precaución.
|
1 2 3 4 5 6 7 |
Circle makeCircle(double x, double y, double radius); // BUENO: Usar un objeto argumento class Point { double x, y; } Circle makeCircle(Point center, double radius); |
- Evita los argumentos booleanos: Pasar un
booleana una función es una clara señal de que la función hace más de una cosa: una paratruey otra parafalse. En su lugar, crea dos funciones separadas. - Sin Efectos Secundarios: Tu función debe hacer lo que su nombre promete, y nada más. Por Ejemplo una función
checkPassword()no debería iniciar una sesión de usuario. - Comandos o Consultas, no ambos: Una función debe o bien hacer algo (cambiar el estado de un objeto) o responder algo (devolver un valor), pero no ambas cosas.
El Problema de switch
Las sentencias switch son problemáticas porque por naturaleza hacen N cosas. Por lo tanto la ideologia de Clean Code no le gusta este tipo de estructura la regla general es que se pueden tolerar si:
- Aparecen una sola vez.
- Se usan para crear objetos polimórficos.
- Se ocultan detrás de una clase (usando un patrón de Factoría) para que el resto del sistema no sepa de su existencia.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
// MALO: El switch se repetirá en cada operación (calculatePay, isPayDay, etc.) public Money calculatePay(Employee e) { switch (e.type) { case COMMISSIONED: return calculateCommissionedPay(e); case SALARIED: return calculateSalariedPay(e); // ... y así sucesivamente } } // BUENO: Se usa polimorfismo y una factoría para ocultar el switch public abstract class Employee { public abstract boolean isPayDay(); public abstract Money calculatePay(); public abstract void deliverPay(Money pay); } public interface EmployeeFactory { public Employee makeEmployee(EmployeeRecord r); } public class EmployeeFactoryImpl implements EmployeeFactory { public Employee makeEmployee(EmployeeRecord r) { switch (r.type) { case COMMISSIONED: return new CommissionedEmployee(r); case SALARIED: return new SalariedEmployee(r); default: throw new InvalidEmployeeType(r.type); } } } |
Formato del Código Legible
Un formato consistente es crucial para la legibilidad. La mayoría de los equipos utilizan herramientas automatizadas (linters, formatters) para mantener la consistencia.
Usa espacios horizontales para agrupar y separar elementos, como entre operadores (a + b).
Verticalidad:
- Los conceptos relacionados deben estar cerca verticalmente.
- Las variables deben declararse lo más cerca posible de su uso.
- Las funciones que se llaman entre sí deben estar próximas, creando un flujo de lectura descendente.
Horizontalidad:
- Mantén las líneas cortas (80-120 caracteres es una buena guía).
- Usa espacios horizontales para agrupar y separar elementos, como entre operadores (
a + b).
Objetos, Estructuras de Datos y Clean code
Abstracción de datos: No expongas los detalles de implementación. En lugar de generar getters y setters para cada variable privada (lo que las convierte en públicas de facto), crea métodos que expresen el comportamiento en términos abstractos.
|
1 2 3 4 5 6 7 8 9 10 |
// MALO: Expone la implementación interna public class Vehicle { public double getFuelLevel(); // Devuelve galones public double getTankCapacity(); // Devuelve galones } // BUENO: Abstrae el detalle public class Vehicle { public double getFuelPercentage(); } |
Ley de Demeter (No hables con extraños): Un método de un objeto solo debe llamar a métodos de:
- Un objeto contenido en una variable de instancia.
- El propio objeto.
- Un objeto pasado como argumento.
- Un objeto que crea.
Evita las “cadenas de trenes” de llamadas.
|
1 2 3 4 5 6 7 |
// MALO: Viola la Ley de Demeter final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath(); // MEJOR: Aunque más verboso, es más mantenible Options opts = ctxt.getOptions(); File scratchDir = opts.getScratchDir(); final String outputDir = scratchDir.getAbsolutePath(); |
Clean Code y el manejo de Errores
Un código limpio anticipa y maneja los errores de manera elegante. Además, un código sin pruebas no es un código limpio, ya que no se puede refactorizar con seguridad.
Errores
- Usa Excepciones en lugar de Códigos de Error: Devolver códigos de error (
-1,null) obliga al llamador a verificar el resultado inmediatamente, ensuciando la lógica. Las excepciones desacoplan la detección del error de su manejo. - Proporciona Contexto en las Excepciones: Una buena excepción debe indicar qué falló, por qué y dónde.
- No devuelvas
null: Devolvernullcrea trabajo extra para el cliente. En su lugar, lanza una excepción o devuelve un Objeto de Caso Especial (por ejemplo, una lista vacía en lugar de unnullsi se busca algo y no se encuentra:Collections.emptyList()). - No pases
null: Evita pasarnullcomo argumento a menos que la API lo requiera explícitamente.
Pruebas estilo Clean Code (TDD)
El Desarrollo Guiado por Pruebas (TDD) no es solo una técnica de pruebas, sino una disciplina de diseño.
Las Tres Leyes del TDD:
- No escribas código de producción hasta que tengas una prueba que falle.
- Escribe solo el código de prueba suficiente para que falle (o no compile).
- Escribe solo el código de producción suficiente para que la prueba que falla pase.
Este ciclo (Rojo-Verde-Refactor) asegura que todo el código esté cubierto por pruebas y promueve un diseño simple.
Principios de las Pruebas Limpias (FIRST):
- Fast (Rápidas): Las pruebas deben ejecutarse rápidamente.
- Independent (Independientes): No deben depender unas de otras.
- Repeatable (Repetibles): Deben funcionar en cualquier entorno.
- Self-Validating (Auto-validadas): La prueba debe devolver
trueofalse. No requiere inspección manual. - Timely (Oportunas): Se escriben justo antes del código de producción que prueban.
Estructura de una Prueba:
Usa el patrón Given-When-Then (o Generar-Operar-Comprobar) para estructurar tus pruebas y hacerlas más legibles.
|
1 2 3 4 5 6 7 8 9 10 11 |
@Test public void testIncrementCounter() { // Given (Generar) Counter counter = new Counter(5); // When (Operar) counter.increment(); // Then (Comprobar) assertEquals(6, counter.getValue()); } |
Como escribir clases legibles con Clean Code
Finalmente, nos enfocamos en cómo organizar nuestro código en clases cohesivas y cómo manejar los desafíos de la programación concurrente.
Clases Limpias
Pequeñas: Al igual que las funciones, las clases deben ser pequeñas.
Principio de Responsabilidad Única (SRP): Una clase debe tener una, y solo una, razón para cambiar. Si una clase maneja la lógica de negocio, la persistencia en base de datos y la serialización a JSON, está violando el SRP.
Cohesión Alta: Las clases deben tener un número reducido de variables de instancia. Los métodos de una clase deben operar sobre esas variables. Si una clase tiene varios grupos de métodos que operan en diferentes subconjuntos de variables, es una señal de que la clase debería dividirse.
Programación Concurrente
La concurrencia es compleja y una fuente común de errores difíciles de reproducir.
Principios para una Concurrencia Segura:
- Evita el bloqueo (
deadlock): Ocurre cuando dos o más procesos se esperan mutuamente para liberar un recurso. - Separa el código concurrente: Mantén el código que maneja la concurrencia separado y tan pequeño como sea posible.
- Limita el acceso a datos compartidos: Usa
synchronizedcon moderación y solo en secciones críticas muy pequeñas. Encapsula los datos compartidos y no los expongas. - Usa copias de los datos: Una forma de evitar problemas de concurrencia es trabajar con copias inmutables de los datos.
- Conoce tus modelos de ejecución: Entiende los problemas clásicos como Productor-Consumidor o Lectores-Escritores y sus soluciones.
Comentarios en el código VS Clean Code
El código debe hablar por sí mismo. Los comentarios son a menudo una excusa para un código poco claro. El formato y la estructura del código también son vitales para la legibilidad.
El último recurso
- Historial de cambios: Para eso está
git log. - Los comentarios mienten: El código evoluciona, pero los comentarios rara vez se actualizan. La única verdad está en el código.
- Un comentario es un fracaso: Expresan nuestra incapacidad para expresarnos con claridad en el código. Antes de escribir un comentario, intenta refactorizar el código para que sea autoexplicativo.
Comentarios válidos:
- TODO: Son útiles para marcar tareas pendientes, pero deben revisarse y eliminarse regularmente.
- Aclaración de algoritmos complejos: A veces, un comentario que explica la intención detrás de una expresión regular compleja o un algoritmo particular puede ser útil.
Qué NO comentar:
- Código comentado: ¡Bórralo! El control de versiones existe para eso.
- Comentarios redundantes: No comentes algo que el código ya dice.
Conclusión
Escribir código limpio es una disciplina que requiere práctica y atención constante. No se trata de seguir ciegamente un conjunto de reglas, sino de desarrollar un sentido de la “limpieza” y el “orden” en el código.
Recuerda siempre la regla del Boy Scout: “Deja siempre el campamento más limpio de como lo encontraste”. Si cada desarrollador limpia un poco el código cada vez que lo toca (renombra una variable, divide una función larga), el sistema mejorará continuamente en lugar de degradarse.
La maestría se construye con conocimiento y trabajo. ¡Ahora es tu turno de aplicar estos principios!
