[2/5] Clean design (Tidy First?) (Category Architecture)

Continue. first I’ll start with the first part of the book Clean Design, in which the author talks about the concept of small changes that make code easier. And here we change the structure of the software, not its behavior. The author says it’s like refactoring and tidyings are a help to refactoring. A separate term appeared because refactoring is now often referred to as those changes that change the behavior of the program, and the author wants to clearly distinguish this.

The author proposes the following approaches:

• Protective expressions (guarding clauses) - removal to the beginning of the function of initial expressions that must be taken into account and early return when they occur from the function
• Dead code. (dead code) - It just needs to be removed. (If needed, it can be restored from the version control system.)
• Normalization of symmetries (normalize symmetries) In short, it is necessary to use consistent approaches throughout the code, for example, the approach to defining and initializing variables. Here can help linters or approaches to readability, as in Google (about wrote Previous Post Measuring Engineering Productivity)
• New interface, old implementation (new interface, old implementation) When implementing changes, we can identify a new beautiful interface and transfer everyone to it, and at first under the hood pull a challenge to the old implementation. In fact, this is a default approach in migration:)
• Code reading order (reading order) The file with the code should be arranged so that it is convenient for the reader to study it. (It's funny that this is true for everything: books, presentations, manuals.)
• The principle of coherence (cohesion order) The point is to organize the code in the file so that when you change the elements that change together, they are located next to each other. The same is true for different files that are linked. (coupling) - they can be transferred to the general catalog.
• Combination of variable declaration and its initialization (move declaration and initialization together) - again, the point is to bring the connected pieces of logic together.
• Explanatory variables (explaining variables) creating separate variables for complex expressions instead of calculating them just in place, for example, when throwing the expression into the parameters of the called function
• Explanatory constants (explaining constants) Creating constants instead of magical values scattered by the code
• Explicit parameter transfer (explicit parameters) - instead of throwing hashmap with an abnormal number of parameters, it is better to clearly throw them into the parameters when calling the function
• Visual grouping of instructions (chunk statements) If you understand when reading the code that one part is doing this and the other is doing this, just add an extra blank line between these blocks of code, plus these blocks of code can be improved with the help of other tips from this part.
• Extraction of helper functions (extract helper) Extracting auxiliary code blocks into separate functions with the name
• One big dump. (one pile) During cleaning, it is sometimes necessary to reduce all parts of the code in one place, and only then apply the rest of the approaches. When we do that, we get one big dump.
• Substantive comments (explaining comments) - if when reading a piece of code you click and there is a thought "Ah, this is what it is", then it makes sense to write this insight in the comment
• Removing redundant comments (delete redundant comments) Sometimes when clearing the code, some comments become apparent, at which point such comments should be deleted.

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture