Un equipo pequeño tiene una ventaja envidiable y un riesgo silencioso. La ventaja es la rapidez: poca gente, poca burocracia, decisiones rápidas. El riesgo es que cada mala elección pese más, porque no queda gente para apagar los incendios que provoca.
En el backend, esto es especialmente cierto. Es la capa donde reside la lógica, los datos y la confiabilidad del producto. Una hermosa interfaz en un frágil backend es un castillo sobre arena. Y cuando tienes dos, tres, cinco desarrolladores, no puedes soportar una arquitectura que requiere un batallón para funcionar.
Este texto reúne buenas prácticas de backend diseñadas específicamente para equipos pequeños. Lo que rige aquí no es lo que hacen las grandes empresas, sino lo que tiene sentido cuando cada hora de ingeniería es preciosa y no hay lugar para una complejidad gratuita.
La regla de oro: la simplicidad es una ventaja competitiva
En un equipo pequeño, la complejidad es el enemigo. Cada pieza adicional de arquitectura es una cosa más que comprender, mantener, monitorear y arreglar al amanecer. Y sólo tienes unas pocas personas para hacer todo esto.
Por tanto, la primera buena práctica es resistir la tentación de imitar la arquitectura de los gigantes. Microservicios, mensajería compleja, orquestación de contenedores, todo esto resuelve problemas reales para las grandes empresas y crea nuevos problemas para los equipos pequeños. Un monolito bueno y bien organizado lleva a una startup mucho más lejos de lo que la mayoría admite.
La pregunta que hay que hacerse ante cada elección técnica: ¿esto soluciona un problema que tengo hoy o uno que imagino que tendré algún día? Un equipo pequeño no puede pagar por el segundo.
Elija tecnología aburrida y familiar
Hay un encanto en adoptar el nuevo lenguaje, el banco de moda, el marco que está en la cima. En un equipo pequeño, este amuleto es una trampa.
La tecnología consolidada tiene documentación, comunidad, personas disponibles en el mercado y respuestas listas para los problemas que encontrará. La nueva tecnología tiene poco de esto, y cuando fallas, falla por sí sola. Para un equipo grande, experimentar es barato. Para un equipo de tres personas, cada hora dedicada a luchar contra una herramienta inmadura es una hora que no se dedica al producto.
Elige la base de datos que conoces. Elija el idioma en el que el equipo es productivo. La innovación de su startup debe estar en el producto y el problema que resuelve, no en la tecnología. La tecnología aburrida libera energía para lo que importa.
##Buenas prácticas que se ajustan al presupuesto de un equipo pequeño
Algunas prácticas dan un retorno desproporcionado al esfuerzo. Estos son los que yo priorizaría:
- Base de datos bien modelada: la mayoría de los problemas de backend surgen de datos mal estructurados. Invertir tiempo en el modelo de datos al principio ahorra meses después. Son los cimientos, rehacer los cimientos con la casa aún en pie es doloroso.
- Configuración fuera del código: secretos, claves y parámetros de entorno nunca dentro del repositorio. Esto evita las fugas clásicas y facilita la ejecución del mismo código en diferentes entornos.
- Registros decentes: no tienes un equipo de operaciones para investigar los problemas, por lo que el sistema necesita decirte lo que está sucediendo. Un registro bien hecho es tu único detective cuando algo se estropea.
- Migraciones de bases de datos versionadas: los cambios en la estructura de datos deben ser rastreables y reversibles. Cambiar un asiento a mano, directamente en producción, es como conducir sin cinturón.
- Manejo de errores explícito: decide qué sucede cuando algo falla. Un error que se traga en silencio es el tipo de error que sólo aparece cuando un cliente se queja.
Ninguna de estas prácticas requiere herramientas costosas o conocimientos exóticos. Requieren disciplina, que es el recurso más barato y escaso al mismo tiempo.
Automatiza lo que harías mal con prisa
Los equipos pequeños trabajan bajo presión y la presión produce errores humanos. La defensa consiste en automatizar lo que se puede automatizar, especialmente la implementación y las pruebas.
No tiene por qué ser sofisticado. Un proceso de implementación automatizado, incluso uno simple, evita el error de cargar una versión incorrecta a las once de la noche. Algunas pruebas automatizadas en rutas críticas, inicio de sesión, pago, el flujo principal, evitan que una solución rápida rompa algo importante sin que nadie se dé cuenta.
El objetivo no es una cobertura perfecta de las pruebas, lo cual es un lujo para un equipo grande. Es proteger lo que, si se rompe, perjudica el flujo de caja o la confianza del cliente. La automatización aquí no es sofisticación; Es una red de seguridad para las personas que van a cometer errores porque son humanos y están corriendo.
Reflexión crítica: deuda técnica que tiene sentido
Hay un discurso purista que condena toda deuda técnica. En un equipo pequeño, este discurso no es realista. Tomarás atajos, y haces bien en tomar algunos. El problema no es la deuda; es la deuda invisible y olvidada.
La deuda técnica consciente es una herramienta empresarial. Decides hacer algo simple ahora, sabiendo que tendrás que revisarlo más adelante para entregar valor más rápido. Esto es legítimo. Lo que mata es la deuda que nadie registró, que nadie recuerda y que explota en el peor momento, sin previo aviso.
La madurez es elegir dónde tomar atajos y dónde no. Acceso directo a la funcionalidad secundaria, bien. Atajo en seguridad de datos, en control de acceso, en el tratamiento de datos personales bajo la LGPD, entonces el atajo es una bomba. Saber distinguir unos de otros es lo que separa al pequeño equipo que sobrevive del que implosiona.
Lo que queda
El backend para un equipo pequeño es un ejercicio de concentración. No se trata de hacer lo más sofisticado, se trata de hacer lo suficiente, bueno, en lo que importa, y resistir a todo lo demás.
Sencillez, tecnología conocida, fundamentos sólidos, automatización de lo esencial y deuda técnica consciente. Estas cinco ideas llevan a un equipo pequeño sorprendentemente lejos. La mayoría de los problemas que veo no provienen de una falta de capacidad técnica, sino de demasiada ambición arquitectónica demasiado pronto.
Si lidera un equipo eficiente y está tomando decisiones de backend que le pesarán en los años venideros, vale la pena pensar detenidamente antes de comprometerse con la complejidad. En el blog hay otros textos sobre arquitectura, escalabilidad y producto que hablan de este.
Lea también
- Caché en aplicaciones: guía rápida de buenas prácticas (y los errores que esconde)
- Arquitectura de aplicaciones: conceptos básicos de errores comunes
- Backend As A Service - Buenas Prácticas para Empresas
- Backend como servicio: buenas prácticas para principiantes
- Backend para Aplicaciones: Arquitectura, Tecnologías y Mejores Prácticas
- Seguridad en aplicaciones móviles: arquitectura para equipos pequeños