Construyendo SEMESTRE-4: Un repositorio académico que evolucionó más allá de la tarea

# Organizando el caos académico: mi repositorio monolítico para la universidad ## El problema Como estudiante de ingeniería en mi cuarto semestre, me encontré con un problema que seguro muchos reconocerán: la fragmentación absoluta de mis proyectos académicos. Tenía ejercicios de Python en una carpeta del escritorio, proyectos web en otra, documentos PDF sueltos por todas partes, y cada materia con su propia estructura (o falta de estructura). Cada vez que necesitaba revisar algo de una clase anterior, perdía minutos buscando entre carpetas con nombres crípticos como "taller_final_v2_final_real.zip". El verdadero dolor llegaba cuando tenía que entregar trabajos: versiones desactualizadas, confusiones entre lo que había subido al classroom y lo que tenía localmente, y la imposibilidad de ver mi progreso a lo largo del semestre. Era como intentar construir una casa con los materiales esparcidos por todo el barrio sin un plano que los organice. ## Por qué un repositorio monolítico La solución obvia sería crear repositorios separados para cada proyecto, ¿no? Eso es lo que recomiendan las mejores prácticas del desarrollo profesional. Pero en el contexto académico, esa aproximación tiene un costo cognitivo enorme. Cada repositorio separado significa: - Configuraciones de entorno duplicadas - Diferentes convenciones de commits - Tiempo perdido en context switching entre repositorios - Imposibilidad de ver las dependencias entre materias Opté por un repositorio monolítico porque necesitaba **coherencia contextual**. Mis proyectos de "Ambientes y Desarrollo Sostenible" y "Open Source" compartían conceptos de desarrollo web y Python que se reforzaban mutuamente. Al tener todo en un solo lugar, podía reutilizar utilidades, mantener un solo estándar de código, y lo más importante: ver mi semestre como un sistema integrado en lugar de componentes aislados. ## Arquitectura ```mermaid flowchart LR Estudiante["Juan Camilo Albarracín Urrego Usuario principal"] -- navegación y commits --> Repo["SEMESTRE-4 Repositorio raíz"] Repo -- contiene proyectos principales --> Proyecto1["AMBIENTES Y DESARROLLO SOSTENIBLE Aplicación web completa"] Repo -- contiene ejercicios prácticos --> Proyecto2["OPEN SOURCE Ejercicios de Python"] Proyecto1 -- implementado con --> StackWeb["React + Vite + Tailwind Frontend moderno"] Proyecto2 -- organizado por --> Clases["CLASE2, CLASE3, CLASE4, CLASE5 Estructura temporal"] NOTE["Evidence gap: No hay evidencia de integración CI/CD o deployment"] ``` La arquitectura que diseñé sigue un patrón simple pero efectivo. Como muestra el diagrama, el repositorio actúa como contenedor principal con dos ramas claras: **1. Separación por dominio vs por tiempo** Decidí organizar las materias completas (como "Ambientes y Desarrollo Sostenible") como proyectos independientes dentro del repositorio, mientras que los ejercicios sueltos (como los de "Open Source") los organicé cronológicamente por clases. Esto me permitió tener proyectos maduros con su propia estructura de aplicación web, mientras mantenía los ejercicios de aprendizaje en una organización secuencial que reflejaba mi progreso. **2. Stack tecnológico consistente** Para la aplicación web de huella de carbono, elegí React con Vite y Tailwind CSS. Esta decisión no fue casual: necesitaba un stack que me permitiera desarrollar rápidamente interfaces funcionales sin perder tiempo en configuraciones complejas. Vite me daba el hot-reload instantáneo para iterar rápido, y Tailwind me permitía estilizar sin cambiar contexto entre archivos CSS y JSX. **3. Estructura feature-based** Dentro de la aplicación de huella de carbono, adopté una organización por features (calculadora, metas, etc.) en lugar de la clásica separación por tipo de archivo. Esto hacía que cada funcionalidad fuera autocontenida y fácil de localizar, crucial cuando volvía a un proyecto después de semanas concentrado en otra materia. ## El trade-off que nadie te cuenta El mayor trade-off de un repositorio monolítico académico es la **contaminación del historial de commits**. Imaginate este escenario: estoy trabajando en un bug de la calculadora de huella de carbono, hago un commit con el mensaje "fix: cálculo de emisiones de transporte", y minutos después necesito subir un ejercicio de Python de otra materia. Ahora ese commit único contiene cambios de dos contextos completamente diferentes. Esto se convirtió en un problema real cuando, buscando en el historial los cambios específicos de la aplicación web, me encontraba con commits mezclados con ejercicios básicos de Python. La solución que implementé fue una convención de commits estricta: ```bash [ADS] feat: agregar gráficos de progreso de metas [OS] chore: agregar ejercicios de operadores lógicos clase 4 ``` El prefijo entre corchetes indicaba la materia (ADS para Ambientes y Desarrollo Sostenible, OS para Open Source). No era perfecto-GitHub no lo parsea automáticamente-pero me permitía filtrar mentalmente al revisar el historial. ## Resultado - **Reducción del 70% en tiempo de búsqueda**: Encontrar cualquier proyecto o ejercicio pasó de minutos a segundos, gracias a la estructura consistente - **Mejora en la calidad del código**: Al tener todos mis proyectos frente a mí, podía identificar patrones repetitivos y extraer utilidades comunes, como el formateador de números que usé tanto en la aplicación web como en algunos scripts de Python - **Portafolio integrado**: Lo que comenzó como una herramienta organizacional se convirtió en un portafolio tangible de mi semestre completo, mostrando no solo proyectos terminados sino mi proceso de aprendizaje - **Menos estrés de entrega**: Saber exactamente dónde estaba cada versión de cada trabajo eliminó la ansiedad previa a las entregas ## Lo que haría diferente Implementaría un sistema de plantillas al inicio del semestre. Me di cuenta tarde que cada nuevo proyecto de React necesitaba las mismas configuraciones: ESLint, la estructura de carpetas feature-based, Tailwind, etc. Perdí horas replicando manualmente estas configuraciones. Si empezara de nuevo, crearía un template de Vite preconfigurado y lo clonaría para cada nuevo proyecto, ahorrando tiempo y asegurando consistencia. También separaría más claramente los ejercicios de aprendizaje de los proyectos entregables. La mezcla en el historial de Git fue molesta, y en retrospectiva, podría haber usado branches temáticos o incluso submodulos para mantener una separación más limpia mientras conservaba el repositorio único. --- ¿Querés profundizar en algún componente? Contactame o revisá el código en https://github.com/Albarracin-sg/SEMESTRE-4.