Volver a los artículos
engineering1 min de lectura

My rule for shared code: if the per-app adapter is longer than 50 lines, the abstraction is wrong.

The 50-line adapter rule

Rob Vasquez·

My rule for shared code: if a per-app adapter grows past about 50 lines, fix the abstraction, not the app.

Here's the shape I hold myself to. A shared library owns all the real logic, the protocol and the ugly edge cases included. When an app wants to use it, the app writes one small adapter. Map my rows into the shape the library expects, hand it a callback to save the result, done. No business logic leaks back into the app.

When that adapter stays near 50 lines, the abstraction is carrying its weight. When it balloons, the library isn't owning the hard part yet, so I go fix the library instead of piling special cases into ten apps.

This one constraint does more for a codebase than any style guide. It forces the logic to live in exactly one place, and it gives you a cheap, visible test for whether your abstraction is real or just a folder with a nice name.

Most duplication comes from abstractions too weak to adopt, so people quietly copy instead.

What's your threshold for an abstraction pulling its weight? Curious where others draw the line.

SoftwareArchitectureCleanCodeTypeScriptEngineeringLeadership

¿Necesitas un camino práctico hacia la entrega habilitada por IA?

Comienza con una auditoría de preparación para IA de precio fijo y sal con una hoja de ruta concreta.

Ver la auditoría de preparación para IA