Hardcoded

Qué es

Hardcoded (o “hardcodeado” en spanglish) significa escribir valores fijos directamente en el código fuente, en lugar de obtenerlos de una fuente externa como:

Variables de entorno
Archivos de configuración
Base de datos
Entrada del usuario

Es una de las malas prácticas más comunes en desarrollo de software.

Errores comunes de pronunciación

❌ “ar-coded” (la ‘h’ no es muda en inglés)
❌ “hard-codead” (no termina en ‘ead’)

Variantes aceptadas:

Hard-coded (con guión)
Hardcoded (junto)
Hard coded (separado)

Ejemplo: El Número de Teléfono que Nadie Puede Cambiar

Código hardcodeado (MAL)

// ❌ MAL: Número hardcodeado
function enviarSMS(mensaje) {
  const telefono = "+52-555-123-4567";  // 😱 Hardcodeado
  smsService.send(telefono, mensaje);
}

// ❌ MAL: URL hardcodeada
function obtenerUsuarios() {
  const url = "https://api.miempresa.com/users";  // 😱 Hardcodeado
  return fetch(url);
}

// ❌ MAL: Credenciales hardcodeadas (PELIGROSO)
function conectarDB() {
  const password = "admin123";  // 🚨 NUNCA hagas esto
  return db.connect("admin", password);
}

Código correcto (BIEN)

// ✅ BIEN: Desde variable de entorno
function enviarSMS(mensaje) {
  const telefono = process.env.SMS_PHONE_NUMBER;
  smsService.send(telefono, mensaje);
}

// ✅ BIEN: Desde configuración
function obtenerUsuarios() {
  const url = config.api.usersEndpoint;
  return fetch(url);
}

// ✅ BIEN: Credenciales desde entorno
function conectarDB() {
  const password = process.env.DB_PASSWORD;
  return db.connect(process.env.DB_USER, password);
}

Por qué es un problema

Problema	Consecuencia
Difícil de cambiar	Hay que modificar código, recompilar y redesplegar
Inseguro	Credenciales expuestas en repositorios
No escalable	Diferentes valores para dev/staging/producción
Difícil de mantener	Valores dispersos por todo el código
Rompe pruebas	No puedes usar valores de prueba fácilmente

Por qué importa para tu empresa

Para quien contrata o evalúa software, esto no es un detalle técnico: es lo que hace que un cambio trivial cueste caro.

Un cambio de un minuto tarda días. Subir un precio, cambiar el correo de notificación o el porcentaje de un impuesto debería ser editar un campo. Si está fijo en el código, hay que modificarlo, probarlo y desplegar una versión nueva.
Te ata a quien lo escribió. Si solo se puede cambiar tocando el código, dependes de ese proveedor, de su agenda y de su tarifa.
Es un riesgo de seguridad. Las contraseñas y llaves escritas en el código terminan copiadas en cada respaldo y en cada equipo que tenga una copia del repositorio.
Encarece cada ambiente. Probar en un entorno de pruebas obliga a duplicar y editar código, en vez de cambiar una configuración.

La pregunta que conviene hacer antes de aceptar una entrega: ¿qué puedo cambiar yo sin llamar al proveedor? Si la respuesta es “nada”, cada ajuste futuro llegará como una cotización.

Es una de las formas más comunes de deuda técnica y un punto fijo de revisión en nuestro trabajo de modernización de sistemas legacy.

Caso Práctico: La Pizzería y sus Precios

Imagina que tienes un sistema de pedidos para tu pizzería.

Enfoque hardcodeado (problemas garantizados)

# precios.py - ❌ MAL
def calcular_total(pizzas, bebidas):
    precio_pizza = 150  # 😱 Hardcodeado
    precio_bebida = 35  # 😱 Hardcodeado
    iva = 0.16          # 😱 Hardcodeado

    subtotal = (pizzas * precio_pizza) + (bebidas * precio_bebida)
    return subtotal * (1 + iva)

Problemas:

El IVA sube a 17% → Hay que buscar todos los “0.16” en el código
Promoción de pizzas a $120 → Modificar código, probar, desplegar
Sucursal en otro país con precios e impuestos diferentes → Hay que duplicar o bifurcar el código

Enfoque con configuración (flexible)

# config.py
import os

PRECIOS = {
    "pizza": float(os.getenv("PRECIO_PIZZA", 150)),
    "bebida": float(os.getenv("PRECIO_BEBIDA", 35)),
    "iva": float(os.getenv("IVA", 0.16)),
}

# precios.py - ✅ BIEN
from config import PRECIOS

def calcular_total(pizzas, bebidas):
    subtotal = (pizzas * PRECIOS["pizza"]) + (bebidas * PRECIOS["bebida"])
    return subtotal * (1 + PRECIOS["iva"])

Beneficios:

Cambiar precios sin tocar código (basta con reiniciar o redesplegar con otra configuración)
Diferentes precios por ambiente (dev/prod)
Para valores que cambian a menudo, como promociones, lo ideal es guardarlos en base de datos

Cuándo SÍ es aceptable hardcodear

A veces tiene sentido tener valores fijos:

// ✅ Constantes matemáticas
const PI = 3.14159265359;

// ✅ Valores que NUNCA cambian
const DIAS_SEMANA = 7;
const HORAS_DIA = 24;

// ✅ Valores por defecto (con opción de override)
const TIMEOUT = config.timeout || 5000;  // Default: 5 segundos

// ✅ Enums o estados fijos
const ESTADOS = {
  PENDIENTE: "pending",
  COMPLETADO: "completed",
  CANCELADO: "cancelled"
};

Cómo identificar código hardcodeado

Señales de alerta en tu código:

🚨 Strings con URLs completas
🚨 Números mágicos (42, 1000, 3600)
🚨 Credenciales o tokens
🚨 Rutas de archivos absolutas
🚨 Direcciones de email
🚨 Nombres de servidores
🚨 Puertos específicos

Cómo solucionarlo

1. Variables de entorno

# .env  (no lo subas al repositorio: agrégalo a .gitignore)
DATABASE_URL=postgres://user:pass@localhost:5432/mydb
API_KEY=sk-1234567890
MAX_CONNECTIONS=100

2. Archivos de configuración

// config.json
{
  "api": {
    "baseUrl": "https://api.example.com",
    "timeout": 5000
  }
}

3. Constantes nombradas

// constants.js
export const MAX_RETRY_ATTEMPTS = 3;
export const SESSION_TIMEOUT_MS = 30 * 60 * 1000; // 30 minutos

Términos relacionados

Refactoring - Proceso de mejorar código sin cambiar su comportamiento
Environment Variables - Variables configuradas fuera del código
Configuration Management - Gestión de configuración de aplicaciones

Recuerda: Si alguna vez piensas “esto nunca va a cambiar”, probablemente cambiará. Mejor usar configuración desde el inicio.

Pronunciación