Análise código .Net

DotNet No Comments

Consigo sim fazer essa avaliação — mas eu não consigo acessar diretamente um caminho local do seu Windows (C:\Users\...) a partir daqui. Para eu analisar o projeto de verdade (código, csproj, camadas, DbContext, queries, etc.), você tem 3 opções:

  1. Enviar um ZIP do repositório (ideal)
  2. Enviar somente partes relevantes (pasta de Data/Infra, DbContext, Repositories/Services, Controllers/Handlers, principais Entities e Migrations)
  3. Rodar análises automatizadas aí e me mandar os relatórios (Sonar/Analyzers/CodeMetrics), e eu interpreto e devolvo um parecer com recomendações

✅ Dica de privacidade: antes de enviar, remova/mascare secrets, connection strings, chaves, certificados e qualquer dado sensível (appsettings.* / user-secrets / pipelines).

O que eu vou entregar (quando você enviar o código ou os relatórios)

Um relatório estruturado com:

  • Misuse de Entity Framework (anti‑patterns + impacto: performance, concorrência, consistência, manutenção)
  • Violação de SOLID (por princípio, com exemplos e refatorações sugeridas)
  • Clean Code (legibilidade, complexidade, duplicação, acoplamento, testes, logs, exceptions)
  • Severidade e priorização: Quick wins (1–2 dias), Médio prazo (1–2 sprints), Estrutural (refatoração maior)
  • Trechos de código anotados (antes/depois) quando aplicável

Para começar: me diga 3 coisas rápidas

  1. O projeto usa EF Core ou EF6? (e versão do .NET: 6/7/8?)
  2. A arquitetura é Clean Architecture, DDD, N‑tier, CQRS/MediatR…?
  3. O problema percebido hoje é mais performance, bugs, dificuldade de evoluir, ou tudo isso?

Se você responder isso, eu já ajusto o foco da análise.

Checklist do que eu vou procurar (e como vou marcar “uso indevido”)

1) Entity Framework — Principais “misuses” / anti‑patterns

A. Performance e consultas

  • N+1 queries (loop que dispara query por item)\ Sinais: .ToList() cedo demais + depois acessando navegações; lazy loading sem controle; foreach com FirstOrDefault/Single no DbSet.
  • Client evaluation / materialização precoce\ Sinais: .AsEnumerable() cedo; projeção depois do materialize; ToList() antes de Where/Select.
  • Tracking desnecessário em leituras\ Sinais: queries de leitura sem .AsNoTracking() (quando não vai atualizar).
  • Includes excessivos / “cartesian explosion”\ Sinais: muitos .Include().ThenInclude() em coleções; retorno gigante; lentidão e memória alta.
  • Paginação incorreta\ Sinais: Skip/Take sem OrderBy; paginação feita em memória.
  • Projeção ineficiente\ Sinais: buscar entidade inteira quando só precisa de 3 campos (não usa Select para DTO).

B. Ciclo de vida do DbContext / concorrência

  • DbContext como Singleton (grave)\ Sinais: registrado como singleton; guardado em campo estático; reusado entre requests.
  • DbContext compartilhado em paralelo\ Sinais: Task.WhenAll com o mesmo context; uso em threads múltiplas.
  • Transações mal gerenciadas\ Sinais: múltiplos SaveChanges() em fluxo crítico sem transação; mistura de conexões.

C. Arquitetura e acoplamento

  • “Repository pattern em cima do EF” (o “repository do repository”) — muitas vezes vira redundância e piora consultas\ Sinais: GenericRepository<T> com GetAll() retornando IEnumerable<T>; falta de IQueryable controlado; specifications ruins.
  • Exposição de IQueryable para camadas superiores sem contrato (vazamento de infraestrutura)\ Sinais: services/controladores montando query arbitrária sobre DbSet.
  • Domínio acoplado ao EF\ Sinais: Entities com atributos de EF por todo lado, lógica de negócio misturada com navegações e carregamentos.

D. Modelagem e consistência

  • Entidades anêmicas + lógica no Service gigante
  • Falta de invariantes no domínio (entidade aceita estados inválidos)
  • Migrations caóticas, sem revisão; alteração de schema arriscada
  • Uso indevido de lazy loading (especialmente fora do request)

✅ Resultado: eu costumo classificar cada achado como (P0 crítico / P1 alto / P2 médio / P3 baixo) com “como reproduzir” e “como corrigir”.

2) SOLID — O que vou medir no seu código

SRP (Single Responsibility)

  • Classes “Deus” (Service/Manager com 1000+ linhas)
  • Handlers/Controllers fazendo: validação + regra + persistência + integração + mapping + logging tudo junto

OCP (Open/Closed)

  • switch/case gigante por tipo/status/canal
  • Ifs espalhados por toda parte para variações previsíveis (ex.: regras por “tipo de cliente”)

LSP (Liskov)

  • Heranças onde subclasses quebram contrato (lança exceptions inesperadas; altera semântica)

ISP (Interface Segregation)

  • Interfaces “gordas”: IService com 20 métodos, implementações forçadas a “não usar metade”

DIP (Dependency Inversion)

  • Domínio/Application dependendo de EF/infra diretamente
  • Services instanciando dependências com new (sem DI)
  • Dependência em classes concretas, não abstrações

📌 Na prática, eu vou apontar:

  • quais dependências estão invertidas
  • onde extrair políticas (domínio) de mecanismos (infra)
  • onde aplicar Strategy/Policy/Specification sem exagero

3) Clean Code — Sinais objetivos que eu procuro

  • Nomes ruins (métodos genéricos: Process, Handle2, DoWork)
  • Métodos longos (muitos níveis de indentação, muitos parâmetros)
  • Complexidade ciclomática alta (muitos if, &&, ||, switch)
  • Duplicação de regras e validações
  • Exceptions como fluxo (try/catch controlando lógica)
  • Logs ruins (sem correlação, sem contexto, loga dados sensíveis)
  • Testabilidade baixa (métodos estáticos, dependências escondidas, código sem interfaces)
  • Mistura de camadas (Controller acessa DbContext direto; Application acessa HttpClient sem abstração, etc.)

Se você quiser rodar a varredura aí (e só me mandar os outputs)

Aqui vai um “kit rápido” de checks úteis (você roda e cola os resultados):

1) Build e warnings

dotnet build -c Release

2) Formatação (se já tiver dotnet format configurado)

dotnet format

3) Analyzers recomendados (se puder adicionar)

  • SonarAnalyzer.CSharp
  • StyleCop.Analyzers
  • Microsoft.CodeAnalysis.NetAnalyzers

4) Métricas (se você usa VS Enterprise: Code Metrics)

Ou me mande um print/export das métricas de Maintainability / Cyclomatic Complexity.

Se você me mandar:

  • lista dos Top 20 arquivos por complexidade
  • e os Top 20 por duplicação / warnings\ eu já consigo apontar o grosso das violações.

Como você pode me enviar para eu analisar agora

✅ Melhor caminho:

  1. Compacte voyager (sem bin/obj)
  2. Garanta que não vai appsettings.Production.json com segredos
  3. Faça upload aqui do ZIP

Ou, se não puder mandar o repo todo:

📂 Envie estas pastas/arquivos (já dá para um diagnóstico bem forte):

  • *.csproj, Directory.Build.props/targets (se houver)
  • Camada de infraestrutura/dados: DbContext, EntityTypeConfigurations, Migrations
  • Services/UseCases/Handlers principais
  • Controllers (ou endpoints minimal)
  • 3–5 fluxos críticos (ex.: criação de ordem, fechamento, cálculo, etc.)
  • Um exemplo de query “pesada” (ex.: listagem com filtros)

Próxima pergunta (para eu começar do jeito certo)

Você prefere que eu faça a avaliação:

  1. Foco performance EF (N+1, includes, tracking, paginação, concorrência)
  2. Foco arquitetura SOLID/Clean (camadas, acoplamento, coesão, testes)
  3. Equilibrado (um pouco de cada, com priorização)

Se você me mandar o ZIP (ou um recorte do projeto), eu começo a revisão e te devolvo um relatório com achados e recomendações práticas.