You have known the five SOLID principles since lesson 1.4.6, from small examples with a before and an after. In lesson 2.10.4 you met them again in everyday work, through the question of what changes when the Kladde moves to the web. This module doesn't explain the principles once more. It goes the opposite way: starting from the code you wrote yourself in the last few modules, which by now is big enough to hurt.
Every lesson in this module has the same structure. It begins with a smell in the Kladde's real code. A characterization test records what the code does today. Then comes the refactoring in small pull requests, then a measurement that proves the gain, and finally the question of when not to do it. This lesson lays the groundwork: you learn the smells, find them in your Kladde and put the tests in place before anyone refactors.
A principle is a tool against a pain
A common mistake when learning SOLID: you read the principles, find them convincing, and from then on build an interface for every class, split up every method and plan extension points for things that never come. The code doesn't get better, only longer.
So the rule of this module is: a principle is a tool against a pain, not a goal. The pain is concrete. A small requirement forces you to touch five files. A test needs a database even though it checks a rule. A test fake has to have twenty methods, of which the test needs one. Where nothing hurts, there is nothing to fix.
The code itself often shows the pain before the next requirement arrives. Such signs are called code smells, a term from the literature on refactoring. A smell isn't a bug. It is a hint that something here might be off, and a reason to look more closely.