Skip to content
#Architecture

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

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

Continuing posts (1 and 2) In the book Clean Design, the author talks about how to manage cleaning: when to start, when to finish, and how to combine it with changing the behavior of the system. Here the author gives the following advice

  • Cleaning separately (separate tidying) Cleaning should be carried out separately from changes that change the behavior of the system. This can be easily arranged by wrapping all cleaning changes into a separate MR. (merge request). Plus, you have to think about the size of the MR — it has to give you some picture to understand the changes, but at the same time, it doesn’t have to be too big to understand.
  • Chains. (chaining) When you start cleaning, these changes begin to create changes for further cleaning. It is important to be able to plan cleaning for several steps, and also know when to stop. More information about cleaning approaches can be found in second-post
  • Size of sets of operations (batch sizes) Here the author tells how to determine the size of the cleaning. He proposes to estimate the cost of revision changes (What forces you not to do small MRs with cleaning) and problems with large cleaning batches: potential collisions, behavioral changes, and speculative changes. In the end, we need to find the optimal:)
  • Rhythm (rhythm) - the author says that in cleaning you need rhythmicity - we can't just clean up and forget about cleaning:) We need to do this periodically if we want to live in a clean place.
  • Untangling (getting untangled) Sometimes, when you write code that changes behavior, the idea comes to clean up. Then write the code again, which changes the behavior, and then clean the code. The author suggests not to do so, and if you still have such a confusing change, then demolish it and continue to do it all over again with new knowledge and understanding that it is necessary to divide behavioral changes and cleaning into separate MRs.
  • Before, after, later, never (first, after, later, never) - the answer to the question, and when to clean. And as usual, it depends... And here it all depends on the economic effects: if cleaning helps us a lot with further changes, we can start with it. And if we never have to change the code, (We're writing a one-off script.)There is no need to clean anything:) But the options in the interval are more complicated and the author gives the following recommendations: Clean up after the changes if Waiting for the next convenient opportunity to conduct it immediately before the changes will cost more Without it, you don’t feel like the job is done.
  • Do the cleaning later if Cleaning involves a lot of work that will not have an immediate effect.
  • Its completion will pay off later It can be carried out in small parts.

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