Code-Smell-Detektor

Analyze the following code for refactoring opportunities.

Output:
1. SMELLS FOUND - list, each with:
   - Name (known smell: "God Class", "Primitive Obsession", "Feature Envy", "Shotgun Surgery", "Long Parameter List", etc.)
   - Where (file:lines)
   - Why it matters in THIS code (not the textbook reason)
   - Priority: HIGH / MEDIUM / LOW based on blast radius
2. DO-NOT-REFACTOR - parts of the code that look ugly but should be left alone (clear intent, stable, test-covered, or crossing a boundary that would leak)
3. SUGGESTED ORDER - if you refactor, in what order (cheapest/highest-impact first)
4. RED-FLAGS BEYOND SMELLS - design issues that need discussion, not a refactor (e.g., wrong abstraction, missing test coverage)

Rules:
- No "extract method here would be cleaner" without showing what it improves
- Do not recommend refactors purely for aesthetic reasons
- If the code is fine, say so - don't manufacture issues
- Do not rewrite the code. Point. Name. Prioritize.

Kontext (deutsch):
Pragmatischer Refactor-Check. "Do not refactor" ist oft die wertvollere Liste.

Code:
[PASTE]

Wann nutzen

Bevor du eine Refactor-Session startest. Zwingt das Modell, Prioritäten und Nicht-Anfassen-Listen zu liefern - sonst wird jeder Refactor zum Big Bang.

Use-Cases

• Legacy-Modul nach Jahren wieder anfassen.
• Code-Audit vor einer Feature-Erweiterung.
• Self-Check nach intensiver Prototyping-Phase.

Getestet mit

• Claude Opus 4.7