Alterar uma grande base de código .NET mantendo-a rápida e compatível

## Colocar a velocidade dos caminhos críticos e a compatibilidade em primeiro lugar Trate o repositório como infraestrutura crítica para desempenho cujo comportamento pode afetar muitas compilações posteriores. - Faça da eficiência em tempo de execução a principal prioridade de engenharia nos caminhos críticos. Minimize alocações, evite sobrecarga de abstração desnecessária e escolha algoritmos que continuem eficientes em grande escala. - Preserve a compatibilidade, a menos que uma alteração seja explicitamente opcional. Um novo aviso, erro ou mudança de comportamento pode interromper consumidores quando avisos são tratados como erros. - Mantenha a alteração focada. Siga a arquitetura e o estilo próximos, mas use recursos atuais da linguagem quando uma quantidade substancial de código novo justificar a modernização. - Não introduza avisos do compilador nem do analisador. Presuma que as compilações oficiais tratam cada aviso como erro. - Prefira evidências da própria compilação do repositório, da saída de bootstrap, dos exemplos e dos testes, em vez de suposições. ## Escrever C# no estilo do repositório e com menos alocações ao analisar texto Aplique o formatador do repositório e o `.editorconfig` antes de inventar regras locais de estilo. - Prefira a sintaxe C# atual aceita pelo SDK fixado, incluindo expressões de coleção quando elas melhorarem a clareza. - Use namespaces com escopo de arquivo e diretivas `using` compactas quando forem coerentes com a base de código. - Siga o estilo de chaves do repositório e use `nameof` ao fazer referência a membros. - Use correspondência de padrões e expressões switch quando elas tornarem as condições mais claras sem adicionar sobrecarga. - Em análises sensíveis a alocações, prefira `Span<T>`, `ReadOnlySpan<T>`, fatiamento e APIs `TryParse` baseadas em span. - Use operações de caracteres invariantes para normalizar caracteres individuais e o comparador de domínio do repositório para identificadores do domínio. Use comparação ordinal para identificadores comuns fora do domínio. - Considere inlining agressivo somente para funções auxiliares pequenas, medidas e localizadas em caminhos críticos. Trate tipos de referência anuláveis de acordo com o modo estabelecido no arquivo: - Arquivos novos usam tipos de referência anuláveis e não devem desativar a análise de nulabilidade. - Arquivos que desativam explicitamente a análise de nulabilidade mantêm esse estilo; não adicione anotações anuláveis isoladas. - Arquivos com análise de nulabilidade ativa usam anotações precisas e tratamento explícito de valores nulos. - Prefira verificações de nulo baseadas em padrões, como `is null` e `is not null`. Escolha coleções imutáveis pelo padrão de atualização. Use coleções imutáveis compactas apoiadas por arrays ou estruturas de busca congeladas para dados construídos uma vez e lidos muitas vezes. Use listas ou dicionários imutáveis persistentes somente quando atualizações incrementais forem realmente necessárias. Não use pipelines de consulta em caminhos críticos quando um loop direto evitar alocações. ## Revisar mudanças pelo custo nos caminhos críticos e por avisos novos Revise as alterações como se elas fossem executadas dentro de um mecanismo de compilação amplamente utilizado. 1. Identifique a frequência de execução e o volume de dados de cada caminho alterado. 2. Sinalize alocações desnecessárias, enumeração repetida, operadores de consulta, criação evitável de strings e estruturas de busca ineficientes nos caminhos críticos. 3. Verifique se a análise usa spans quando viável e se a semântica de comparação corresponde ao domínio. 4. Confirme que os tipos de coleção sejam adequados ao padrão de construção e acesso. 5. Procure novos diagnósticos, padrões alterados, avaliação reordenada, comportamento de comandos modificado ou outras diferenças observáveis externamente. 6. Trate qualquer novo aviso ou erro no comportamento existente como uma alteração incompatível, mesmo que o diagnóstico pareça útil. 7. Permita diagnósticos mais rigorosos em novos comportamentos opcionais nos quais os usuários escolham deliberadamente o novo contrato. Inspecione com cuidado as alterações na configuração de origens de pacotes. Novas origens externas exigem justificativa explícita, e origens internas aprovadas devem ser preferidas quando o repositório as definir. Não altere arquivos de SDK fixado, origens de pacotes, propriedades de compilação compartilhadas nem versões de pacotes gerenciadas centralmente, a menos que o trabalho solicitado exija isso. Nunca edite a saída de compilação gerada nem o diretório do SDK local gerenciado pelo repositório. Atualize a documentação técnica relacionada quando o comportamento, as APIs públicas, os comandos ou as orientações de solução de problemas mudarem. ## Compilar primeiro o menor projeto e corrigir os primeiros erros Comece com a menor compilação capaz de comprovar o componente alterado e amplie o escopo somente conforme exigido pelo contrato de conclusão do repositório. - Compile um projeto individual com o comando silencioso padrão do repositório quando a alteração for localizada. - Use o script de compilação do repositório inteiro específico da plataforma para a verificação de integração. Respeite o tempo limite documentado; não cancele uma compilação reconhecidamente longa apenas porque ela está silenciosa. - Não direcione a saída de compilação por pipe para um arquivo. Quando for necessária uma lista persistente de erros, use a opção nativa de registro em arquivo do sistema de compilação para manter confiáveis o comportamento do console e o status de saída. - Ao revisar um subconjunto de falhas de compilação, comece pelos primeiros erros. Falhas posteriores costumam ser consequências. - Se a compilação não conseguir resolver o SDK fixado, ative o ambiente de bootstrap do repositório e verifique se a versão esperada do SDK está ativa. - Após uma compilação bem-sucedida de todo o repositório, use o executável ou ambiente de bootstrap gerado para a validação posterior. - Use projetos de exemplo do repositório, em vez de projetos externos não relacionados, para verificações de ponta a ponta. Mantenha os artefatos de compilação no diretório de artefatos definido pelo repositório. Não edite manualmente arquivos gerados para fazer uma compilação parecer bem-sucedida. ## Testar a mudança e executar o comando recém-compilado antes de concluir Use uma sequência de verificação que comprove tanto o comportamento alterado quanto o mecanismo de compilação produzido pelo repositório. 1. Execute o projeto de testes unitários relevante e, quando útil, um filtro de teste voltado ao cenário alterado. 2. Execute a suíte de testes completa somente quando o contrato do repositório ou o escopo da alteração exigir. Respeite os tempos de execução documentados e nunca cancele antecipadamente uma suíte longa que continue funcionando normalmente. 3. Compile um exemplo representativo do repositório pelo ambiente de bootstrap. 4. Invoque o ponto de entrada de linha de comando recém-compilado com um comando inofensivo, como a exibição de ajuda. 5. Confirme que a compilação completa terminou sem avisos nem erros. 6. Releia a diferença para identificar edições em arquivos gerados, alterações de configuração não solicitadas, riscos de compatibilidade e documentação ausente. A conclusão exige evidências, não apenas uma compilação bem-sucedida. Registre qual compilação, testes focados, exemplo e verificação do executável foram realizados e declare claramente qualquer validação que não pôde ser executada. Não afirme que houve validação completa quando apenas uma verificação no nível do componente foi concluída.