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.
- ✅
Frameworks→Adapters→Use Cases→Entities- ❌
EntitiesNO pueden importarUse CasesoFrameworks
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 featurefix: Bug fixdocs: Solo documentaciónstyle: Formato (no cambia lógica)refactor: Ni fix ni featuretest: Agregar testschore: 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:
- i18next (JS)
- react-intl (React)
- django-modeltranslation (Django)
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 |