Separation of concerns -- each module does one thing

Functions that fetch data AND format it AND log it AND handle errors are hard to test, hard to reuse, and hard to change. A change to logging requires modifying business logic.

Each function/module/service should have one reason to change. Separate: (1) Data access from business logic. (2) Business logic from presentation. (3) Configuration from code. (4) Error handling from happy path (use middleware/decorators). (5) Validation from processing. Test: can you describe what this function does without using 'and'? If not, it does too much.

When concerns are mixed, changing one requires understanding and risking all others. Separated concerns can be tested, replaced, and evolved independently.