Improve Code Architecture and Code Maintainability

The use case Ramp Up in a New Code Base explains how the NDepend Dependency Graph and Dependency Matrix help understanding code by visualizing its architecture. You can go further with these tools and identify entangled portions of your architecture and get concrete advices on what to do to improve it.

Some code is maintainable when the time to implement a change is short and when the risk that a change breaks some wanted behaviors is low. Avoiding monolithic components and other code smells like god classes is essential to obtain maintainable code and prevent frictions when the code will evolve.

Identify entangled portion of code

When no element is selected the dependency graph navigation bar proposes a cycles link. Clicking this link edits the code rule Avoid namespaces dependency cycles.

From there you can export the elements that form a cycle to the graph. Below we can see a graph made of 30 entangled namespaces. They form a large monolithic portion of code: all these namespaces depend on each other.

To improve such monolithic architecture components must be layered. To do so it is advised to:

• Transform each double-side edge (in red) into a single sided edge. For that double clicking a red edge shows a new graph made of types and methods involved into the two sided coupling.
• Remove all remaining cycles to layer the entire structure.

The dependency matrix proposes also some features to identify and navigate entangled code.

• Cells representing a bi-directional dependency have a background paint in black.
• The matrix triangularization heuristic aggregates elements involved in a cycle.
• Cycles are highlighted with a red border.

Additionally an Indirect Dependency Mode is proposed by the matrix. In this mode the number in cell is the minimum path length between the row element and the column element. Since all elements involved in a cycle are inter-dependents, in this mode all cells within a cycle have a black background.

Get advices on what to do to improve the architecture

The default rule Avoid namespaces mutually dependent contains an heuristic that lists dependencies that should be removed at namespace, class and method levels. For each advices proposed, the time to implement is estimated. This is the technical-debt estimation for the fix.

Often to improve your architecture based on these advices you'll end up:

• Moving a class, an interface or an enumeration from one namespace to another.
• Create interfaces and inject code to favor depending on an abstraction instead of an implementation as adviced by the Dependency Inversion Principle.
• Create namespaces to group some interfaces or to group some classes.