Capítulo 4: Setup del entorno y coding standards
Capítulo 4: Setup del entorno y coding standards
Jueves. Es el día de ensuciarse las manos. Pero antes de escribir funcionalidades, el equipo necesita un entorno donde todos trabajen igual y un pipeline de integración continua que los proteja desde el minuto cero.
Anterior: Metaphor y arquitectura | Siguiente: Día 1: Primer pair programming
Coding standards: decisión colectiva
Carlos podría haber llegado con un documento de 50 páginas de convenciones. No lo hace. En XP, los coding standards se definen entre todos.
Carlos (TL): “Necesitamos acordar cómo escribimos código. No es mi estilo ni el de nadie: es el estilo del equipo.”
Diego (Dev): “¿Tabs o spaces?”
Carlos (TL): “Lo que decida el formateador automático. No vamos a pelear por eso nunca. Lo configuramos una vez y se acabó.”
Elena (Dev): “¿Y convenciones de nombres?”
Carlos (TL): “Usamos los estándares del lenguaje. Python tiene PEP 8, React tiene sus convenciones. No inventamos nada nuevo.”
El equipo acuerda cinco reglas simples:
- El formateador automático tiene la última palabra sobre estilo
- Los nombres siguen la metáfora del sistema: tablero, columna, tarjeta
- Cada archivo tiene una sola responsabilidad
- Los tests se nombran describiendo el comportamiento, no el método
- Si no entiendes un trozo de código, es demasiado complejo
Elena (Dev): “Me gusta la quinta. Es subjetiva pero poderosa.”
Carlos (TL): “Es intencional. Si tu pair no entiende lo que escribiste, lo simplificas. No hay excusa para código críptico.”
Pair programming para el setup
Carlos propone que configuren el entorno en parejas. Diego y Elena se sientan juntos frente a una máquina.
Diego (Dev): “¿Quién conduce?”
Carlos (TL): “Elena conduce, Diego navega. Elena maneja el teclado. Diego observa, piensa en el panorama general y sugiere. Cada 25 minutos rotan.”
Elena (Dev): “¿Por qué 25 minutos?”
Carlos (TL): “Es un pomodoro. Suficiente para hacer progreso, corto para que nadie se canse. Cuando suene el timer, Diego toma el teclado.”
Elena empieza a configurar el repositorio. Diego observa.
Diego (Dev): “¿No deberíamos crear la estructura de carpetas primero?”
Elena (Dev): “Tienes razón. Primero la estructura del hexágono: dominio en el centro, adaptadores afuera.”
Diego (Dev): “Y un lugar para los tests desde el principio.”
Carlos (TL): “Bien. Los tests no son ciudadanos de segunda clase. Tienen su lugar desde el día uno.”
CI desde el minuto cero
Mientras Diego y Elena configuran la estructura del proyecto, Carlos configura el pipeline de integración continua. No espera a que haya código productivo.
Ana (PO): “¿Ya están configurando CI? Si todavía no hay código…”
Carlos (TL): “Precisamente. Si configuramos CI cuando ya hay 50 archivos, va a ser doloroso. Si lo hacemos ahora, cada cosa que escribamos pasa por el pipeline automáticamente.”
Ana (PO): “¿Y qué hace el pipeline si no hay código?”
Carlos (TL): “Verifica que el proyecto se construye. Corre los tests, aunque todavía no haya ninguno. Verifica el formato. Si mañana Elena empuja código con un test roto, el pipeline se pone rojo y todos lo saben al instante.”
Carlos configura tres pasos en el pipeline: construir, formatear y testear. Lo mantiene simple.
Carlos (TL): “Kent Beck dice: ‘si duele, hazlo más seguido’. Integrar código duele cuando lo haces poco. Si integramos varias veces al día desde el principio, nunca se acumula dolor.”
El primer test que pasa
Diego toma el teclado después de los primeros 25 minutos. Escriben un test que verifica la cosa más simple posible: que pueden crear un tablero con un nombre.
Diego (Dev): “Es un test ridículo. Solo verifica que un tablero tiene nombre.”
Elena (Dev): “Y eso es perfecto. Verifica que nuestra estructura funciona, que los tests corren, que CI los ejecuta. Es un test de infraestructura tanto como de negocio.”
Carlos (TL): “Empujen al repositorio. Veamos si CI se pone verde.”
Esperan treinta segundos. El pipeline corre. Luz verde. El equipo celebra su primer éxito: un test que pasa en CI.
Ana (PO): “Parece poco para un día entero de trabajo.”
Carlos (TL): “Es la inversión más importante que haremos. A partir de mañana, todo lo que construyamos se verifica automáticamente. Si hubiéramos empezado a codificar features directamente, en una semana tendríamos un desastre sin tests y sin pipeline.”
El costo de no hacer setup primero
Elena comparte una experiencia de un proyecto anterior.
Elena (Dev): “En mi equipo anterior, empezamos a codificar el día uno. Tres semanas después intentamos agregar CI. Fue una pesadilla: tests que no corrían, dependencias que no se instalaban, formatos inconsistentes. Perdimos una semana entera arreglando lo que debimos hacer al principio.”
Diego (Dev): “¿Una semana?”
Elena (Dev): “Y eso fue solo para CI. Las convenciones de código nunca las alineamos del todo. Cada pull request tenía discusiones sobre estilo.”
Carlos (TL): “Eso es exactamente lo que evitamos hoy. Un día invertido ahora nos ahorra semanas de dolor después.”
Ana toma nota. Entiende que este día sin “features visibles” es la base sobre la que se construirá todo lo demás.
Práctica XP del capítulo
Coding Standards: Kent Beck enfatiza que los coding standards en XP no son impuestos por un arquitecto: se acuerdan entre todo el equipo. El objetivo no es homogeneizar el estilo personal de cada programador, sino eliminar fricciones innecesarias. Si todo el equipo formatea igual y nombra igual, el pair programming fluye sin roces y la propiedad colectiva del código se hace posible.
Continuous Integration: Configurar CI el primer día, antes de tener código productivo, es una práctica que paga dividendos desde la segunda línea de código. En XP, integrar no es un evento: es una actividad continua.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Observa, entiende el valor de la inversión en infraestructura |
| Carlos | Configura CI, facilita la decisión de coding standards |
| Diego | Navega y luego conduce en pair con Elena |
| Elena | Conduce y luego navega en pair con Diego |
Anterior: Metaphor y arquitectura | Siguiente: Día 1: Primer pair programming