[5/5] Clean design (Tidy First?) (Category Architecture)
This post concludes the series on Clean Design. (previous posts: 1, 2, 3 and 4).
- Engagement (coupling) - The author describes concept Cascading changes, when changes in one component trigger changes in other components. This property was described by Ed Yordon and Larry Constantine in their book Structured Design.
Two elements are considered to be related to a change if a change in one element requires a change in another element. In this definition, it is important not only that the elements are related to each other, but also that this relationship exists with respect to a particular change. Therefore, a simple review of the source code is not enough to analyze coupling – it is important to know what changes have already occurred, as well as what are possible in the future. As a result, coupling raises development costs, so it’s often helpful to understand when cleaning what changes will reduce it.
- Costantain's Equality (Constantine’s equivalence) An interesting chain of thoughts of the author Where he starts by saying that most of the total cost of code ownership is the cost of changes.> cost(software) ~= cost(change) The value of changes has a power distribution. (power law distribution)It is not normal that the cost of large changes outweighs normal events.> cost(change) ~= cost(big changes) And big changes are due to high coupling.> cost(big changes) ~= coupling This is what Constantine Equality is: Cost(software) ~= cost(change) ~= cost(big changes) ~= coupling or more simply put
cost(software) ~= coupling That’s why everyone wants to reduce coupling, but that requires compromises.
- Engagement and reduction (coupling versus decoupling) The author begins by saying that “the hook is often invisible until you step on it – just like a Lego cube in a dark room.” But as the hook appears, there are several options. When implementing the behavior, we chose a path with additional engagement, taking into account the NPV solution. (could have been done without it, but it was longer and it is not clear when it will pay off.) Initially, it did not cause problems. (We didn't initially plan to make changes that suddenly appeared before us.) In the end, there must be relations and interrelations between our elements of the system, otherwise it is no longer a system, but a group of elements.) Next, we have to make a decision - pay further for the hook or pay for its reduction. If you plot the graph, you can see that both of these extreme solutions are prohibitively costly, and we have to pick something in the middle. (As usual, where exactly in the middle you should look empirically).
- Connectivity (cohesion) The author is actually talking about the clustering of elements of our system. Conditionally strongly related elements should fall into their clusters, and unrelated elements should appear in different clusters. But coupling is already links between these clusters.
- Conclusion (conclusion) In the last chapter, the author explains how to make a cleaning decision.
- Costs. Will cleaning reduce costs for a later time or make them less likely?
- Income. Will cleaning increase revenue more, faster, or more likely?
- Coupling. Will cleaning mean I have to change fewer items?
- Cohesion. Can ordering lead to the elements I need to change being smaller and more concentrated? Finally, he compares the purification, refactoring and evolution of architecture, where the scale of change, stakeholders, causes and ways of implementing each approach are changing. This is only the first book in the series, so we are waiting for the next one.
P.S. In the end, the author recommends a bunch of books, of which I have only read a few.
#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture