Cambiar código en un repositorio grande de varios lenguajes compilando y probando solo lo necesario

## Investigar y planear, y luego hacer y probar el cambio más pequeño Utilice una secuencia repetible para cada cambio: 1. Investigue la solicitud, el código pertinente, las interfaces de las dependencias, las pruebas existentes y los modos de fallo conocidos. 2. Formule un plan de implementación de alto nivel y cuestione sus supuestos, casos límite y riesgos operativos. 3. Inspeccione código similar para conocer la organización, la nomenclatura, la gestión de errores y los patrones de prueba del repositorio. 4. Presente el plan solo cuando el usuario lo solicite; de lo contrario, continúe con la implementación. 5. Implemente el cambio coherente más pequeño que satisfaga la solicitud. 6. Revise el resultado para comprobar la corrección de las API, la claridad, el rendimiento, la legibilidad y cualquier ampliación involuntaria del alcance. 7. Ejecute el formateo, compilaciones específicas y las pruebas pertinentes; después, repita el ciclo ante los fallos. No considere que terminar el borrador equivale a completar la tarea. Un cambio solo está listo después de revisar y validar tanto la implementación como el comportamiento directamente afectado. ## Antes de editar, seguir el patrón del código parecido más cercano Lea las directrices de contribución del repositorio y todas las instrucciones específicas de las rutas que rigen los archivos que se modificarán. Busque el ejemplo funcional más cercano, como una clase hermana, un paquete adyacente, una prueba similar o un flujo de trabajo relacionado, y siga su estructura establecida salvo que la tarea exija una desviación deliberada. Verifique las API de las dependencias y los casos límite mediante interfaces autorizadas o usos existentes. Localice las pruebas actuales antes de crear otras nuevas e integre la nueva cobertura en los marcos existentes del repositorio, en lugar de inventar una infraestructura paralela. Mantenga la investigación centrada en el comportamiento solicitado. No combine el cambio con modificaciones de nombres, movimientos de directorios, cambios masivos de formato o limpiezas arquitectónicas que no estén relacionados. ## Antes de probar, comprobar qué herramientas y hardware hay Antes de elegir comandos, determine qué compiladores, entornos de ejecución, herramientas de compilación, contenedores, aceleradores y credenciales están realmente disponibles. Distinga entre una capacidad no disponible y un fallo del producto: la ausencia de un dispositivo, un entorno de contenedores no compatible o una cadena de herramientas inexistente no demuestra que el código sea defectuoso. Utilice el contenedor o entorno de desarrollo estándar del repositorio cuando sea compatible y necesario para la reproducibilidad. De lo contrario, ejecute todas las comprobaciones significativas disponibles en el entorno actual e identifique el comando restante más pequeño que requiera otra máquina o la intervención del usuario. Nunca afirme que una prueba no disponible ha sido superada. Informe de la limitación exacta, de la validación completada sin ella y del riesgo residual. ## Compilar y probar solo las partes que afecta el cambio Prefiera los preajustes y scripts auxiliares proporcionados por el repositorio a las secuencias de comandos construidas manualmente. Averigüe cuáles son los preajustes compatibles, seleccione el que corresponda al componente modificado y al nivel del lenguaje, y limítese a los objetivos de compilación, pruebas unitarias, pruebas de integración o comprobaciones del compilador pertinentes. Utilice la información de dependencias para incluir los componentes posteriores afectados por un cambio compartido o de alta dependencia. En un cambio local, evite recompilar paquetes no relacionados. Reserve las compilaciones y suites de pruebas completas para cambios transversales, puertas de publicación o políticas del repositorio que las exijan explícitamente. Registre por qué el alcance seleccionado es suficiente. Una comprobación limitada solo aporta valor cuando está clara su relación con el cambio. ## Probar cada lenguaje y arquitectura de hardware a su manera Trate cada lenguaje o capa de paquetes de acuerdo con su propia interfaz. Las bibliotecas nativas pueden requerir ajustes de compilador, estándar del lenguaje y arquitectura, mientras que los paquetes de lenguajes interpretados pueden necesitar versiones del entorno de ejecución, dependencias adicionales y puntos de entrada de pruebas específicos del paquete. No transfiera los parámetros de un ecosistema a otro. En el código sensible a la arquitectura, distinga entre comprobaciones que solo utilizan el sistema anfitrión, comprobaciones únicamente de compilación, simuladores u objetivos virtuales y pruebas que requieren hardware físico. Seleccione arquitecturas representativas según el comportamiento modificado y el intervalo de compatibilidad admitido, en lugar de compilar todas las variantes de forma predeterminada. Cuando cambie un componente compartido, inspeccione el grafo de dependencias y valide los consumidores con mayor probabilidad de revelar regresiones de compatibilidad. ## Hacer primero las comprobaciones baratas y no cortar antes de tiempo las compilaciones lentas Suponga que las compilaciones grandes, las matrices de pruebas generadas y las suites respaldadas por hardware pueden tardar bastante. Establezca tiempos de espera realistas, utilice las cachés admitidas, limite las arquitecturas y los objetivos durante la iteración y amplíe la cobertura solo cuando el riesgo o la fase de publicación justifiquen el coste. Una duración prolongada no demuestra por sí sola que haya un bloqueo. No cancele una compilación o prueba en curso únicamente porque sea lenta; deténgala solo cuando exista una prueba concreta de fallo, un límite operativo explícito o una instrucción del usuario. Organice la validación por etapas para recibir primero la información menos costosa: formateo y comprobaciones estáticas, compilación específica, pruebas ejecutables en el sistema anfitrión y, por último, suites especializadas o dependientes del hardware. Mantenga la cobertura final requerida aunque las primeras iteraciones utilicen un subconjunto menor. ## Reducir la CI mientras se itera, pero ejecutarla completa antes de fusionar Utilice la detección de cambios y las matrices de trabajos para ejecutar las tareas pertinentes a los componentes afectados. Las matrices de sustitución temporal o los controles de omisión pueden reducir el coste durante las primeras iteraciones, especialmente en cambios de infraestructura o áreas con muchas dependencias, pero deben permanecer visibles y auditables. Trate la cobertura reducida de CI como una condición que bloquea la fusión. Antes de fusionar, restaure la configuración completa requerida por el repositorio y obtenga una ejecución correcta sin sustituciones temporales ni controles de omisión. No retire la sustitución de otro colaborador ni cambie su alcance sin una instrucción explícita. Mantenga la configuración de sustitución estructuralmente válida cuando el flujo de trabajo espere un valor vacío en lugar de su eliminación. Confirme que la agregación de resultados se cierre de forma segura con un fallo cuando fallen los trabajos obligatorios o siga activa la cobertura reducida. ## Pasar formateador y linter, e informar de las comprobaciones no ejecutadas Antes de confirmar los cambios, ejecute el formateador, el linter y las comprobaciones pre-commit del repositorio sobre los archivos modificados. Aplique primero las directrices de estilo comunes y, después, las reglas específicas del lenguaje, el directorio o las pruebas que determinen las rutas afectadas. Revise la diferencia final para detectar archivos accidentales, artefactos generados, nombres incoherentes, comentarios obsoletos y pruebas ausentes. Vuelva a ejecutar la validación específica después de la última edición para que las pruebas notificadas coincidan con el contenido entregado. Informe con precisión de las comprobaciones realizadas, sus resultados, las comprobaciones no ejecutadas, el motivo por el que no estaban disponibles y el riesgo residual resultante. Nunca describa un cambio como completamente validado si faltaron el hardware, las herramientas, los permisos o la cobertura de CI requeridos.