Cambiar una gran base de código .NET manteniéndola rápida y compatible

## Poner primero la velocidad de las rutas críticas y la compatibilidad en cada cambio Trata el repositorio como infraestructura crítica para el rendimiento cuyo comportamiento puede afectar a muchas compilaciones posteriores. - Haz que la eficiencia en tiempo de ejecución sea la principal prioridad de ingeniería en las rutas críticas. Minimiza las asignaciones, evita la sobrecarga de abstracción innecesaria y elige algoritmos que sigan siendo eficientes a escala. - Conserva la compatibilidad salvo que un cambio sea expresamente voluntario. Una nueva advertencia, error o modificación de comportamiento puede interrumpir a los consumidores cuando las advertencias se tratan como errores. - Mantén el cambio enfocado. Respeta la arquitectura y el estilo circundantes, pero utiliza las capacidades actuales del lenguaje cuando una cantidad considerable de código nuevo justifique la modernización. - No introduzcas advertencias del compilador ni del analizador. Supón que las compilaciones oficiales tratan cada advertencia como un error. - Prefiere las pruebas obtenidas de la propia compilación del repositorio, la salida de bootstrap, los ejemplos y las pruebas automatizadas frente a las suposiciones. ## Escribir C# con el estilo del repositorio y con menos asignaciones al analizar texto Aplica el formateador del repositorio y `.editorconfig` antes de inventar reglas de estilo locales. - Prefiere la sintaxis actual de C# compatible con el SDK fijado, incluidas las expresiones de colección cuando mejoren la claridad. - Usa espacios de nombres con ámbito de archivo y directivas `using` compactas cuando sean coherentes con la base de código. - Sigue el estilo de llaves del repositorio y usa `nameof` para hacer referencia a miembros. - Usa coincidencia de patrones y expresiones switch cuando aclaren las condiciones sin añadir sobrecarga. - En análisis sensibles a las asignaciones, prefiere `Span<T>`, `ReadOnlySpan<T>`, segmentación y API `TryParse` basadas en span. - Usa operaciones de caracteres invariantes para normalizar caracteres individuales y el comparador de dominio del repositorio para identificadores del dominio. Usa comparación ordinal para identificadores ordinarios que no pertenezcan al dominio. - Considera la inserción agresiva en línea solo para funciones auxiliares pequeñas, medidas y situadas en rutas críticas. Gestiona los tipos de referencia que aceptan valores nulos según el modo establecido en el archivo: - Los archivos nuevos usan tipos de referencia que aceptan valores nulos y no deben desactivar su análisis. - Los archivos que desactivan expresamente el análisis de valores nulos conservan ese estilo; no añadas anotaciones aisladas de nulabilidad. - Los archivos con análisis de valores nulos activado usan anotaciones precisas y tratamiento explícito de valores nulos. - Prefiere comprobaciones de valores nulos basadas en patrones, como `is null` e `is not null`. Elige colecciones inmutables según el patrón de actualización. Usa colecciones inmutables compactas respaldadas por matrices o búsquedas congeladas para datos construidos una vez y leídos muchas veces. Usa listas o diccionarios inmutables persistentes solo cuando las actualizaciones incrementales sean un requisito real. No uses canalizaciones de consultas en rutas críticas cuando un bucle directo evite asignaciones. ## Revisar los cambios por su costo en rutas críticas y por advertencias nuevas Revisa los cambios como si fueran a ejecutarse dentro de un motor de compilación de uso generalizado. 1. Identifica la frecuencia de ejecución y el volumen de datos de cada ruta modificada. 2. Señala asignaciones innecesarias, enumeraciones repetidas, operadores de consulta, creación evitable de cadenas y estructuras de búsqueda ineficientes en las rutas críticas. 3. Comprueba que el análisis use spans cuando sea práctico y que la semántica de comparación coincida con el dominio. 4. Confirma que los tipos de colección se ajusten a su patrón de construcción y acceso. 5. Busca nuevos diagnósticos, valores predeterminados modificados, evaluación reordenada, comportamiento alterado de comandos u otras diferencias visibles externamente. 6. Trata cualquier advertencia o error nuevo en el comportamiento existente como un cambio incompatible, aunque el diagnóstico parezca útil. 7. Permite diagnósticos más estrictos en comportamientos nuevos y voluntarios, en los que los usuarios seleccionen intencionadamente el nuevo contrato. Inspecciona con cuidado los cambios en la configuración de orígenes de paquetes. Los nuevos orígenes externos requieren una justificación expresa, y deben preferirse los orígenes internos aprobados cuando el repositorio los defina. No cambies archivos de SDK fijado, orígenes de paquetes, propiedades de compilación compartidas ni versiones centralizadas de paquetes salvo que el trabajo solicitado lo requiera. Nunca edites la salida de compilación generada ni el directorio del SDK local gestionado por el repositorio. Actualiza la documentación técnica cercana cuando cambien el comportamiento, las API públicas, los comandos o las instrucciones de solución de problemas. ## Compilar primero el proyecto más pequeño y corregir los primeros errores Comienza con la compilación más pequeña que pueda demostrar el componente modificado y amplía el alcance solo cuando lo exija el contrato de finalización del repositorio. - Compila un proyecto individual con el comando silencioso estándar del repositorio cuando el cambio esté localizado. - Usa el script de compilación de todo el repositorio correspondiente a la plataforma para la verificación de integración. Respeta el tiempo de espera documentado; no canceles una compilación que se sabe que tarda mucho solo porque no produzca salida. - No canalices la salida de compilación a un archivo. Cuando necesites una lista persistente de errores, usa la opción nativa de registro en archivo del sistema de compilación para conservar la fiabilidad del comportamiento de consola y del estado de salida. - Al revisar un subconjunto de fallos de compilación, empieza por los primeros errores. Los fallos posteriores suelen ser consecuencias. - Si la compilación no puede resolver el SDK fijado, activa el entorno de bootstrap del repositorio y comprueba que esté activa la versión de SDK esperada. - Tras una compilación correcta de todo el repositorio, usa el ejecutable o entorno de bootstrap generado para la validación posterior. - Usa proyectos de ejemplo del repositorio, no proyectos externos no relacionados, para las comprobaciones de extremo a extremo. Conserva los artefactos de compilación en el directorio de artefactos definido por el repositorio. No edites manualmente archivos generados para aparentar que una compilación fue correcta. ## Probar el cambio y ejecutar el comando recién compilado antes de terminar Usa una secuencia de verificación que demuestre tanto el comportamiento modificado como el motor de compilación producido por el repositorio. 1. Ejecuta el proyecto de pruebas unitarias pertinente y, cuando resulte útil, un filtro de prueba centrado en el escenario modificado. 2. Ejecuta el conjunto completo de pruebas solo cuando lo exijan el contrato del repositorio o el alcance del cambio. Respeta las duraciones documentadas y nunca canceles antes de tiempo un conjunto de larga duración que siga funcionando correctamente. 3. Compila un ejemplo representativo del repositorio mediante el entorno de bootstrap. 4. Invoca el punto de entrada de línea de comandos recién compilado con un comando inofensivo, como mostrar la ayuda. 5. Confirma que la compilación completa terminó sin advertencias ni errores. 6. Vuelve a leer la diferencia para detectar modificaciones en archivos generados, cambios de configuración no solicitados, riesgos de compatibilidad y documentación ausente. La finalización exige pruebas, no solo una compilación correcta. Registra qué compilación, pruebas enfocadas, ejemplo y comprobación del ejecutable se realizaron, e indica claramente cualquier verificación que no pudiera efectuarse. No afirmes que se completó una validación integral cuando solo se terminó una comprobación a nivel de componente.