Glosario
Los términos del curso con una definición breve, ordenados por parte del curso. Siguen la regla de la guía de estilo:
- Un término técnico se deja en inglés cuando su traducción suena forzada, como lo dicen los equipos de desarrollo en el Perú y como aparece en la documentación, en GitHub y en los mensajes de error (pull request, backlog, pipeline, rollback). Esas entradas están en inglés y se explican en español.
- Los que de verdad se usan en español (requisito, prueba, revisión de código, despliegue) van en español, con el término en inglés entre paréntesis.
Las definiciones son las de los apuntes de cada semana, que citan sus fuentes. Cada término está en la parte donde el curso lo presenta o lo trata a fondo.
Herramientas
| Término | Definición |
|---|---|
| Kallpa | La aplicación de reservas de un complejo deportivo que escribimos para el curso, en TypeScript con Node.js. Es la base de los laboratorios. |
| Git | El sistema de control de versiones que usamos, con GitHub como remoto. |
| Node.js | El entorno que ejecuta el código del curso (versión 26): corre archivos .ts directamente porque quita los tipos al cargar, sin revisarlos. |
node:test |
El runner de pruebas que trae Node.js; se usa junto con node:assert/strict. |
| fast-check, StrykerJS | Las bibliotecas del curso para pruebas basadas en propiedades y pruebas de mutación, respectivamente. |
| GitHub Actions | El servicio de integración continua de GitHub: un workflow se dispara con eventos y tiene jobs que corren en runners; cada job tiene steps, que son comandos o actions. |
| Contenedor (container) | Un proceso con vista propia de archivos, red y procesos, que comparte el kernel. No es una máquina virtual. |
Parte 1 — Proceso y requisitos
| Término | Definición |
|---|---|
| Ingeniería de software (software engineering) | Programación integrada en el tiempo: producir código y mantenerlo útil mientras haga falta, en equipo. Se diferencia de programar por el tiempo, la escala y las decisiones con costos. |
| Ley de Hyrum (Hyrum’s law) | Con suficientes usuarios de una API, no importa lo que se prometa en el contrato: todo comportamiento observable del sistema va a ser usado por alguien. |
| Beyoncé Rule | “If you liked it, you should have put a CI test on it”: si algo importaba, había que ponerle una prueba en integración continua. Las pruebas que no corren ahí no cuentan. |
| commit | Una foto del proyecto con sus padres y un hash que la identifica. Se dice hacer commit, con un mensaje en imperativo. |
| branch (rama) | Un nombre que apunta a un commit. En el curso: una rama por cambio. |
| merge | Juntar el trabajo de dos ramas. Se dice hacer merge; un commit de merge tiene dos padres. |
| Conflicto de merge (merge conflict) | Aparece cuando dos ramas cambian la misma zona de un archivo desde la misma base. Se resuelve decidiendo qué tiene que decir el código, no eligiendo un lado a ciegas. |
| pull request (PR) | El pedido de integrar una rama, con su descripción y su revisión: el paquete que se revisa en GitHub antes del merge. |
| trunk-based development | Trabajar con cambios chicos a los que se les hace merge seguido con la rama principal, con pruebas e integración continua que la mantienen funcionando. Se opone a las ramas de larga vida. |
| Proceso de desarrollo (development process) | El acuerdo de un equipo sobre quién decide qué se construye, en qué orden, cada cuánto se entrega y cómo se corrige el rumbo. |
| Cascada (waterfall) | Proceso por fases con documentos entre ellas. Sirve cuando los requisitos son fijos y corregir tarde es aceptable; su riesgo es que el cliente ve el producto al final. |
| Scrum | Marco de trabajo basado en el empirismo, con tres responsabilidades (product owner, Scrum master, developers), cinco eventos y tres artefactos con sus compromisos. Story points, velocity y planning poker no son parte de la Scrum Guide. |
| sprint | Evento de duración fija, de un mes o menos, que contiene a los demás eventos de Scrum y produce un incremento. |
| product owner | La persona, no un comité, responsable de ordenar el product backlog para maximizar el valor del producto. |
| Scrum master | Quien responde por que Scrum se aplique y le sirva al equipo. |
| backlog, product backlog | Lista ordenada de lo que hace falta en el producto. El sprint backlog es la parte elegida para un sprint, con el plan para hacerla. |
| Definition of Done | La descripción formal del estado que tiene que tener el incremento para cumplir las medidas de calidad. Un ítem que no la cumple al final del sprint vuelve al backlog: no existe “terminado al 90 %”. |
| daily | Reunión de hasta 15 minutos, de los developers, para inspeccionar el avance hacia el sprint goal y ajustar el plan del día. |
| Kanban | Método que optimiza el flujo: visualizar el trabajo, controlar el WIP y mejorar. Sus métricas mínimas son WIP, throughput, work item age y cycle time. |
| WIP (work in progress), ley de Little | El WIP son los ítems empezados y no terminados; limitarlo crea un sistema pull. Por la ley de Little, en promedio y en un sistema estable, WIP = throughput × cycle time. |
| story point | Estimación relativa del esfuerzo hasta la Definition of Done (trabajo, complejidad, incertidumbre). No se convierte en horas. |
| velocity | La suma de los puntos de los ítems terminados en un sprint. Es una medición hecha después, sirve para planificar al mismo equipo y no se compara entre equipos. |
| Ley de Goodhart (Goodhart’s law) | Cuando una medida se convierte en meta, deja de ser una buena medida. Le pasa a la velocity y a la cobertura. |
| Requisito, regla del negocio (requirement, business rule) | Un requisito es una condición, escrita, que el sistema tiene que cumplir para que el cliente resuelva su problema. La regla del negocio es del cliente; el requisito, lo que el sistema hace para cumplirla; la decisión de diseño, del equipo. |
| Requisito funcional, no funcional (functional, non-functional requirement) | El funcional dice qué hace el sistema; el no funcional, cómo de bien lo hace, y necesita un número: qué, dónde, cuánto y cómo se mide. |
| Elicitación (elicitation) | Descubrir los requisitos con varias técnicas, porque cada una ve cosas distintas: en una entrevista la gente cuenta lo que cree que hace; observando se ve lo que hace. |
| Historia de usuario (user story) | “Como…, quiero…, para…”: una promesa de conversación, con un rol concreto y un beneficio real. Tiene tres C: card, conversation y confirmation. |
| Criterio de aceptación (acceptance criterion) | Condición dado, cuando, entonces que dice cuándo una historia está cumplida. Es verificable si dos personas harían la misma prueba. |
| INVEST | Lista para revisar una historia antes de un sprint: independiente, negociable, valiosa, estimable, pequeña (small) y testeable (testable). |
| Priorización, MoSCoW (prioritization) | Decidir el orden del trabajo. MoSCoW clasifica respecto de una entrega (Must, Should, Could, Won’t) y se complementa con valor, costo y riesgo. |
Parte 2 — Diseño y arquitectura
| Término | Definición |
|---|---|
| Especificación (specification) | Lo que dice qué hace un módulo sin decir cómo. Es un acuerdo que permite cambiar el código de cada lado sin preguntar al otro. |
| Contrato (contract) | Lo que un sistema o una rutina promete. En la forma de Meyer tiene precondición, postcondición e invariante, y reparte las obligaciones entre quien llama y la rutina. |
| Precondición (precondition) | Lo que quien llama tiene que garantizar antes de la llamada. Si no se cumple, la rutina no promete nada, y el bug es de quien llama. |
| Postcondición (postcondition) | Lo que la rutina garantiza al terminar si se cumplió la precondición. Es completa si dice que lo devuelto es correcto y que está todo: si return [] la cumple, le falta algo. |
| Invariante (invariant) | Lo que vale siempre entre operaciones, antes y después de cada una. En las pruebas basadas en propiedades, además, lo que tiene que ser cierto de la salida sea cual sea la entrada. |
| design doc | Documento que se escribe antes de construir: contexto y alcance, objetivos y no objetivos, el diseño, las alternativas consideradas y los temas transversales. |
| Desarrollo guiado por especificaciones (spec-driven development) | Trabajar con un agente usando la especificación como entrada principal. Donde la especificación calla, el agente elige; lo verificable son las pruebas de aceptación escritas o revisadas por una persona. |
| Complejidad (complexity) | Lo que hace difícil entender y cambiar un sistema. Sus síntomas son la amplificación de cambios, la carga cognitiva y las incógnitas desconocidas; sus causas, las dependencias y la oscuridad. |
| Módulo profundo, superficial (deep, shallow module) | Un módulo es profundo si da mucha funcionalidad con una interfaz pequeña, y superficial si su interfaz es casi tan grande como lo que hace. |
| Interfaz (interface) | Lo que hay que saber de un módulo para usarlo. Tiene una parte formal (firmas, tipos) y una informal (lo que no se revisa solo, como el orden de las llamadas). |
| Ocultamiento de información (information hiding) | Principio de Parnas (1972): cada módulo esconde una decisión difícil o que probablemente cambie. |
| Concepto (concept) | Según Jackson, una unidad de funcionalidad que el usuario reconoce y que tiene sentido por sí sola. Tiene propósito, estado, acciones y principio operacional. |
| Acoplamiento, cohesión (coupling, cohesion) | El acoplamiento mide cuánto obliga un cambio en un módulo a cambiar otro; la cohesión, cuánto pertenecen juntas las partes de un módulo. Se busca bajo acoplamiento y alta cohesión. |
| refactoring (refactorización) | Cambiar la estructura del código sin cambiar su comportamiento, en pasos pequeños y con las pruebas en verde. |
| API | La interfaz con que un programa usa a otro. Es un contrato con quien no está en la sala: no se puede revisar ni actualizar a quien llama. |
| Diseño orientado a recursos (resource-oriented design) | Diseñar una API con sustantivos en las rutas y verbos estándar (GET, POST, PATCH, DELETE). Lo que no encaja, como cancelar, es un método propio. |
| Seguro (safe) | Un método HTTP es seguro si quien llama no pide un cambio de estado (RFC 9110). |
| Idempotente (idempotent) | Una operación lo es si el efecto buscado en el servidor de N solicitudes iguales es el mismo que el de una. Es sobre el efecto, no sobre la respuesta, que puede cambiar. PUT y DELETE lo son por definición; POST y PATCH no, salvo que se diseñen y documenten así. |
| Clave de idempotencia (idempotency key) | Identificador de la intención que manda quien llama: el servidor guarda la clave con la respuesta y, ante un reintento, la repite. Exige guardar la clave y el efecto en la misma transacción. |
| Patrón de diseño (design pattern) | Una solución con nombre, y con costos, para un problema de diseño que se repite. Antes de aplicarlo se pregunta qué cambio futuro abarata y qué tan probable es. |
| dependency injection | Pasar una dependencia desde afuera en lugar de crearla por dentro: por constructor, por setter o por parámetro. Es lo que da la costura para probar. |
| strategy, adapter, decorator, observer | Strategy elige un algoritmo intercambiable, a menudo con solo una función. Adapter traduce entre dos interfaces. Decorator envuelve a un objeto con otro de la misma interfaz, y el orden importa. Observer avisa a quienes se suscribieron, y desacopla el código, no las fallas. |
| repository | Patrón que esconde cómo se guardan los datos: quien lo usa ve una colección de objetos del dominio. |
| middleware | La idea de decorator aplicada a los handlers de HTTP: una función que envuelve al handler para agregarle algo. |
| Arquitectura (architecture) | Las decisiones de un sistema que son caras de cambiar: cómo se divide, cómo se comunican las partes, dónde viven los datos y cómo se despliega. |
| Arquitectura hexagonal (hexagonal architecture) | El núcleo define puertos en sus propios términos, los adaptadores conectan la tecnología y las dependencias apuntan hacia el núcleo. |
| Monolito, microservicios (monolith, microservices) | Un monolito se despliega entero y da transacciones y llamadas simples; si sus módulos tienen fronteras que se hacen cumplir, es un monolito modular. Los microservicios dan despliegues y escalado independientes a cambio de fallas parciales, consistencia eventual y mucha más operación. |
| Atributo de calidad (quality attribute) | Qué tan bien hace el sistema lo que hace. Se escribe como un escenario medible: estímulo, entorno, respuesta y medida. |
| ADR (architecture decision record) | Documento corto por decisión, con estado, contexto, decisión, alternativas y consecuencias, también las malas. Vive en el repositorio y, si la decisión cambia, se reemplaza. |
| C4 | Modelo para dibujar un sistema en cuatro niveles: contexto, contenedores, componentes y código. Su contenedor es algo que debe correr o existir para que el sistema funcione, no un contenedor de Docker. |
Parte 3 — Calidad
| Término | Definición |
|---|---|
| Prueba unitaria, de integración, de punta a punta (unit, integration, end-to-end test) | Las tres escalas de alcance: cuánto código ejercita una prueba. La pirámide de pruebas sugiere muchas unitarias, menos de integración y pocas de punta a punta. |
| Prueba frágil (brittle test) | La que falla ante un cambio de código que no introdujo ningún error real. |
| flaky test (prueba flaky) | La que a veces pasa y a veces falla sin que nada haya cambiado. Enseña al equipo a ignorar el rojo. |
| Oráculo (oracle) | El mecanismo que decide si la salida de una prueba es la correcta. Tiene que venir de la especificación, no del código. |
| test double (doble de prueba) | Objeto que reemplaza a una dependencia durante una prueba. Los tipos son dummy, stub, fake, spy y mock. |
| dummy | Doble que se pasa porque hace falta llenar el parámetro, pero nunca se usa. |
| stub | Doble que da respuestas fijas a las llamadas, como un reloj en que “ahora” siempre es la misma hora. Controla lo que recibe el código bajo prueba. |
| fake | Doble que funciona de verdad, con un atajo que no sirve para producción, como un repositorio en memoria. |
| spy | Un stub que además registra cómo lo llamaron, para revisarlo después. |
| mock | Doble programado de antemano con las llamadas que espera, que falla si no ocurren. |
| Costura (seam) | Según Feathers, un lugar donde se puede cambiar el comportamiento de un programa sin editar en ese lugar. El Clock que recibe createServer en Kallpa es una. |
| coverage (cobertura) | Qué partes del código se ejecutaron durante las pruebas. Encuentra lo que no se ejecuta, pero no dice que algo se haya verificado: una prueba sin aserciones puede dar 100 %. |
| TDD (test-driven development) | Flujo de trabajo en que la prueba se escribe antes que el código: rojo por la razón esperada, verde con el cambio más simple, y refactorizar. |
| BDD (behaviour-driven development) | Forma de trabajar que parte de una conversación con el cliente, con ejemplos concretos que se convierten en pruebas ejecutables, con o sin Gherkin. |
| Prueba de caracterización (characterization test) | La que fija lo que el código hace hoy, no lo que debería hacer, para poder cambiarlo sin cambiar eso. No es una especificación. |
| property-based testing (pruebas basadas en propiedades) | Una propiedad afirma algo sobre todas las entradas de un dominio; la prueba intenta refutarla con entradas generadas. Si no se logra, la propiedad queda sin refutar, no demostrada. |
| Contraejemplo, shrinking (counterexample) | El contraejemplo es una entrada que hace fallar la propiedad. El shrinking lo simplifica hasta donde sabe; es una búsqueda local, así que no da necesariamente el mínimo global. |
| fuzzing | Alimentar un programa con muchas entradas generadas, a menudo malformadas, buscando que falle. Usa un oráculo implícito: no caerse, no colgarse, no responder 500. |
| mutation testing (pruebas de mutación) | Medir la suite cambiando el programa: un mutante es una copia con un cambio pequeño, que muere si alguna prueba falla y sobrevive si todas pasan. El mutation score es la proporción de mutantes detectados. |
| Mutante equivalente (equivalent mutant) | Un cambio que no altera ningún comportamiento observable dentro del dominio de la función. Ninguna prueba lo puede matar, y no indica un hueco en la suite. |
| Revisión de código (code review) | La lectura de un cambio por otra persona antes del merge. Además de corrección, da comprensión, consistencia, ownership compartido, conocimiento y registro histórico. |
| Análisis estático (static analysis) | Razonar sobre un programa sin ejecutarlo. Por el teorema de Rice, toda herramienta tiene falsos positivos o falsos negativos, y casi siempre los dos. |
| Falso positivo, falso negativo (false positive, false negative) | Un falso positivo es un aviso donde no hay error; un falso negativo, un error sin aviso. Un falso positivo efectivo es un aviso con el que nadie hace nada. |
| linter | Herramienta que busca patrones problemáticos en el código, como una variable sin usar o un catch vacío. El curso usa ESLint; el linting con tipos además usa la información de TypeScript. |
| type checker | Herramienta que revisa los tipos sin ejecutar el programa. En el curso es tsc --noEmit; TypeScript no es sólido a propósito, y cada as, ! y any es un lugar donde el tipo puede mentir. |
| Integración continua (continuous integration) | Práctica en que cada integrante integra su trabajo a la rama principal al menos una vez al día, y cada integración se verifica con un build automático. Un pipeline con ramas de tres semanas no lo es. |
| build | El proceso automático que deja el software verificado y listo. Cuando Node ejecuta TypeScript sin compilar, es tsc, eslint y las pruebas: make check. |
| pipeline | La secuencia automática de pasos que recorre un cambio: build, pruebas y, si corresponde, despliegue. |
| semver (versionado semántico) | Promesa de quien publica sobre lo que cambia con MAJOR, MINOR y PATCH. Las pruebas son la evidencia. ^ acepta hasta el siguiente MAJOR, salvo en 0.x, y ~, hasta el siguiente MINOR. |
| lockfile | Archivo que registra la versión exacta y el hash de cada paquete instalado, también los transitivos. Garantiza que lo instalado es lo mismo, no que sea bueno. |
| Cadena de suministro (supply chain) | Todo lo que interviene para que el software llegue a producción: paquetes, herramientas, actions, imágenes base, el registro y las cuentas de quienes publican. Se ataca por typosquatting, dependency confusion o un mantenedor comprometido. |
| slopsquatting | Publicar un paquete con el nombre que un modelo de lenguaje suele inventar, a la espera de que alguien lo instale. El término circula en la industria, y no es el del artículo que estudia el fenómeno. |
| SBOM (software bill of materials) | La lista de todo lo que va en un producto. Sirve para responder “¿nos afecta?”, y por sí sola no protege de nada. |
Parte 4 — Producción y evolución
| Término | Definición |
|---|---|
| Entrega continua, despliegue continuo (continuous delivery, continuous deployment) | En la entrega continua, cada cambio que pasa el pipeline queda listo para desplegarse, y una persona decide cuándo. En el despliegue continuo, además, se despliega solo. La diferencia es de confianza en el pipeline. |
| Imagen (image) | El sistema de archivos inicial de un contenedor, más sus metadatos: un template de solo lectura. Es inmutable, y se etiqueta con el SHA del commit. |
| rollback | Volver a la versión anterior. Con imágenes inmutables, es correr la imagen anterior sin reconstruir nada. |
| blue-green | Dos entornos completos e iguales: se despliega en el que no atiende y se cambia el tráfico en un solo paso. Da el rollback más rápido y cuesta el doble de infraestructura. |
| canary | La versión nueva recibe primero una parte pequeña del tráfico y se compara con la anterior. Si va bien, sube el porcentaje; si no, se saca. |
| feature flag | Una condición en el código que decide, en ejecución, si una parte se activa. Los hay de release, experimento, operación y permisos, y cada uno tiene owner y fecha. |
| Observabilidad (observability) | La capacidad de responder preguntas sobre lo que hace un sistema desde afuera, a partir de lo que emite y sin cambiarlo. Lo que emite es la telemetría: logs, métricas y traces. |
| logs, métricas, traces | Los logs son eventos individuales; las métricas, números agregados en el tiempo; los traces, el recorrido de una solicitud por varios servicios (tracing). Un log estructurado es una línea JSON. |
| SLI (service level indicator) | Una medida cuantitativa y bien definida de un aspecto del servicio, escrita como proporción: eventos buenos / eventos válidos. |
| SLO (service level objective) | Un objetivo interno sobre un SLI en una ventana: “99.5 % de las solicitudes sin 5xx, en 30 días”. Es una decisión de producto tanto como técnica. |
| SLA (service level agreement) | Un contrato con consecuencias si no se cumple, como una multa o una devolución. Si no hay consecuencia explícita, es un SLO. Un SLA razonable promete menos que el SLO interno. |
| Presupuesto de errores (error budget) | Lo que el SLO permite fallar: 1 − SLO. Con 99.5 % en 30 días son 3.6 horas. |
| Incidente (incident) | Algo que afecta a los usuarios y requiere una respuesta coordinada. Tiene roles, y primero se mitiga, después se entiende. |
| postmortem | Registro escrito de un incidente, sin culpables: impacto, línea de tiempo, causas de proceso y acciones verificables con owner y fecha. “Tener más cuidado” no es una acción. |
| DORA | Programa de investigación que mide el proceso de entrega con cinco métricas: de rendimiento, tiempo de entrega de un cambio, frecuencia de despliegue y tiempo de recuperación; de inestabilidad, tasa de fallo de cambios y tasa de retrabajo. |
| LLM (modelo de lenguaje, large language model) | Modelo que recibe una secuencia de tokens y produce una continuación. No ejecuta nada ni recuerda la llamada anterior, y es una función no determinista. |
| prompt | El texto de entrada que recibe el modelo, con las instrucciones y lo que debe procesar. |
| context window | El máximo de tokens que el modelo considera en una llamada. Entran las instrucciones, la conversación, las descripciones de las herramientas, los archivos leídos y las salidas de los comandos. |
| coding agent (agente) | Un programa que pone a un modelo de lenguaje en un ciclo: el modelo decide, el programa ejecuta la herramienta y el resultado entra al contexto. Que diga que terminó no es evidencia de nada. |
| tool calling | Mecanismo en que el modelo pide usar una herramienta con ciertos argumentos. El modelo no la ejecuta; la ejecuta el programa. |
| context engineering (ingeniería de contexto) | Decidir qué entra al contexto: la especificación, las reglas del proyecto (AGENTS.md), los archivos relevantes y las pruebas. |
| MCP (Model Context Protocol) | Protocolo abierto para conectar aplicaciones con LLM a fuentes de datos y herramientas. Conectar un servidor MCP es una decisión de seguridad: corre código, y sus descripciones entran al contexto. |
| Alucinación (hallucination) | Cuando el modelo inventa algo que no existe, como una función, una opción de un comando o un paquete de npm, con la misma seguridad que lo demás. |
| vibe coding | Según la definición que usa el curso, programar con la esperanza de que el resultado funcione perfecto sin probarlo. |
| eval | Prueba del comportamiento de un sistema con un modelo. Tiene un dataset, un criterio de corrección y una métrica, y se corre con cada cambio. Con un modelo con guion prueba la validación, y no dice nada del modelo real. |
| Inyección de prompts (prompt injection) | Ataque posible porque el modelo no separa instrucciones de datos: directa, si la escribe quien usa el sistema; indirecta, si está en lo que el sistema lee. No tiene solución completa, así que se diseña para que un modelo engañado no pueda hacer daño. |
| lethal trifecta | Según Willison, la combinación en un mismo agente de acceso a datos privados, contenido no confiable y salida hacia afuera. Se rompe quitando una de las tres. |
| Modelo de amenazas (threat model) | Análisis escrito, hecho por quienes construyen el sistema, de qué puede salir mal. Responde cuatro preguntas: qué estamos construyendo, qué puede salir mal, qué vamos a hacer y si lo hicimos bien. |
| Autenticación, autorización (authentication, authorization) | Autenticación es saber quién eres; autorización, decidir qué puedes hacer. Agregar inicio de sesión no cierra un IDOR. |
| IDOR (insecure direct object reference) | El servidor recibe el identificador de un objeto y actúa sobre él sin comprobar si quien llama tiene derecho. |
| Inyección SQL (SQL injection) | Texto del usuario que se vuelve parte de una sentencia SQL. Se evita con sentencias preparadas, siempre. |
| XSS (cross-site scripting) | Un texto controlado por una persona termina interpretado como HTML o JavaScript en la página de otra. Se corrige en el sink, donde el dato se vuelve HTML; una Content Security Policy es una segunda capa. |
| CSRF (cross-site request forgery) | Otra página hace que el navegador de la víctima envíe un pedido, aprovechando que manda sola la cookie de sesión. |
| Accesibilidad (accessibility) | Una página accesible es la que pueden usar personas con discapacidad. WCAG 2.2 tiene cuatro principios (perceptible, operable, comprensible, robusto) y tres niveles, con AA como meta habitual. |
| Licencia (license) | El permiso que da quien tiene los derechos sobre el código; sin ella, nadie tiene permiso. Las permisivas (MIT, Apache-2.0) piden poco; las copyleft (GPL, AGPL) piden compartir el código del trabajo derivado al distribuirlo y, en AGPL, también por la red. |
| Mantenimiento (maintenance) | Todo lo que se hace después de la primera entrega: correctivo, adaptativo, perfectivo y preventivo. Solo el primero arregla errores. |
| Código heredado (legacy code) | Según Feathers, código sin pruebas. Para cambiarlo con seguridad hacen falta pruebas, y para ponerlas suele haber que cambiarlo: ese es su dilema. |
| Deuda técnica (technical debt) | Un atajo que hace más rápido el cambio de hoy y más caros los siguientes; los intereses son ese costo extra. Fowler la clasifica en deliberada o inadvertida, y prudente o imprudente. |
| strangler fig | Reemplazar un sistema de a pocos: el nuevo crece detrás de la misma interfaz, con comparación en lectura antes de cambiar el tráfico. |
| parallel change (expand and contract) | Hacer un cambio incompatible en una interfaz en tres etapas: expandir, migrar y contraer. Cada etapa se puede integrar sola. |
| Deprecación (deprecation) | El proceso ordenado de migrar a los usuarios de un sistema obsoleto y finalmente retirarlo. No es lo mismo que marcarlo como viejo. |