Architecturally clean systems are easier to maintain. Changes to a system therefore shouldn’t degrade its architecture. Paixao, Krinke, Han, Ragkhitwetsagul, and Harman studied four large projects to better understand whether and how developers take the system’s architecture into account when making changes.
Why it matters
Architectural decisions strongly impact a system’s maintainability.
For example, studies have shown that coupling and cohesion clearly affect various aspects of software quality, including maintainability, comprehensibility, code smells, and bug-proneness.
A better understanding of how developers deal with architectural changes is necessary in order to design proper tools and processes that prevent developers from making changes to a system that degrade its architecture.
How the study was conducted
The authors study changes from four Java projects with a large number of merged reviews. For each project, the authors extract all reviews and commits that represent the state of the system immediately before and after each reviewed merge.
The structural cohesion and coupling are computed on the module dependency graphs of the “before” and “after” states. This is done twice for each state: once for the overall architecture and once for a single package. The resulting numbers make it possible to determine the architectural impact of each merged change.
What discoveries were made
Most changes that significantly impacted the system’s architecture were made to introduce a new feature, enhancement of an existing feature, refactoring, and . Together, they account for 90% of all significant architectural changes.
Discussions about the impact that a change will have on the system’s architecture are conspicuously absent in most reviews, especially if that impact is negative. .
Reviews of changes that have refactoring as their primary goal generally do include discussions about architectural impact. Coincidentally, the impact tends to be more positive in these cases.
The impact is not always positive however. Sometimes refactoring results in a (partial) architectural deterioration. Reasons vary: in one case it’s because the developer did not realise the full ramifications of their changes, in another it’s because developers also appear to consider aspects other than coupling and cohesion.
In any case, it appears that one should strive for increased awareness of the architectural impact of changes among developers.
Changes of which the architecture is discussed during review tend to have higher structural improvement
The architectural impact of a change is discussed in only 38% of reviews, which suggests a lack of awareness among developers
Tool support might help increase architectural awareness and slow down or even prevent architectural degradation