Enterprise JavaScript: cómo no ahogarse en el código de una empresa gigante

JavaScript de un millón de líneas: introducción al mundo enterprise

¿Alguna vez has visto un proyecto de JavaScript que pese más que el sistema operativo de tu portátil? Bienvenido al desarrollo enterprise. Aquí no hay lugar para "lo escribí rápido sobre la marcha" ni para "seguro funciona". Aquí el código vive durante años, lo leen cientos de desarrolladores, y un error en un paquete npm puede detener el funcionamiento de un banco entero.

Enterprise JavaScript no trata sobre frameworks (aunque React o Angular también están presentes). Se trata de cultura, procesos y arquitectura que permiten gestionar el caos. Si quieres entender en qué se diferencia una startup de una corporación, o te estás preparando para una entrevista en una gran empresa, este artículo es para ti. Analizaremos las características clave del desarrollo de JavaScript en un entorno enterprise, respaldándolo todo con ejemplos reales de código.

Monorepositorio vs. multirrepositorio: la batalla de los titanes

En una startup, lo más probable es que tengas un solo repositorio en GitHub. En el mundo enterprise es más complejo. Puedes tener 50 microservicios, una biblioteca común de componentes de UI, un paquete separado para utilidades y una docena más de proyectos heredados en jQuery.

¿Por qué gana el monorepositorio?

Las grandes empresas (Google, Facebook, Microsoft) utilizan monorepositorios. Un único repositorio que contiene todo el código de la empresa. Esto simplifica la refactorización: cambias una API en un lugar y todos los proyectos actualizan los cambios. Pero hay un detalle: herramientas como Lerna, Nx o Turborepo se vuelven obligatorias.

Ejemplo de estructura de monorepositorio usando npm workspaces:

// package.json (raíz)\n{\n  "name": "enterprise-monorepo",\n  "private": true,\n  "workspaces": [\n    "packages/*"\n  ],\n  "scripts": {\n    "build": "npm run build --workspaces",\n    "test": "npm run test --workspaces"\n  }\n}

Ahora tienes una carpeta packages/ donde se encuentran paquetes individuales (por ejemplo, ui-kit, api-client, core). Cada paquete tiene su propio package.json, pero las dependencias se instalan una sola vez en la raíz.

Consejo: En el mundo enterprise, nunca uses npm link manualmente. Solo herramientas de monorepositorio, de lo contrario corres el riesgo de tener un "infierno de dependencias".

TypeScript: no es un lujo, es una necesidad

Muchos piensan: "¿Para qué TypeScript si ya escribo sin errores?". En el mundo enterprise esto es estricto. Cuando tienes una base de código de 500,000 líneas y un equipo de 30 personas, la tipificación dinámica se convierte en una fuente de errores que pueden llegar a producción.

TypeScript permite:

\n
• Crear contratos claros entre módulos (a través de interfaces).
\n
• Simplificar la refactorización (el IDE te indicará qué se ha roto).
\n
• Reducir la cantidad de errores en tiempo de ejecución.
\n

Ejemplo de cómo un proyecto enterprise utiliza TypeScript para describir una API:

// types/api.ts\nexport interface User {\n  id: string;\n  name: string;\n  email: string;\n  role: 'admin' | 'user' | 'moderator';\n}\n\nexport interface ApiResponse<T> {\n  data: T;\n  status: number;\n  message: string;\n}\n\n// services/userService.ts\nimport { User, ApiResponse } from '../types/api';\n\nexport async function getUser(id: string): Promise<ApiResponse<User>> {\n  const response = await fetch(`/api/users/${id}`);\n  return response.json();\n}

Observa: ApiResponse<T> es un genérico. Garantiza que la respuesta del servidor siempre tendrá una estructura predecible. En el mundo enterprise, esto es un estándar.

Arquitectura: capas, módulos e inversión de dependencias

En una startup, puedes poner toda la lógica en un componente de React. En el mundo enterprise, esto llevaría a un desastre. Aquí se utiliza una arquitectura estricta:

\n
• Capa de presentación (UI) — Componentes de React/Vue/Angular que solo renderizan datos.
\n
• Capa de aplicación
\n