solid-principles

Use SOLID to diagnose, not to decorate. Each principle names a specific way designs rot under change; the skill is recognizing the rot early and making the smallest cut that stops it. The failure mode of SOLID is applying it as ceremony - an interface for every class, a factory for every constructor - which produces the same unmaintainability it was meant to prevent, with more files. Every abstraction this skill recommends must be justified by a change pressure that actually exists in this codebase, not one imagined.

Step 1: Find the change pressure

Before judging any structure, learn what actually changes here:

• git log --oneline --follow on the files in question: what has forced edits, and do unrelated reasons keep touching the same file?
• Where have bugs clustered? A class that breaks every time a neighbour changes is telling you where the coupling is.
• What does the team add regularly (new payment providers, new report types, new integrations)? That axis deserves an extension point; axes that never vary do not.

SOLID violations only matter along axes that change. A "god class" that has been stable for two years is a lower priority than a small class edited weekly by three features.

Step 2: Diagnose against each principle

For each, the smell, the test, and the minimal fix - in the codebase's own idiom (modules and functions count; none of this requires classes).

S - Single responsibility. A unit should have one reason to change.

• Smell: commits touch the same file for unrelated features; the class name contains "Manager", "Handler", "Util"; you describe it with "and".
• Test: list the actors/features that force edits to it. More than one - it is doing more than one job.
• Fix: split along the reasons-to-change, not along method count. Ten cohesive methods are fine; three methods serving three features are not.

O - Open/closed. Add behaviour by adding code, not by editing a growing conditional.

• Smell: a switch/if-else chain over a type tag that grows a branch with every new variant, duplicated in several places.
• Test: "when the next variant arrives, how many existing files change?" More than one is the smell; zero or one (plus the new variant file) is the goal.
• Fix: one extension point - a strategy map, a handler registry, polymorphism - introduced at the second or third variant, not speculatively at the first.