Architecture Anti-patterns: Automatically Detectable Violations of Design Principles (Category Architecture)

This article This is an interesting topic of architecture governance. In it, the authors describe their approaches for automatically finding architectural anti-patterns in large systems. The bottom line is that files that are subject to changes and errors rarely live alone in such systems – they are usually architecturally connected and these connections display architectural problems that lead to the spread of error exposure. In this article, the authors define a set of anti-patterns based on the fundamental principles of design and Baldwin and Clark’s design rule theory. Next, they validate a set of architectural anti-patterns that can be automatically found by analyzing the structural relationships in the project as well as the history of change. To this end, the authors analyzed 19 large-scale systems and demonstrated 1. Files involved in these architecture anti-patterns are more error-prone and change-prone; 2. The more anti-patterns a file is involved in, the more error-prone and change-prone it is; and 3. While all of our defined architecture anti-patterns contribute to file’s error-proneness and change-proneness, Unstable Interface and Crossing contribute the most by far.

In the end, the authors succeeded. 6 anti-patterns:

1. Unstable Interface The interfaces on which many depend must remain stable.
2. Modularity Violation Groups Independent modules must evolve independently.
3. Unhealthy Inheritance Hierarchy This is a violation of the Liskov Substitution Principle.
4. Crossing - a file that has both high fan-in and high fan-out, and changes often together with its dependents and the files it depends on, is often at the center of maintenance activities.
5. Clique A set of files that form a strongly-linked graph, resulting in tight coupling between files (Expansion of history with cyclical dependencies)
6. Package Cycle Cycles in dependency graphs that violate basic design principles to form hierarchical structures. Changes to a file in one package often cause unexpected changes to files in other packages due to cyclical dependencies between them.

I was interested in this white paper because of the article. **"A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google"**about told A couple of days ago. The bottom line is that there, the authors analyzed the Monarch codebase in the way described in this article, and found many anti-patterns in the codebase of components in Leaves that had too much responsibility and were difficult to maintain. Later in the last article, they redesigned this component to improve availability and maintainability.

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems