SOLID, clean code and clean architecture

What was covered

• Level one, daily practice. The things to look for in a pull request: descriptive names even when they run long, small functions and classes that do one thing, no more than two or three arguments, and no repetition.
• Level two, SOLID. Each principle came with a short example. A User should not also send the welcome email (single responsibility). New shapes extend a Shape interface instead of editing calculate (open/closed). An ostrich is a bird that cannot fly, so model Bird and FlyingBird separately (Liskov). Split fat interfaces into Workable and Eatable (interface segregation).
• Level three, architecture. Dependency inversion is the principle that matters most here. A ReportGenerator depends on a DataSource abstraction, not on a database connection. Clean architecture stacks this into concentric layers (entities, use cases, interface adapters, frameworks and drivers) with dependencies pointing only inwards.

What came up

• How far to generalise. The rule is not to repeat yourself, but effort has to be weighed against benefit.
• Selling a refactor. A large refactor is hard to justify, so follow the boy scout rule: leave the code a little cleaner than you found it, in the parts a new feature touches.
• Skipping layers. Not good practice. Use mappers to convert between layers. They add verbosity and upfront work, but they isolate the domain and make provider changes cheap.
• Real migrations. One of us found the layering paid off during a cloud-provider migration, where only the outer layer changed and the business rules stayed untouched. A database swap went much the same way.

Takeaway

Pick a standard and apply it in small steps. It lowers friction in the team and shortens development cycles. A repository with a clean-architecture example was promised as a follow-up.