Mejora la calidad
de tu código

Cada pieza de conocimiento debe tener una única representación autorizada en el código.

Reconoce la duplicación oculta y elige la abstracción correcta para eliminarla.

Cómo la filosofía 5S de manufactura de Toyota se traduce en artesanía de software profesional.

Entiende lo que hace un framework antes de usarlo — lee el código fuente, no solo la documentación.

Aplica las heurísticas F1–F4 para mantener las funciones mínimas, enfocadas y sin efectos secundarios.

Mantén la política de alto nivel separada del detalle de bajo nivel, y asegura que las clases base nunca dependan de las derivadas.

Aplica el mismo patrón en todas partes, evita el desorden conceptual y nunca acoplas preocupaciones no relacionadas.

Sigue los estándares de codificación del equipo de forma religiosa y reemplaza cada literal mágico con una constante nombrada.

Construye sistemas que compilen en un paso, ejecuten todas las pruebas en un paso, y nunca mientan a través de advertencias suprimidas.

Usa variables explicativas, nombres precisos y un profundo entendimiento del algoritmo para que el código hable por sí mismo.

Un método que pasa la mayor parte de su tiempo leyendo los datos de otra clase pertenece a esa clase.

Haz explícitas todas las dependencias y reemplaza las cadenas if/switch con despacho polimórfico.

Elimina información excesiva, código muerto y distancia vertical para que cada archivo sea fácil de escanear.

Pon cada función en la clase más interesada en ella, y mantén los métodos estáticos como utilidades verdaderamente sin estado.

Los argumentos selectores booleanos y de enumeración oscurecen la intención — divídelos en funciones enfocadas y bien nombradas.

Un catálogo curado de malos olores de código y heurísticas de refactorización extraídas del capítulo 17 de Clean Code.

El código que intenta ser inteligente es código que falla en comunicar — la densidad y brevedad a costa de la claridad no son virtudes.

Que las pruebas pasen no equivale a entender — el código limpio exige que comprendas completamente por qué funciona el algoritmo antes de confirmarlo.

Nunca permitas que un módulo asuma silenciosamente un valor de otro — haz que cada dependencia sea explícita y declarada en el código.

Tres heurísticas enfocadas en Java: evita importaciones con comodines, nunca heredes constantes, y prefiere enumeraciones sobre constantes enteras.

Transforma código legado enredado de forma segura añadiendo pruebas primero y refactorizando en pequeños pasos.

Escribe nombres que revelen la intención, eviten la confusión y hagan el código buscable.

Aplica las heurísticas N1–N7 para escribir nombres precisos, sin ambigüedad y fáciles de buscar.

El código es la única fuente de verdad — los comentarios mienten a medida que el código evoluciona.

Los objetos ocultan datos detrás del comportamiento. Las estructuras exponen datos. Mezclar ambos crea híbridos que nadie quiere.

La calidad es una responsabilidad profesional — no algo que entregas cuando el tiempo lo permite, sino el mínimo no negociable de tu oficio.

Una función pura siempre devuelve el mismo resultado para la misma entrada y no cambia nada fuera de ella misma.

Usa las heurísticas de Responsabilidad Única para detectar y dividir clases y módulos sobrecargados.

Aplica el refinamiento sucesivo a la clase SerialDate — prueba, renombra, extrae y simplifica.

Un caso de estudio para leer código legado de forma crítica — encuentra los malos olores antes de tocar nada.

Las cuatro reglas de Kent Beck, en orden de prioridad, para un diseño siempre listo para evolucionar.

Las funciones deben hacer una sola cosa, hacerla bien y solo eso.

El formato del código es un acto de comunicación — estructura los archivos para que cualquier desarrollador pueda navegar en segundos.

Comienza con código que funciona y luego refactoriza de forma iterativa — nunca escribas código limpio en un solo paso.

El código de terceros pertenece al borde — envuélvelo para que nunca contamine tu lógica de negocio.

Domina el micro-ciclo rojo-verde-refactorizar: escribe primero una prueba que falle, luego solo el código necesario para pasarla.

Aplica las heurísticas T1–T9 para escribir suites de pruebas completas, significativas y mantenibles.

Cabe más objetos en RAM compartiendo estado común — separa datos intrínsecos (compartidos) de extrínsecos (únicos) para evitar duplicar objetos pesados.

Recorre elementos de cualquier colección sin exponer su estructura interna — el cliente nunca necesita saber si es una lista, árbol o grafo.

Restringe la comunicación directa entre objetos — fuerza la colaboración a través de un mediador para reducir dependencias caóticas muchos-a-muchos.

Captura y restaura el estado interno de un objeto sin violar la encapsulación — implementa Deshacer almacenando instantáneas de estados pasados.

Permite que los objetos se suscriban a eventos y sean notificados automáticamente — desacopla los productores de eventos de los consumidores sin que ninguno sepa del otro.

Copia objetos existentes sin depender de sus clases — clona configuraciones complejas en lugar de reconstruirlas desde cero.

Proporciona un sustituto que controla el acceso a otro objeto — úsalo para carga perezosa, control de acceso, registro o caché sin cambiar el objeto real.

Abstrae el acceso a datos detrás de una interfaz para que la lógica de negocio nunca sepa si los datos vienen de una base de datos, caché o API — y las pruebas se convierten en un simple cambio.

Asegura que una clase tenga solo una instancia y proporciona un punto de acceso global — pero el abuso crea estado global oculto y dificulta las pruebas.

Permite que un objeto altere su comportamiento cuando su estado interno cambia — reemplaza los condicionales de estado con objetos de estado polimórficos.

Define una familia de algoritmos, encapsula cada uno en su propia clase y hazlos intercambiables en tiempo de ejecución — elimina los condicionales seleccionando el comportamiento mediante composición.

Define el esqueleto de un algoritmo en una superclase, pero permite a las subclases sobrescribir pasos específicos sin cambiar su estructura.

Añade nuevas operaciones a una jerarquía de objetos sin modificar las clases — el visitor porta la operación, los elementos simplemente la aceptan.

Las dependencias del código fuente solo pueden apuntar hacia adentro — nada en un círculo interior puede saber nada de un círculo exterior, manteniendo el núcleo de negocio estable y reutilizable.

La base de datos, la capa web y los frameworks son mecanismos de entrega — un buen arquitecto postpone estas decisiones y mantiene las reglas de negocio independientes para evitar un matrimonio tecnológico costoso.

Atar la lógica de negocio a dispositivos de E/S específicos es un error costoso — la arquitectura debe ser agnóstica a si los datos vienen de tarjetas, terminales, archivos o APIs.

Las dependencias del código fuente deben apuntar solo a abstracciones — las Fábricas Abstractas crean la frontera arquitectónica entre el código concreto volátil y la política estable.

Con interfaces, los arquitectos hacen que las dependencias del código apunten contra el flujo de control, dando control absoluto sobre el acoplamiento.

La arquitectura es importante pero rara vez urgente. Los desarrolladores deben defender la buena estructura frente a la presión del negocio.

Las Entidades contienen reglas de negocio críticas que existen en toda la empresa; los Casos de Uso orquestan flujos específicos de la aplicación y están aislados de los cambios de UI y base de datos.

La programación funcional disciplina la asignación. La inmutabilidad elimina condiciones de carrera, deadlocks y problemas de actualización concurrente.

El diseño y la arquitectura son lo mismo: su verdadera medida es el esfuerzo necesario para satisfacer al cliente minimizando el costo a largo plazo.

Separa el comportamiento difícil de probar del fácil de probar — el Presentador prepara toda la lógica en un ViewModel testeable; la Vista es un humble object que solo muestra lo que recibe.

La mejor arquitectura fracasa sin un uso disciplinado de los modificadores de acceso — el compilador es tu aliado más fuerte para hacer cumplir las reglas de Clean Architecture en todo el equipo.

Los Adaptadores de Interfaz convierten datos entre el formato que entienden los casos de uso y el que necesitan los sistemas externos — los límites siempre se cruzan con DTOs simples, nunca con entidades crudas o filas de BD.

No dependas de cosas que no usas — las interfaces gordas fuerzan recompilaciones innecesarias y acoplamiento a fallos en código no relacionado.

Un buen arquitecto maximiza el número de decisiones aún no tomadas — separando la política de los detalles para que las elecciones de base de datos y framework puedan postponerse hasta saber más.

Separa lo que cambia a diferentes ritmos — UI, reglas de negocio de aplicación, reglas de dominio y base de datos cambian por razones distintas y deben ser capas horizontales.

Los subtipos deben ser sustituibles por sus tipos base — las violaciones del LSP fuerzan lógica costosa de casos especiales en el diseño.

Main es el componente más sucio y de más bajo nivel — el punto de entrada que conecta todas las dependencias y entrega el control a la arquitectura limpia que está sobre él.

Los componentes deben equilibrar Abstracción (A) e Inestabilidad (I) — la Zona de Dolor (estable+concreto) y la Zona de Inutilidad (abstracto+inestable) son antipatrones a evitar.

Los artefactos de software deben estar abiertos para extensión pero cerrados para modificación — añadir nuevo comportamiento debe añadir código, no cambiarlo.

La POO no inventó la encapsulación — C tenía encapsulación perfecta antes de que C++ y Java la debilitaran con los archivos de cabecera.

Agrupa toda la responsabilidad de un límite de funcionalidad limpio en un paquete — la persistencia interna y la lógica permanecen privadas, el compilador hace cumplir lo que es visible para el resto del sistema.

Agrupa el código por funcionalidad de dominio — los paquetes de nivel superior revelan el negocio, cada funcionalidad está co-ubicada y la búsqueda mejora drásticamente a medida que el sistema crece.

La organización de código más simple agrupa por capa técnica (web/servicio/repositorio) — fácil de comenzar pero oculta la intención del negocio y permite atajos peligrosos entre capas.

Los límites arquitectónicos completos son costosos — los límites parciales usando patrones Strategy o Facade preservan puntos de separación futura sin el costo total inicial.

El antipatrón periférico ocurre cuando el código de infraestructura habla directamente con otro código de infraestructura, saltándose el dominio — como el anillo de París, el tráfico fluye alrededor de la ciudad en lugar de a través de ella.

El nivel es la distancia a las entradas y salidas — cuanto más lejos de la E/S, mayor el nivel. Las dependencias del código fuente siempre deben apuntar hacia las políticas de más alto nivel y más estables.

El polimorfismo permite tratar dependencias externas como plugins intercambiables, haciendo que la lógica central sea independiente del dispositivo.

El interior es el dominio; el exterior es la infraestructura — el exterior depende del interior, los puertos hablan el lenguaje del dominio y los adaptadores traducen entre el dominio y los sistemas externos.

Las pruebas no demuestran corrección, demuestran ausencia de incorrecciones conocidas. La buena arquitectura produce módulos fácilmente falsificables.

Los tres paradigmas imponen disciplina eliminando capacidades, no añadiéndolas.

REP agrupa las clases que se liberan juntas; CCP agrupa las que cambian juntas por la misma razón — ambas reflejan el SRP a escala de componente.

Un componente debe ser tan abstracto como estable — los componentes más estables deben ser interfaces puras para poder extenderse sin modificarse.

La estructura de carpetas debe revelar qué hace el sistema, no qué framework usa — un sistema de salud grita 'Salud', no 'Rails'.

Depende en la dirección de la estabilidad — un componente volátil nunca debe ser dependido por uno estable, o esa estabilidad queda comprometida permanentemente.

Los servicios no definen la arquitectura — un servicio con estructura interna pobre es solo una llamada de función costosa. Los límites arquitectónicos reales pueden existir dentro de un monolito o entre servicios.

Un módulo debe ser responsable ante un solo actor, evitando que los cambios de un departamento rompan accidentalmente otro.

Dijkstra demostró que el goto sin restricciones es perjudicial. La secuencia, selección e iteración son suficientes para módulos correctos y descomponibles.

Los tests son el círculo arquitectónico más externo — los tests frágiles acoplados a detalles de implementación hacen el sistema rígido; una API de Test desacopla la estructura de tests de la estructura de la aplicación.

El software tiene valor por su comportamiento y su estructura. Un sistema rígido dejará de funcionar cuando los requisitos cambien.

Los casos de uso son cortes verticales que atraviesan todas las capas — desacoplarlos permite que cada uno evolucione independientemente sin que los cambios de un caso de uso colisionen con los de otro.