La navaja de Ockham y el código: contra la abstracción prematura

Una interfaz PaymentProvider con una sola implementación durante dos años. Se creó el primer mes, cuando aún no había ninguna pasarela integrada, porque estaba claro que algún día habría varias.

Algún día llegó la segunda. No encajaba. La primera cobraba y devolvía el resultado en la misma llamada; la nueva confirmaba por webhook media hora después. La interfaz suponía una operación síncrona con respuesta inmediata, y esa suposición estaba metida en la forma misma de los métodos. Hubo que rehacerla entera.

El resultado: dos años pagando una indirección que no protegía de nada, más el refactor que la indirección existía para evitar. La abstracción no se equivocó en si habría varias pasarelas. Acertó en eso. Se equivocó en cómo iban a ser distintas, que es la única parte que importaba.

El principio, tal cual

En el siglo XIV, Guillermo de Ockham formuló una regla que sobrevivió a siete siglos: no multipliques las entidades sin necesidad. Era metafísica, no ingeniería, y no dice «lo simple es bonito». Dice algo más fuerte: entre dos explicaciones que dan cuenta de los mismos hechos, la que introduce menos entidades es preferible. No por gusto estético, sino porque cada entidad extra es una afirmación más que puede estar equivocada.

En código, cada capa es una entidad. Cada interfaz, cada factoría, cada capa de indirección es una afirmación sobre el futuro: «esto va a variar de estas formas». Y como toda afirmación sobre el futuro, casi siempre es falsa en los detalles, que es donde se paga.

La abstracción es una apuesta, no un regalo

Circula la idea de que abstraer siempre es virtud, de que un código con muchas capas es más profesional. Es al revés. Abstraer es apostar.

Cuando creas una interfaz con una sola implementación estás apostando a que algún día habrá varias y a que se van a diferenciar por donde tú has puesto la costura. Lo primero se acierta bastante. Lo segundo casi nunca, porque para acertar habría que conocer la segunda implementación, y si la conocieras no estarías abstrayendo: estarías describiendo.

La abstracción correcta se paga sola. La prematura la paga el que la mantiene, todos los días, por un futuro que llegó distinto.

Epicuro y las palabras sin perfil

Epicuro llamó canónica a su teoría del conocimiento. La palabra viene del canon, la regla del carpintero: la vara con la que se comprueba si algo está recto. Es un buen sitio del que sacar el nombre de una epistemología, y dice bastante del tipo de filosofía que era.

Su regla de arranque es la que aquí interesa. Sostenía que no se puede investigar nada sin una noción previa depositada por la experiencia repetida: haber visto muchos caballos deja un perfil de «caballo», y por eso puedes preguntar si lo que hay allí al fondo es un caballo o una vaca. Sin ese perfil, la pregunta no se puede ni formular. Y de ahí su aviso: no habríamos dado nombre a algo si antes no hubiéramos aprendido su perfil. Usar una palabra general sin esa experiencia detrás no es hablar con precisión: es emitir un ruido con forma de concepto, y discutir sobre él no termina nunca porque cada uno tiene en la cabeza un perfil distinto.

Una abstracción es exactamente eso, un nombre general. PaymentProvider pretendía nombrar lo común a todas las pasarelas de pago habiendo visto una. No era un concepto: era una expectativa con nombre de concepto. Y como todas las palabras sin perfil detrás, generó su ración de discusiones que no se podían cerrar, porque cada uno defendía una idea distinta de lo que la interfaz «debía» abarcar y ninguno tenía casos con los que zanjarlo.

Epicuro tenía además una recomendación para los fenómenos donde la evidencia no alcanza a decidir entre varias explicaciones posibles: no elegir. Sostener todas las compatibles con lo observado, y esperar. Es un consejo extraño para un físico y buenísimo para un arquitecto de software. Cuando de verdad no sabes por dónde va a variar algo, la jugada disciplinada no es elegir una forma de variación: es no construir ninguna todavía, que es la única manera de no cerrar las demás.

La regla de las tres veces, ahora con motivo

Hay una heurística vieja del gremio: no abstraigas hasta la tercera repetición. La primera vez escribes el código. La segunda duplicas —sí, a propósito— y aguantas la incomodidad. Solo a la tercera extraes la abstracción.

Se suele justificar por prudencia estadística, y funciona mejor con la justificación de Epicuro. Tres casos son, más o menos, el mínimo de experiencia que deposita un perfil. Con uno tienes un caso. Con dos tienes un caso y una sospecha, y la sospecha suele ser que se parecen en lo accidental. Con tres empiezas a ver qué es lo que de verdad se repite y qué era circunstancia del primero.

A la tercera no estás adivinando el patrón: lo estás leyendo. Y la diferencia entre las dos cosas no se nota en el diff, se nota dos años después.

Duplicar dos veces sale más barato que mantener durante dos años una abstracción que adivinó mal. La duplicación prematura se borra en cinco minutos; la abstracción prematura echa raíces, porque para entonces hay código escrito contra ella.

Cómo distingo una capa necesaria de una prematura

• ¿Cuántas implementaciones reales tiene hoy? Una interfaz con una sola no es una abstracción: es un adorno con coste de lectura.
• ¿La variación ya ocurrió, o la estoy imaginando? Abstraer sobre variación observada es diseño. Abstraer sobre variación imaginada es adivinación con buena presentación.
• ¿Podría escribir en una línea qué tienen en común los casos? Si no me sale, o me sale con un «y» en medio, no tengo un concepto todavía.
• ¿Puedo introducirla después sin dolor? Si extraerla el día que haga falta cuesta media hora, no la construyas hoy. Espera al día.
• ¿Esta capa aísla algo, o solo mueve el problema una casa más allá? La indirección que no protege de nada solo añade un salto más a la lectura.

El coste que no se ve en el diff

Lo que hace peligrosa a la abstracción prematura es que no aparece como problema. Un diff con más interfaces, más capas y más ficheros parece trabajo serio. Nadie rechaza un PR por estar «demasiado bien estructurado».

El coste llega después, disperso e imposible de atribuir: la persona que tarda el doble en seguir un flujo simple, el bug que se esconde tres capas abajo, el cambio trivial que hay que tocar en cinco sitios porque la abstracción repartió una decisión que debería haber vivido junta.

Y hay un coste peor, que es el que tuvimos con la pasarela: la abstracción equivocada no solo estorba, enseña mal. Todo el que llegó después leyó en aquella interfaz que cobrar era una operación síncrona, porque eso era lo que la interfaz decía. Escribieron su código creyéndoselo. El día que apareció el webhook, lo que había que arreglar no era una clase: era todo lo que se había apoyado en una afirmación falsa sobre el mundo.

Por qué me importa

Desconfiar de las entidades que uno introduce para explicar algo es un hábito viejo. Cada concepto nuevo tiene que ganarse el sitio: si los mismos hechos se explican sin él, sobra.

El código es igual. La elegancia no está en la cantidad de capas que sostienes, sino en la cantidad que conseguiste no necesitar. Un sistema es maduro no cuando ya no puedes añadirle nada, sino cuando no puedes quitarle nada sin romperlo.

Siete siglos después, la navaja sigue siendo el mejor consejo de arquitectura que conozco, y ahora la uso con la coletilla epicúrea puesta: cuando dudes entre dos diseños, quédate con el que introduce menos cosas que puedan estar equivocadas — y no nombres lo que todavía no has visto tres veces.