I used NDepend several times in the past, but up to today the usage covers only small part of that…
Firstly, it helps to visualize how the software is build, and when problems could appear 😉 So lets take a look:
What we can see there ?
- Big part of NDatabase code is put into NDatabase.Odb.Core.Layers.Layer3.Engine. That’s the part which is responsible for saving and retrieving data from file system, memory stream, isolated storage, so that’s the low-level database engine which is the big part of NDatabase
- There is several more big blocks, which describes well features supported by NDatabase: BTree, Linq, Query Values, Meta Representaion of Objects, Triggers, Transactions, Reflection, Type Resolution and more.
Going further, we could check the types metric:
This picture is showing us even more, we could see how types are spread in the library. The most important thing which we could find out from that are two the biggest types: ObjectReader and ObjectWriter. That means they could cause problems with the time (size of the class), so it will be good to create smaller classes from them. On the other hand, the names of them are describing well the set of methods which are the part of instances, and the size of them results from the library domain, it is all about object persistence!
The last view is focused on methods, which (in terms of sizes) is adequate to the above view:
The another even more important thing which I usually used are Queries and Rules, or rather the breaks of them. NDepend is defining the set of rules (best practices) which should be avoided. It’s not only creating the report from this rules, it additionally helps to understand them and identify the place in code which should be fixed! That’s the awesome feature which helps me to improve the design a lot.
That was the past. Now my toolkit grows with the knowledge about Dependency Matrix. I used to think, for big projects analyzing dependencies with dependency graph is too complicated. Take a look on NDatabase dependency graph!
But things are changing. (Thanks to Patrick for helping me to understand Dependency Matrix 🙂 Looking at Dependency Matrix documentation helped me to understand this view much better (before that, it was just the black magic…). Now, taking a look on below diagram was enough to identify and fix cycle dependency between NDatabase.BTree and NDatabase.Odb namespaces!
Black color means something is wrong, so expanding that shows two blues between more greens boxes. That’s the problem! NonPersistanteAttribute and OrderByConstants classes are used commonly in NDatabase assembly which makes it easy to have circular dependency between namespaces. I decided to create a new namespace (NDatabase.Common) which solved this particular dependency, the results are below.
But still, that’s not ideal. On below triangle we should have only blues, on above greens boxes. Going deeper with namespaces is showing us where is the problem:
Here it is! We have another dependencies which should be addressed, we even could visualize them better to see exact namespaces dependencies:
So far so good. Thanks this knowledge (and NDepend of course) I know how to identify namespaces circular dependencies.
Now I need the time to find more awesome NDepend features which are waiting for me to discover them 🙂