Altere um mecanismo de armazenamento de banco de dados sem perder velocidade nem compatibilidade

## Escreva código legível que trate bem os erros e a concorrência Escreva código claro e autoexplicativo, com nomes significativos e comentários para invariantes que não sejam óbvias. Prefira um fluxo de controle legível a truques engenhosos que ofereçam apenas um ganho marginal de velocidade. Siga o formatador, as regras de nomenclatura e os padrões estruturais do repositório. Use de forma consistente o tipo padrão de estado ou de erro do projeto. Propague falhas com contexto suficiente para identificar a operação que falhou. Nunca descarte silenciosamente um erro nem um valor de estado que não tenha sido verificado. Evite asserções para falhas recuperáveis em caminhos de produção. Cubra entradas inválidas, esgotamento de recursos, falhas de E/S, corrupção e progresso parcial. Preserve a semântica do banco de dados, como a ordenação de chaves, a visibilidade de instantâneos, a durabilidade e o comportamento de recuperação. Documente as premissas de sincronização junto aos dados que elas protegem. Revise em conjunto bloqueios, operações atômicas, ordenação de memória e riscos de condição de corrida e de impasse. Mantenha explícita a liberação de recursos nos caminhos de sucesso, erro, cancelamento e encerramento. Mantenha os comentários voltados aos contratos locais, não à justificativa atual de um chamador específico. Elimine a lógica duplicada quando uma abstração compartilhada tiver uma responsabilidade estável e coerente. Não classifique como pronta para integração uma alteração sensível à correção antes de testar os caminhos de falha e o comportamento concorrente. ## Acelere o código conforme a frequência de execução e comprove com testes comparativos Trate a atenção ao desempenho como um requisito do trabalho com mecanismos de armazenamento. Estabeleça a correção antes de fazer micro-otimizações, mas escolha algoritmos e estruturas de dados sólidos desde o início. Classifique o código afetado pela frequência de execução: - Em caminhos quentes, cada alocação, cópia, desvio e falha de cache se multiplica ao longo de operações frequentes. - Caminhos mornos exigem um equilíbrio medido entre clareza e velocidade. - Caminhos frios favorecem a facilidade de manutenção, a menos que a análise de desempenho revele um custo relevante. Fundamente as afirmações sobre desempenho com testes comparativos e dados de análise de desempenho. Compare com uma referência adequada e informe a carga de trabalho, a configuração e a variância. Quando houver justificativa, reduza a alocação dinâmica em caminhos quentes por meio de reutilização, pré-alocação, regiões de alocação ou conjuntos de memória. Prefira operações de movimentação, visualizações, referências e operações no próprio local a cópias desnecessárias. Organize os dados e os padrões de acesso para favorecer a localidade e evitar o falso compartilhamento. Mova o trabalho invariável para fora dos laços, agrupe operações repetidas e reduza desvios imprevisíveis. Use indicações de probabilidade de desvio somente em casos realmente raros ou caros, não em configurações comuns. Habilite a vetorização do compilador por meio de uma disposição de dados adequada antes de recorrer a funções intrínsecas explícitas. Use SIMD explícito apenas onde houver suporte, medição e condições de manutenção. Aplique RAII e uma propriedade clara para impedir vazamentos enquanto mantém a sobrecarga baixa. Não mantenha uma otimização complexa que não tenha benefício reproduzível. ## Projete API compatíveis com opções de um único propósito Mantenha a política de alto nível no chamador ou na camada de políticas. Exponha mecanismos precisos e reutilizáveis nas camadas inferiores. Não faça o código genérico depender da identidade ou da justificativa de um único chamador. Dê a cada sinalizador ou parâmetro um único comportamento coerente. Substitua valores booleanos que agrupem propriedade, cache, modo de E/S e pré-busca por campos explícitos ou um objeto de opções. Não deduza políticas de detalhes incidentais da implementação, como identificadores de cache ou o estado do leitor. Use asserções, interfaces mais restritas e nomes mais claros para tornar os contratos aplicáveis. Faça com que as novas API sejam coerentes com a nomenclatura, a ordem de parâmetros, os tipos de retorno e o tratamento de erros existentes. Use opções com segurança de tipos, incluindo tipos inteiros de largura fixa e enumerações com escopo quando adequado. Valide os valores das opções e retorne erros claros. Faça com que as alterações dinâmicas de configuração sejam seguras entre threads e verifique quando entram em vigor. Preserve a compatibilidade do código-fonte e dos binários, a menos que uma alteração incompatível tenha uma justificativa excepcional. Revise a disposição, os símbolos e as convenções de chamada quando uma interface binária pública for exposta. Marque elementos como obsoletos pelo processo documentado de várias versões e forneça orientações de migração. Documente as API públicas com uso, significado dos parâmetros, regras de segurança entre threads, custos de desempenho e observações de compatibilidade. Não exporte tipos de implementação de terceiros por uma API pública. ## Revise a fundo o registro antecipado de gravação e outras partes de alto risco Aplique a revisão mais profunda ao registro antecipado de gravação, às tabelas em memória, à compactação, à recuperação e a outros caminhos centrais do banco de dados. Teste alterações centrais sob diversas configurações, estilos de compactação, falhas e cargas de trabalho concorrentes. Garanta que a compactação respeite os limites configurados e trate os casos sem arquivos ou com apenas um arquivo. Trate os cabeçalhos públicos como a superfície de maior impacto sobre a compatibilidade. Trate os formatos persistentes de tabelas e blocos como contratos de dados de longa duração. Verifique as somas de verificação entre opções de compressão, tamanhos de bloco, casos de corrupção e limites de compatibilidade. Teste as operações de busca, avanço, recuo e exclusão do iterador, além da semântica dos pontos extremos. Mantenha as chaves de cache únicas e garanta que a pré-busca respeite os limites de recursos. Faça testes comparativos de alterações em tabelas, caches e utilitários que possam ser executadas em caminhos quentes. Explicite a sincronização do cache, a propriedade da memória e a política de expulsão. Mantenha utilitários opcionais isolados dos componentes internos do banco de dados. Para opções, verifique a segurança de tipos, a validação, a obsolescência e as atualizações dinâmicas seguras entre threads. Para utilitários internos, teste estouro superior, estouro inferior, entradas inválidas e contratos de asserção. Não aprove alterações de alto risco em formatos, recuperação, compactação ou cache sem evidências de testes unitários, de integração, de estresse e comparativos. ## Sincronize todos os sistemas de compilação e compile em cada plataforma suportada Mantenha todos os sistemas de compilação compatíveis ao adicionar ou retirar um arquivo-fonte. Atualize primeiro o manifesto canônico de fontes e gere novamente os arquivos de compilação derivados com o gerador aprovado. Não edite manualmente um arquivo interno de compilação gerado. Procure referências afetadas em todas as definições de compilação, linguagens, documentações e implementações. Use a quantidade de CPUs do host para compilações paralelas dentro dos limites de recursos. Impeça que modos de compilação mistos reutilizem arquivos-objeto incompatíveis. Em compilações manuais, habilite o mecanismo do sistema de compilação que realiza uma limpeza automática quando a configuração muda. Ofereça suporte à matriz de sistemas operacionais, compiladores, bibliotecas padrão, sanitizadores e modos de compilação do projeto. Quando configurados, considere Linux, macOS, Windows, compiladores nativos e cruzados, compilações de lançamento, sanitizadores, compilações unificadas e vínculos de linguagens. Prefira as abstrações de portabilidade do projeto às API diretas de cada plataforma. Proteja com condições os cabeçalhos, as chamadas, os atributos e as funções integradas inevitavelmente específicos de cada plataforma. Inclua diretamente todos os cabeçalhos padrão em vez de depender de inclusões transitivas. Garanta que os binários de produção e de estresse sejam compilados sem informações de tipos em tempo de execução quando isso for uma restrição do projeto. Restrinja as conversões descendentes em tempo de execução aos testes; nos demais locais, use o auxiliar de conversão estática verificada do projeto. Execute verificações do código-fonte que rejeitem caracteres sem suporte e outros conteúdos incompatíveis com a integração contínua. Use pontuação ASCII em comentários e cadeias do código-fonte quando o repositório exigir. ## Escreva testes reproduzíveis sem depender de esperas fixas Ajuste a profundidade dos testes ao risco: testes unitários para comportamentos isolados, testes de integração para interações e testes de estresse para concorrência e desempenho. Cubra limites, caminhos de erro, recuperação, diferenças entre plataformas e casos de regressão. Use casos orientados por tabelas quando as entradas forem diferentes, mas o contrato testado for o mesmo. Extraia funções auxiliares para construções repetidas, conversões de ida e volta e sequências de asserções. Mantenha os casos extremos determinísticos separados da cobertura aleatória. Prefira a amostragem aleatória aos produtos exaustivos de parâmetros quando ela proporcionar uma cobertura útil mais ampla. Use a fonte de aleatoriedade do projeto e exiba a semente para que as falhas possam ser reproduzidas. Não coloque o processo em espera enquanto aguarda eventos concorrentes. Use pontos de sincronização ou sinais explícitos para controlar o avanço das threads. Limite a execução de cada teste unitário com um tempo limite definido. Execute em série uma pequena quantidade de testes específicos e os conjuntos maiores pelo sistema de testes paralelos. Submeta repetidamente os novos testes de concorrência a estresse sob trocas de contexto forçadas. Investigue falhas intermitentes que ocorrem apenas na integração contínua com as ferramentas específicas de reprodução do projeto. Teste todas as plataformas compatíveis afetadas por caminhos, API, compiladores ou sinalizadores de compilação. Garanta que as falhas dos testes informem estado suficiente para reproduzir a configuração que as desencadeou. Inclua novas opções de configuração e recursos de desempenho na cobertura de testes de estresse e comparativos. Antes do envio, revise os testes atualizados para detectar duplicação e estado compartilhado acidental. ## Adicione cabeçalhos de licença e sincronize a documentação e as notas de versão Adicione a cada novo arquivo-fonte o cabeçalho de licença exigido pelo repositório. Preserve nos arquivos derivados os avisos de direitos autorais da origem, além do cabeçalho do projeto. Use o prefixo de comentário correto para cada linguagem de código-fonte. Não substitua uma designação obrigatória de licença dupla por uma declaração genérica de direitos. Execute a formatação automática após as alterações e inspecione as diferenças resultantes. Execute as ferramentas de manutenção de dependências e rejeite alterações não relacionadas no manifesto. Ao adicionar um recurso, avalie métricas úteis sem introduzir regressão nos caminhos quentes. Exponha recursos relacionados ao desempenho pela ferramenta padrão de testes comparativos. Mantenha as notas de lançamento curtas, voltadas ao público externo e concentradas no comportamento visível ao usuário. Documente os projetos dos componentes no índice do subsistema e em capítulos específicos. Quando necessário, garanta que os sites ou as publicações gerados façam referência a metadados de autor válidos. Para uma nova API, opção ou marcação como obsoleta, siga o procedimento específico do repositório. Atualize as orientações de migração antes de retirar uma superfície obsoleta. Mantenha sincronizados a implementação, os metadados de compilação, os testes, a documentação e as notas de lançamento. Não deixe um novo arquivo-fonte acessível por um sistema de compilação e ausente de outro. ## Passe por uma compilação limpa e pelos testes antes de aprovar uma alteração Revise correção, testes, desempenho, compatibilidade, limites contratuais, estilo e documentação como critérios independentes. Exija resultados de testes comparativos para alterações sensíveis ao desempenho. Exija cobertura de estresse para novos comportamentos concorrentes ou configuráveis. Execute o objetivo completo de compilação limpa e testes após a aprovação das verificações específicas. Execute a compilação mais rigorosa de verificação de estado que detecta resultados de erro ignorados. Use o modo de limpeza automática para que os sinalizadores de compilação alterados não possam reutilizar arquivos-objeto obsoletos. Monitore execuções longas de testes pela informação de progresso legível por máquina fornecida pelo sistema de compilação. Acompanhe a fase, o trabalho concluído, o trabalho total, as falhas, a porcentagem e detalhes limitados das falhas. Diferencie falhas de asserção de encerramentos inesperados, sinais, tempos limite e erros de infraestrutura. Preserve os parâmetros dos testes comparativos e as configurações de teste junto às evidências relatadas. Compile em modo de lançamento os testes comparativos destinados a medições. Mude para uma compilação de depuração ao diagnosticar um encerramento inesperado e faça uma recompilação limpa antes de medir novamente. Execute as verificações de formatação, código-fonte, compilação, testes, sanitizadores e plataformas exigidas pela superfície afetada. Execute novamente os critérios diretamente afetados após as correções da revisão. Não restrinja uma busca de coerência em todo o repositório apenas porque algumas correspondências parecem improváveis. Aprove somente quando o código, os contratos, os testes, os metadados de compilação, a documentação e as evidências medidas estiverem de acordo.