Padrões de qualidade do código

Saiba mais sobre recursos e otimização de custo bem arquitetados → Organização de código

Essa página de padrão consolidado abrange as práticas de qualidade e manutenção de código para otimização de recurso. Inclui orientação sobre decisões de código padrão vs. personalizado, gerenciamento de débito técnico, padrões de design, práticas de documentação e governança. Esses padrões ajudam a manter a velocidade de desenvolvimento, reduzir as taxas de defeito e permitir a sustentabilidade de soluções de longo prazo.

Padrões

Onde procurar	Qual é a boa aparência
Desempenho em escala	✅ O teste valida se as soluções declarativas atendem aos requisitos de desempenho em volumes de dados projetados. O teste de carregamento no Full Copy Sandbox com dados realistas confirma a escalabilidade antes da implementação da produção.
Análise de capacidade de manutenção	✅ A análise de TCO compara a carga de manutenção de longo prazo de abordagens declarativas vs. personalizadas, incluindo esforço de atualização, requisitos de teste e requisitos de habilidades para equipes futuras.
Arquitetura de abordagem mista	✅ As soluções combinam abordagens declarativas e programáticas quando apropriadas. O fluxo orquestra lógica de alto nível, enquanto o Apex lida com cálculos complexos. Campos de fórmula calculam derivações simples enquanto o Apex processa operações em massa.
Avaliação do AppExchange	✅ Antes de criar código personalizado, avalie pacotes existentes do AppExchange que fornecem funcionalidades semelhantes. Resultados da avaliação do documento, incluindo pacotes revisados, lacunas de funcionalidade e comparação de TCO.

Padrões

Onde procurar	Qual é a boa aparência
Visibilidade de pendências	✅ Itens de débito técnico rastreados em pendências com rótulos claros, contexto explicando por que o código precisa de melhoria, impacto comercial de deixá-lo sem solução e esforço estimado de remediação. O débito invisível não pode ser priorizado nem gerenciado.
Melhoria incremental	✅ Regra Boy Scout aplicada durante o desenvolvimento de recursos: deixar código melhor que encontrado. As equipes remediam o débito incrementalmente durante o trabalho de recursos relacionados, em vez de exigir grandes projetos de refatoramento dedicados. As análises de código verificam melhorias incrementais.
Prevenção sobre remediação	✅ Os portões de qualidade em CI/CD aplicam padrões antes de o código chegar à produção. Scanner de código, ApexGuru e métricas de complexidade integradas à validação de solicitação de pull. Bloquear problemas impede a mesclagem até ser resolvida.

Antipadrões

Onde procurar	Qual é a aparência ruim
Gerenciamento de pendências	⚡️ Dívida técnica confirmada verbalmente, mas nunca rastreada em pendências. Nenhuma visibilidade do acúmulo de débito. A remediação da dívida sempre adiada em favor do trabalho do recurso. O Velocity diminui gradualmente, as equipes não podem explicar por quê.
Desvio de gate de qualidade	Portões de qualidade de CI/CD frequentemente ignorados sob pressão de agenda com intenção de corrigir mais tarde. “Mais tarde” nunca acontece. Falhas do leitor de código marcadas como problemas conhecidos e ignoradas. Limites de complexidade elevados para acomodar implementações ruins.
Sem capacidade de remediação	100% da capacidade de sprint alocada para trabalho de recurso com capacidade zero para remediação de débito técnica. O débito se acumula indefinidamente. Principais projetos de refatoramento exigiram 18 a 24 meses consumindo trimestres inteiros.
Dívido de configuração	Tipos de metadados personalizados e configurações personalizadas são acumulados sem limpeza. A configuração não utilizada persiste indefinidamente. A produção tem 50 registros de metadados, sendo que apenas 12 são realmente usados. Nenhuma documentação explicando o propósito dos valores de configuração.

Padrões

Onde procurar	Qual é a boa aparência
Arquitetura do acionador	✅ Padrão do manipulador do acionador aplicado de modo consistente: acionadores finos são delegados às classes de manipulador, as classes de manipulador organizam a lógica pelo contexto do acionador (antes de inserir, após a atualização), os nomes de métodos claros revelam o propósito. Nenhuma lógica de negócios nos arquivos de acionador em si.
Implementação da camada de serviço	✅ Lógica de negócios encapsulada em classes de serviço separadas de controladores, acionadores e pontos de entrada em lote. Classes de serviço reutilizáveis em vários pontos de entrada sem duplicação. Limpe a convenção de nomenclatura (AccountService, OrderProcessor).
Padrão do seletor	✅ Consultas SOQL centralizadas em classes seletoras por objeto (AccountSelector, OpportunitySelector). Os métodos seletores retornam conjuntos de campos consistentes. Alterações de otimização de LDV aplicadas uma vez, afetando todas as consultas.
Padrão do repositório	✅ Acesso a dados extraído atrás de interfaces que permitem testes com origens de dados simuladas. As implementações de repositório encapsulam estratégias de construção de consulta, armazenamento em cache e otimização. A lógica de negócios depende de interfaces de repositório, não de implementações concretas.
Padrões de design de componente	✅ Componentes da Web do Lightning seguem o princípio da responsabilidade única, expõem propriedades para configuração, emitem eventos para comunicação pai, projetados para composição e reutilização. Biblioteca de componentes documentada com exemplos de uso.
Organização de código	✅ Estrutura de pacote lógica agrupa classes relacionadas. Limpe a separação entre lógica de domínio, acesso a dados, pontos de extremidade da API e adaptadores de integração. As dependências do pacote fluem em uma direção.

Antipadrões

Onde procurar	Qual é a aparência ruim
Acionadores	⚡️ Toda a lógica de negócios integrada diretamente a arquivos de acionador com condições profundamente aninhadas, sem separação de preocupações, sem classes de manipulador. Mais de 300 arquivos acionadores de linha misturando validação, lógica de negócios e chamadas de integração. Não é possível testar de modo eficaz.
Consulta em loop	⚡️ Consultas SOQL executadas em loops de iteração. Trabalha com pequenos volumes de dados, mas viola o limite de consultas SOQL 100 ao processar operações em massa. Descoberto apenas quando acionadores são disparados em cargas de dados em massa na produção.
DML em loop	Declarações DML (inserir, atualizar, excluir) executadas em loops de iteração. Viola o limite de instruções DML 150 com operações em massa. Cada registro processa em uma transação de banco de dados separada em vez de um processamento em massa eficiente.

Padrões

Onde procurar	Qual é a boa aparência
Registros de decisão de arquitetura	✅ Decisões arquitetônicas significativas documentadas em ADRs armazenados no controle de versão. Os ADRs capturam o contexto (acionadores de negócios, restrições técnicas), a decisão (o que foi escolhido), as alternativas consideradas (por que foram rejeitadas) e as consequências (negócios, condições para revisitação).