Knowledge MaxxingSeparation of concerns
Separation of concerns is organizing code so each part handles one distinct responsibility, keeping unrelated logic, like data storage and display formatting, apart from each other.
Prerequisite: Design pattern
What matters
Code organized this way is easier to change safely, since a change to one concern, like how data is displayed, is less likely to accidentally break an unrelated concern, like how it's stored.
Example
Keeping database-access code separate from the code that formats a response for display is an example of separating two distinct concerns.
Common misconception
Separation of concerns does not mean every piece of logic must live in its own separate file; it's about responsibility boundaries, not simply file count.
Recall question
Why does separating concerns make a codebase safer to change?