Uncle Bob Craft

Aplique os critérios de Robert C. Martin (Uncle Bob) para revisão e produção de código: Clean Code, Clean Architecture, The Clean Coder, Clean Agile e disciplina de padrões de projeto. Esta habilidade é complementar à habilidade existente @clean-code (que foca no livro Clean Code) e ao linter/formatador do seu projeto — ela não os substitui.

Visão Geral

Esta habilidade agrega princípios do trabalho de Uncle Bob para revisar e escrever código: nomes e funções (via @clean-code), arquitetura e limites (Clean Architecture), profissionalismo e estimativa (The Clean Coder), valores e práticas ágeis (Clean Agile), e uso vs. mau uso de padrões de projeto. Use-a para avaliar estrutura, dependências, SOLID em contexto, "code smells" (cheiros de código) e práticas profissionais. Ela fornece critérios de "craft" (ofício) e design apenas — não imposição de sintaxe ou estilo, que permanecem responsabilidade do seu linter e formatador.

Quando Usar Esta Habilidade

• Revisão de código: Aplique a Regra de Dependência, limites, SOLID e heurísticas de "smells"; sugira refatorações concretas.
• Refatoração: Decida o que extrair, onde traçar limites e se um padrão de projeto é justificado.
• Discussão de arquitetura: Verifique limites de camadas, direção de dependência e separação de responsabilidades.
• Padrões de projeto: Avalie o uso correto vs. "cargo cult" (culto à carga) ou uso excessivo antes de introduzir um padrão.
• Estimativa e profissionalismo: Aplique ideias de The Clean Coder (dizer não, ritmo sustentável, estimativas de três pontos).
• Práticas ágeis: Referencie Clean Agile (Iron Cross, TDD, refatoração, programação em par) ao discutir processo.
• Não use para substituir ou sobrescrever o linter, formatador ou testes automatizados do projeto.

Agregadores por Fonte

Padrões de Projeto: Uso vs. Mau Uso

• Use padrões quando eles resolvem um problema real de design (ex: variação de comportamento, ciclo de vida ou preocupação transversal), não para parecer "enterprise".
• Evite "cargo cult": Não adicione Factory/Strategy/Repository apenas porque a base de código "deveria" tê-los; adicione-os quando duplicação ou rigidez justificarem a abstração.
• Sinais de mau uso: Nome do padrão em todos os nomes de classe, camadas que apenas delegam sem lógica, padrões que tornam código simples mais difícil de seguir.
• Regra geral: Introduza um padrão quando sentir a terceira duplicação ou a segunda razão para mudar; nomeie o padrão no código ou na documentação para que a intenção fique clara.

"Smells" e Heurísticas (Resumo)

Listas completas (incluindo heurísticas estilo C1–T9) estão em reference.md. Use-as em revisões para nomear problemas e sugerir refatorações (extrair, mover dependência, introduzir limite).

Revisão vs. Produção

…