Structure Review

Review code with two questions in mind: does each piece of structure earn its keep right now, and is there missing structure that would make the code easier to navigate and understand?

Over-structure (speculative abstractions, premature genericity) hurts because it obscures the real flow. Under-structure (flat directories, mixed responsibilities, everything in one file or one level) hurts because it forces readers to scan unrelated code to find what they need.

Workflow

1. Anchor the review in the real code.

• Read the changed files, nearby interfaces, and affected tests or docs.
• Distinguish between:
  • necessary structure serving current behavior
  • readability-oriented structure that pays for itself now
  • speculative or low-value structure added mostly for hypothetical future use
• Done when every changed file is read and classified into one of these categories.