1. Skip to content

1. Convenciones y Estándares

Nomenclatura, flujo Git, gestión de dependencias, configuración y convenciones de equipo.


1.1 🔤 Nomenclatura

Qué: Reglas consistentes para nombrar variables, funciones, archivos y componentes.

Por qué: Código se lee 10x más que se escribe. Buenos nombres = documentación viva.

Quién: Todo el equipo, enforcement vía linters.

Cuándo: Siempre, desde el primer archivo.

Dónde: Todo el codebase sin excepciones.

Cómo: Style guides + linters automáticos + code review.

Esfuerzo: Inversión inicial configurar linters (2-4h), ahorra horas en code review.

1.1.1 Por Lenguaje

Lenguaje Variables/Funciones Clases/Tipos Constantes Archivos
Python snake_case PascalCase UPPER_SNAKE snake_case.py
JavaScript/TS camelCase PascalCase UPPER_SNAKE kebab-case.ts o PascalCase.tsx
Java camelCase PascalCase UPPER_SNAKE PascalCase.java
SQL snake_case N/A N/A snake_case
CSS kebab-case N/A N/A kebab-case.css

1.1.2 Principios Generales

Principio Mal ❌ Bien ✅
Descriptivo d, tmp, data userCreatedAt, tempPassword
Específico process(), handle() validateEmail(), handleLoginClick()
Evitar abreviaturas usr, btn, msg user, button, message
Booleanos con is/has active, valid isActive, hasPermission
Arrays plurales user, data users, transactions
Funciones verbos email(), user() sendEmail(), getUser()

Excepciones aceptables:

  • Loops: i, j, k (si contexto claro)
  • Callbacks: e (event), err (error)
  • Math: x, y, z

1.2 📁 Estructura de Carpetas

Qué: Organización lógica de archivos y directorios en el proyecto.

Por qué: Estructura clara = onboarding rápido, ubicación predecible de archivos, escalabilidad.

Quién: Architects definen, equipo mantiene.

Cuándo: Al inicio del proyecto, evolucionando según necesidad.

Dónde: Todo el repositorio.

Cómo: Elegir patrón según tamaño y complejidad del proyecto.

Esfuerzo: Decisión temprana de alto impacto, difícil cambiar después.

1.2.1 Backend - Por Tipo de Fichero

Qué: Agrupar por categoría técnica (controllers, services, models).

Cuándo: Proyectos pequeños-medianos (< 20 endpoints), equipo único.

Pros: ✅ Simple, ✅ Intuitivo para juniors
Cons: ❌ Escala mal, ❌ Difícil encontrar features

src/
├── controllers/     # HTTP handlers
│   ├── userController.js
│   ├── orderController.js
│   └── productController.js
├── services/        # Business logic
│   ├── userService.js
│   ├── orderService.js
│   └── emailService.js
├── repositories/    # Data access
│   ├── userRepository.js
│   └── orderRepository.js
├── models/          # Entities, DTOs
│   ├── User.js
│   ├── Order.js
│   └── Product.js
├── middleware/      # Express/FastAPI middleware
│   ├── auth.js
│   ├── errorHandler.js
│   └── logger.js
├── utils/           # Helpers, utilities
│   ├── validators.js
│   └── formatters.js
├── config/          # Configuration
│   ├── database.js
│   └── env.js
└── tests/           # Tests (mirrors src/)
    ├── unit/
    └── integration/

1.2.2 Backend - Por Funcionalidad/Módulo

Qué: Agrupar por feature/bounded context de negocio.

Cuándo: Proyectos medianos-grandes, múltiples equipos, microservicios.

Pros: ✅ Escalable, ✅ Features autónomas, ✅ Ideal para equipos
Cons: ❌ Duplicación inicial, ❌ Puede confundir a juniors

src/
├── auth/                    # Feature: Authentication
│   ├── controllers/
│   │   └── authController.js
│   ├── services/
│   │   └── authService.js
│   ├── models/
│   │   └── User.js
│   ├── middleware/
│   │   └── jwtMiddleware.js
│   └── tests/
├── orders/                  # Feature: Order management
│   ├── controllers/
│   ├── services/
│   ├── models/
│   └── tests/
├── products/                # Feature: Product catalog
│   ├── controllers/
│   ├── services/
│   ├── models/
│   └── tests/
└── shared/                  # Código compartido
    ├── database/
    ├── utils/
    └── config/

1.2.3 Backend - Por Arquitectura Hexagonal

Qué: Separar lógica de negocio (core) de infraestructura (adaptadores).

Cuándo: Dominios complejos, testability crítica, independencia de frameworks.

Pros: ✅ Testeable sin infra, ✅ Cambiar DB/framework sin tocar core
Cons: ❌ Más archivos, ❌ Curva de aprendizaje

src/
├── domain/                  # Core: Business logic
│   ├── entities/           # Pure domain objects
│   │   ├── User.ts
│   │   └── Order.ts
│   ├── value-objects/      # Immutable values
│   │   ├── Email.ts
│   │   └── Money.ts
│   ├── repositories/       # Interfaces (ports)
│   │   └── IUserRepository.ts
│   └── services/           # Business rules
│       └── OrderService.ts
├── application/             # Use cases
│   ├── commands/           # Write operations
│   │   ├── CreateUserCommand.ts
│   │   └── PlaceOrderCommand.ts
│   └── queries/            # Read operations
│       └── GetUserQuery.ts
├── infrastructure/          # Adapters (implementaciones)
│   ├── repositories/       # DB implementations
│   │   └── PostgresUserRepository.ts
│   ├── http/              # API adapters
│   │   ├── controllers/
│   │   └── routes/
│   ├── messaging/         # Event bus, queues
│   └── persistence/       # Migrations, seeds
└── tests/
    ├── unit/              # Domain + Application
    └── integration/       # Infrastructure

1.2.4 Backend - Por Onion Architecture

Qué: Arquitectura en capas concéntricas donde las dependencias apuntan hacia el centro (Domain Model).

Cuándo: Aplicaciones empresariales complejas, lógica de negocio crítica, testing intensivo.

Pros: ✅ Dominio completamente aislado, ✅ Testeable sin infraestructura, ✅ Cambios tecnológicos no afectan core
Cons: ❌ Más archivos y carpetas, ❌ Curva de aprendizaje alta

src/
├── domain/                      # Capa 1: Domain Model (Core)
│   ├── entities/               # Entidades de negocio
│   │   ├── User.ts
│   │   ├── Order.ts
│   │   └── Product.ts
│   ├── value-objects/          # Objetos inmutables
│   │   ├── Email.ts
│   │   ├── Money.ts
│   │   └── Address.ts
│   ├── aggregates/             # Raíces de agregados
│   │   └── OrderAggregate.ts
│   └── exceptions/             # Excepciones de dominio
│       └── InvalidEmailException.ts
├── domain-services/             # Capa 2: Domain Services
│   ├── PricingService.ts       # Lógica que no pertenece a una entidad
│   ├── InventoryValidator.ts
│   └── ShippingCalculator.ts
├── application/                 # Capa 3: Application Services
│   ├── use-cases/              # Casos de uso
│   │   ├── CreateOrderUseCase.ts
│   │   ├── ProcessPaymentUseCase.ts
│   │   └── UpdateUserProfileUseCase.ts
│   ├── interfaces/             # Puertos (interfaces)
│   │   ├── IOrderRepository.ts
│   │   ├── IEmailService.ts
│   │   └── IPaymentGateway.ts
│   └── dto/                    # Data Transfer Objects
│       ├── CreateOrderRequest.ts
│       └── OrderResponse.ts
└── infrastructure/              # Capa 4: Infrastructure
    ├── repositories/           # Implementaciones de repositorios
    │   ├── PostgresOrderRepository.ts
    │   └── MongoUserRepository.ts
    ├── services/               # Implementaciones de servicios
    │   ├── SendGridEmailService.ts
    │   └── StripePaymentGateway.ts
    ├── http/                   # Adaptadores HTTP
    │   ├── controllers/
    │   │   ├── OrderController.ts
    │   │   └── UserController.ts
    │   ├── routes/
    │   │   └── api.routes.ts
    │   └── middleware/
    │       ├── auth.middleware.ts
    │       └── error.middleware.ts
    ├── persistence/            # Migraciones, seeds
    │   ├── migrations/
    │   └── seeds/
    └── config/                 # Configuración
        ├── database.config.ts
        └── app.config.ts

1.2.5 Backend - Por Clean Architecture

Qué: Arquitectura de 4 círculos concéntricos (Entities, Use Cases, Interface Adapters, Frameworks) con dependencias apuntando hacia adentro.

Cuándo: Sistemas empresariales críticos, independencia total de frameworks, proyectos de larga vida (5+ años).

Pros: ✅ Máxima independencia del dominio, ✅ Testability extrema, ✅ Cambiar frameworks sin tocar lógica
Cons: ❌ Más complejo inicialmente, ❌ Puede ser over-engineering para MVPs

src/
├── entities/                        # Círculo 1: Enterprise Business Rules
│   ├── User.ts                     # Entidades de negocio puras
│   ├── Order.ts
│   ├── Product.ts
│   └── value-objects/              # Value Objects
│       ├── Email.ts
│       ├── Money.ts
│       └── OrderStatus.ts
├── use-cases/                       # Círculo 2: Application Business Rules
│   ├── user/
│   │   ├── CreateUser.ts           # Casos de uso específicos
│   │   ├── UpdateUserProfile.ts
│   │   └── DeleteUser.ts
│   ├── order/
│   │   ├── PlaceOrder.ts
│   │   ├── CancelOrder.ts
│   │   └── GetOrderHistory.ts
│   ├── interfaces/                 # Puertos (definidos por Use Cases)
│   │   ├── repositories/
│   │   │   ├── IUserRepository.ts
│   │   │   └── IOrderRepository.ts
│   │   └── services/
│   │       ├── IEmailService.ts
│   │       └── IPaymentGateway.ts
│   └── dto/                        # Request/Response DTOs
│       ├── CreateUserRequest.ts
│       └── OrderResponse.ts
├── adapters/                        # Círculo 3: Interface Adapters
│   ├── controllers/                # Convertir HTTP → Use Cases
│   │   ├── UserController.ts
│   │   └── OrderController.ts
│   ├── presenters/                 # Formatear respuestas
│   │   ├── UserPresenter.ts
│   │   └── OrderPresenter.ts
│   ├── gateways/                   # Implementar interfaces de Use Cases
│   │   ├── PostgresUserRepository.ts
│   │   ├── MongoOrderRepository.ts
│   │   └── SendGridEmailGateway.ts
│   └── view-models/                # Modelos para UI
│       └── OrderViewModel.ts
└── frameworks/                      # Círculo 4: Frameworks & Drivers
    ├── web/                        # Framework web (Express, Fastify)
    │   ├── server.ts
    │   ├── routes/
    │   │   ├── user.routes.ts
    │   │   └── order.routes.ts
    │   └── middleware/
    │       ├── auth.middleware.ts
    │       └── error.middleware.ts
    ├── database/                   # ORM/Database setup
    │   ├── typeorm/
    │   │   ├── config.ts
    │   │   └── migrations/
    │   └── seeds/
    ├── external-services/          # APIs de terceros
    │   ├── stripe/
    │   └── sendgrid/
    └── config/                     # Configuración de frameworks
        ├── env.ts
        └── logger.ts

Nota clave de Clean Architecture:

Dependency Rule: El código fuente solo puede apuntar hacia adentro. Las capas internas NO conocen las externas.

  • FrameworksAdaptersUse CasesEntities
  • Entities NO pueden importar Use Cases o Frameworks

1.2.6 Backend - Por DDD (Domain-Driven Design)

Qué: Organizar por bounded contexts y agregados del dominio.

Cuándo: Dominios muy complejos, múltiples subdominios, enterprise.

Pros: ✅ Refleja negocio, ✅ Ubiquitous language, ✅ Boundaries claros
Cons: ❌ Requiere expertise DDD, ❌ Over-engineering en dominios simples

src/
├── contexts/                    # Bounded Contexts
│   ├── sales/                  # Subdominio: Ventas
│   │   ├── domain/
│   │   │   ├── aggregates/    # Order (root), OrderItem
│   │   │   │   ├── Order.ts
│   │   │   │   └── OrderItem.ts
│   │   │   ├── entities/
│   │   │   ├── value-objects/  # Money, Address
│   │   │   ├── events/        # OrderPlaced, OrderShipped
│   │   │   ├── repositories/  # Interfaces
│   │   │   └── services/      # Domain services
│   │   ├── application/       # Use cases
│   │   │   ├── commands/
│   │   │   └── queries/
│   │   ├── infrastructure/    # Adaptadores
│   │   │   ├── persistence/
│   │   │   └── http/
│   │   └── tests/
│   ├── inventory/             # Subdominio: Inventario
│   │   └── (misma estructura)
│   └── shipping/              # Subdominio: Envíos
│       └── (misma estructura)
├── shared-kernel/             # Código compartido entre contexts
│   ├── domain/
│   └── infrastructure/
└── anti-corruption-layer/     # Traducción entre contexts

1.2.7 Frontend - Por Tipo de Fichero

Qué: Agrupar por categoría técnica (components, pages, hooks).

Cuándo: Proyectos pequeños (< 30 componentes), prototipado rápido.

Pros: ✅ Simple, ✅ Flat structure
Cons: ❌ Difícil escalar, ❌ Componentes relacionados separados

src/
├── components/          # Todos los componentes
│   ├── Button.tsx
│   ├── Card.tsx
│   ├── Header.tsx
│   └── UserProfile.tsx
├── pages/              # Páginas/Routes
│   ├── Home.tsx
│   ├── Dashboard.tsx
│   └── Profile.tsx
├── hooks/              # Custom hooks
│   ├── useAuth.ts
│   └── useFetch.ts
├── services/           # API calls
│   ├── api.ts
│   └── authService.ts
├── store/              # State management
│   ├── slices/
│   └── store.ts
├── utils/              # Helpers
│   └── formatters.ts
├── types/              # TypeScript types
│   └── User.ts
└── assets/             # Images, fonts

1.2.8 Frontend - Por Funcionalidad/Módulo

Qué: Agrupar por feature de negocio.

Cuándo: Apps medianas-grandes (> 30 componentes), múltiples features.

Pros: ✅ Escalable, ✅ Features autónomas, ✅ Fácil eliminar features
Cons: ❌ Puede tener duplicación compartida

src/
├── features/                # Features de negocio
│   ├── auth/               # Feature: Autenticación
│   │   ├── components/
│   │   │   ├── LoginForm.tsx
│   │   │   └── RegisterForm.tsx
│   │   ├── hooks/
│   │   │   └── useAuth.ts
│   │   ├── services/
│   │   │   └── authApi.ts
│   │   ├── store/
│   │   │   └── authSlice.ts
│   │   ├── types/
│   │   │   └── User.ts
│   │   └── pages/
│   │       ├── LoginPage.tsx
│   │       └── RegisterPage.tsx
│   ├── dashboard/          # Feature: Dashboard
│   │   ├── components/
│   │   ├── hooks/
│   │   └── pages/
│   └── profile/            # Feature: Perfil usuario
│       └── (similar)
├── shared/                  # Componentes reutilizables
│   ├── components/         # Button, Card, Modal
│   │   ├── ui/            # Componentes UI básicos
│   │   └── layout/        # Header, Sidebar, Footer
│   ├── hooks/             # useDebounce, useLocalStorage
│   ├── utils/             # Helpers generales
│   └── types/             # Types compartidos
└── app/                    # App-level config
    ├── routes/
    ├── store/
    └── providers/

1.2.9 Frontend - Por Atomic Design

Qué: Jerarquía de componentes: Atoms → Molecules → Organisms → Templates → Pages.

Cuándo: Design systems, componentes altamente reutilizables, equipos design+dev.

Pros: ✅ Reutilización máxima, ✅ Storybook friendly, ✅ Consistencia visual
Cons: ❌ Over-engineering para apps simples, ❌ Puede ser rígido

src/
├── components/
│   ├── atoms/              # Componentes básicos indivisibles
│   │   ├── Button/
│   │   │   ├── Button.tsx
│   │   │   ├── Button.test.tsx
│   │   │   ├── Button.stories.tsx
│   │   │   └── Button.module.css
│   │   ├── Input/
│   │   ├── Label/
│   │   ├── Icon/
│   │   └── Avatar/
│   ├── molecules/          # Combinación de atoms
│   │   ├── SearchBar/      # Input + Button + Icon
│   │   ├── FormField/      # Label + Input + Error
│   │   ├── Card/           # Container con atoms
│   │   └── MenuItem/
│   ├── organisms/          # Secciones complejas
│   │   ├── Header/         # Logo + SearchBar + UserMenu
│   │   ├── ProductCard/    # Card + Button + Image + Price
│   │   ├── NavigationBar/
│   │   └── CommentThread/
│   ├── templates/          # Layouts de página
│   │   ├── MainLayout/     # Header + Sidebar + Content + Footer
│   │   ├── DashboardLayout/
│   │   └── AuthLayout/
│   └── pages/              # Instancias de templates con data
│       ├── HomePage/
│       ├── DashboardPage/
│       └── ProfilePage/
├── hooks/
├── services/
└── store/

1.2.10 Frontend - Híbrido (Features + Atomic para Shared)

Qué: Features por módulo + Atomic Design para componentes compartidos.

Cuándo: Mejor de ambos mundos para apps grandes con design system.

Pros: ✅ Escalable, ✅ Reutilización, ✅ Features aisladas
Cons: ❌ Más complejo inicialmente

src/
├── features/                # Por módulo de negocio
│   ├── auth/
│   │   ├── components/     # Componentes específicos de auth
│   │   │   └── LoginForm.tsx
│   │   ├── hooks/
│   │   └── pages/
│   ├── dashboard/
│   └── products/
└── shared/                  # Atomic Design para compartidos
    ├── atoms/              # Button, Input, Icon
    ├── molecules/          # SearchBar, FormField
    ├── organisms/          # Header, Sidebar
    ├── templates/          # MainLayout, DashboardLayout
    ├── hooks/
    └── utils/

1.2.11 Monorepo

Qué: Múltiples apps/packages en un repositorio.

Cuándo: Microservicios, múltiples frontends, librerías compartidas.

Pros: ✅ Código compartido fácil, ✅ Atomic commits cross-repo
Cons: ❌ Build más complejo, ❌ Requiere tooling (Nx, Turborepo)

monorepo/
├── apps/                    # Aplicaciones
│   ├── web/                # Frontend web (Next.js)
│   ├── mobile/             # Mobile app (React Native)
│   ├── admin/              # Admin panel
│   ├── api/                # Backend API
│   └── workers/            # Background jobs
├── packages/                # Librerías compartidas
│   ├── ui/                 # Design system compartido
│   │   ├── components/
│   │   └── package.json
│   ├── utils/              # Utilidades compartidas
│   ├── types/              # TypeScript types compartidos
│   ├── config/             # Configs (ESLint, TS, etc)
│   └── api-client/         # Cliente API compartido
├── tools/                   # Scripts build, codegen
├── docs/                    # Documentación
├── package.json            # Root package
├── turbo.json              # Turborepo config
└── nx.json                 # Nx config (alternativa)

1.2.12 Comparación y Decisión

Estructura Proyecto Ideal Complejidad Escalabilidad Curva Aprendizaje
Por Tipo Pequeño, 1 equipo Baja ⭐ Baja ⭐⭐ Baja ⭐
Por Funcionalidad Mediano-grande, múltiples features Media ⭐⭐ Alta ⭐⭐⭐⭐ Media ⭐⭐
Hexagonal Testability crítica, cambios frecuentes de infra Alta ⭐⭐⭐ Alta ⭐⭐⭐⭐ Alta ⭐⭐⭐⭐
Onion Lógica de negocio compleja, testing intensivo Alta ⭐⭐⭐ Alta ⭐⭐⭐⭐ Alta ⭐⭐⭐⭐
Clean Architecture Independencia total de frameworks, proyectos 5+ años Muy Alta ⭐⭐⭐⭐ Muy Alta ⭐⭐⭐⭐⭐ Muy Alta ⭐⭐⭐⭐⭐
DDD Dominio muy complejo, enterprise Muy Alta ⭐⭐⭐⭐ Muy Alta ⭐⭐⭐⭐⭐ Muy Alta ⭐⭐⭐⭐⭐
Atomic Design Design system, componentes reutilizables Media ⭐⭐⭐ Media ⭐⭐⭐ Media ⭐⭐⭐
Monorepo Múltiples apps relacionadas Alta ⭐⭐⭐⭐ Muy Alta ⭐⭐⭐⭐⭐ Alta ⭐⭐⭐⭐

Recomendación general:

  • Startup/MVP: Por Tipo (simple y rápido)
  • Producto creciendo: Por Funcionalidad (escala mejor)
  • Testability crítica: Hexagonal o Onion (aislamiento del dominio)
  • Enterprise/Crítico: Clean Architecture o DDD (máxima independencia)
  • Design System: Atomic Design
  • Múltiples apps: Monorepo

1.3 🔀 Git Workflow

What (Qué es): Convenciones para branches, commits y merges.

Why (Por qué): Historial limpio, deployment predecible, colaboración efectiva.

Who (Quién): Todo el equipo, enforcement vía Git hooks.

When (Cuándo): Cada commit, cada branch, cada merge.

Where (Dónde): Repositorio Git.

How (Cómo): Naming conventions + Conventional Commits + Git hooks.

How much (Cuánto): Setup inicial 1-2h, ahorra horas en debugging histórico.

1.3.1 Branch Naming

Tipo Formato Ejemplo
Feature feature/descripcion-corta feature/user-authentication
Bugfix fix/descripcion-bug fix/login-redirect-loop
Hotfix hotfix/descripcion hotfix/critical-security-patch
Refactor refactor/descripcion refactor/extract-user-service
Docs docs/descripcion docs/api-documentation
Chore chore/descripcion chore/update-dependencies

1.3.2 Conventional Commits

Formato: <type>(<scope>): <description>

Tipos:

  • feat: Nueva feature
  • fix: Bug fix
  • docs: Solo documentación
  • style: Formato (no cambia lógica)
  • refactor: Ni fix ni feature
  • test: Agregar tests
  • chore: Mantenimiento (deps, config)
  • perf: Mejora performance

Ejemplos:

feat(auth): add JWT authentication
fix(api): handle null user in /profile endpoint
docs(readme): update installation instructions
refactor(user-service): extract validation logic
test(auth): add unit tests for login flow
chore(deps): upgrade React to 18.2
```text

**Herramientas:** [commitlint](https://commitlint.js.org/), [husky](https://typicode.github.io/husky/)

### GitFlow vs Trunk-Based

| Aspecto | GitFlow | Trunk-Based |
| :-------- | :-------- | :------------ |
| **Branches** | `main`, `develop`, `feature/*`, `release/*`, `hotfix/*` | `main`, `feature/*` (short-lived) |
| **Merge a main** | Via `release` branch | Directo (tras CI/CD) |
| **Feature lifetime** | Días/semanas | <24 horas ideal |
| **Cuándo usar** | Releases planificados, equipos grandes | CI/CD continuo, deploy frecuente |

**Trunk-Based (recomendado moderno):**

```text
main ─────●─────●─────●────→ (siempre deployable)
                        feature (merge rápido)

1.4 📦 Gestión de Dependencias

1.4.1 Package Managers

Lenguaje Manager Lock File Comando Install
JavaScript npm, pnpm, yarn package-lock.json, pnpm-lock.yaml npm install
Python pip, poetry, conda requirements.txt, poetry.lock pip install -r requirements.txt
Java Maven, Gradle pom.xml, gradle.lock mvn install
Go go modules go.sum go mod download
Rust Cargo Cargo.lock cargo build

1.4.2 Best Practices

Práctica Por qué Cómo
Pin versions Reproducibilidad react@18.2.0 no react@^18.0.0 (prod)
Commit lock files Builds deterministas Git add package-lock.json
Security scanning Detectar CVEs Dependabot, Snyk, npm audit
Update regularmente Evitar tech debt Mensual, usar bots
Minimizar deps Menos superficie ataque Evaluar cada nueva dep

Versioning (SemVer):

1.2.3
│ │ └─ PATCH: Bug fixes
│ └─── MINOR: New features (backward compatible)
└───── MAJOR: Breaking changes

Ranges:

  • 1.2.3: Exacto
  • ^1.2.3: Compatible con 1.x.x (>= 1.2.3 < 2.0.0)
  • ~1.2.3: Patch updates (>= 1.2.3 < 1.3.0)

1.5 🌍 i18n y l10n

i18n: Internationalization (preparar app para múltiples idiomas)
l10n: Localization (traducir para región específica)

1.5.1 Estructura

// locales/en.json
{
  "common": {
    "welcome": "Welcome",
    "logout": "Log out"
  },
  "errors": {
    "notFound": "Page not found",
    "serverError": "Something went wrong"
  }
}

// locales/es.json
{
  "common": {
    "welcome": "Bienvenido",
    "logout": "Cerrar sesión"
  }
}

1.5.2 Best Practices - i18n

Práctica Cómo
Claves descriptivas user.profile.editButton no btn1
Pluralización Usar librería con soporte (ICU)
Variables "Hello {{name}}" con interpolación
Formatos Usar Intl para fechas, monedas, números
RTL support CSS con dir="auto"

Herramientas:


1.6 ⚙️ Configuración y Entornos

1.6.1 Environments

Ambiente Propósito Características
local Desarrollo individual DB local, debug on, hot reload
dev Integración equipo Shared DB dev, CI/CD, feature branches
staging Pre-producción Datos prod-like, testing final
production Usuarios reales Alta disponibilidad, monitoreo, backups

1.6.2 Factor App Config

Principio: Config en environment variables, no en código.

# ❌ Mal
DATABASE_URL = "postgresql://localhost/mydb"

# ✅ Bien
import os
DATABASE_URL = os.getenv("DATABASE_URL")

.env (solo local, no commitear):

DATABASE_URL=postgresql://localhost/mydb
SECRET_KEY=dev-secret-key-not-for-prod
DEBUG=true

Producción: Usar secrets managers (Vault, AWS Secrets Manager).


1.7 🔒 .gitignore

Esenciales:

# Dependencies
node_modules/
venv/
.venv/

# Build outputs
dist/
build/
*.pyc
__pycache__/

# Environment
.env
.env.local

# IDEs
.vscode/
.idea/
*.swp

# OS
.DS_Store
Thumbs.db

# Logs
*.log
logs/

# Testing
coverage/
.pytest_cache/

1.8 📋 Code Style

1.8.1 Formatters (automático)

Lenguaje Herramienta Config
JavaScript/TS Prettier .prettierrc
Python Black, Ruff pyproject.toml
Java google-java-format Maven/Gradle plugin

1.8.2 Linters (reglas)

Lenguaje Herramienta Config
JavaScript/TS ESLint .eslintrc.json
Python Pylint, Ruff .pylintrc
Java Checkstyle checkstyle.xml

Setup:

// package.json
{
  "scripts": {
    "lint": "eslint src/",
    "format": "prettier --write src/",
    "format:check": "prettier --check src/"
  },
  "husky": {
    "hooks": {
      "pre-commit": "npm run format && npm run lint"
    }
  }
}

1.9 📝 Comentarios y Documentación

1.9.1 Cuándo comentar

✅ Comentar ❌ No comentar
Por qué existe código complejo Qué hace (obvio del código)
Workarounds temporales Código autoexplicativo
Decisiones arquitecturales Restating código en español
Algoritmos no obvios TODOs sin contexto

Ejemplo:

// ❌ Mal: restating
// Incrementa contador
counter++;

// ✅ Bien: explica por qué
// Workaround: API retorna duplicados, deduplicar manualmente
// TODO: Reportar bug al team de backend (ticket: API-123)
const uniqueUsers = [...new Set(users)];

1.9.2 JSDoc / Docstrings

Python:

def calculate_discount(price: float, discount_percent: float) -> float:
    """
    Calcula precio con descuento aplicado.

    Args:
        price: Precio original
        discount_percent: Porcentaje de descuento (0-100)

    Returns:
        Precio final con descuento aplicado

    Raises:
        ValueError: Si discount_percent < 0 o > 100
    """
    if not 0 <= discount_percent <= 100:
        raise ValueError("Discount must be between 0 and 100")
    return price * (1 - discount_percent / 100)

TypeScript:

/**
 * Validates email format using RFC 5322 regex
 * @param email - Email address to validate
 * @returns true if valid, false otherwise
 * @example
 * isValidEmail("user@example.com") // true
 * isValidEmail("invalid") // false
 */
function isValidEmail(email: string): boolean {
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return regex.test(email);
}

1.10 🚫 Anti-patrones

Anti-patrón Problema Solución
Inconsistencia Parte camelCase, parte snake_case Style guide + linter
Magic numbers if (status === 3) if (status === OrderStatus.COMPLETED)
Branches long-lived Merge conflicts, context switching Feature flags, trunk-based
.env en Git Secrets públicos .gitignore, educación
Sin lock files "Works on my machine" Commitear lock files

1.11 📚 Recursos