I've run my open source FileCombiner app through NDepend and dotTrace, and the results were on one hand startling, and on the other hand, expected.
Here are the first impressions:
dotTrace:
- Discovered huge performance hit surrounding my WriteByte code. While attempting to make something that's extremely granular for Unit Testing, I obviously lost site of the overall speed goal.
- Essentialy what's going on is 29 million individual calls to the WriteByte code -- I need to optimize this (probably by using a buffer), but now I have measured performance as a benchmark to improve.
- I can now prove that improvements to code occurred, that they have a net positive effect, and the scale by which those improvements exist.
NDepend:
- This one's tougher. A lot of the measures here I don't yet fully understand.
- The good:
- 28% comment ratio (1:1 would be 50%)
- Distance is extremely low (0.07). Code nicely straddles the safe area between the "zone of uselessness" and the "zone of pain"
- Most classes have great numbers
The Bad:
- App is marked as high instability
- High instability seems centered around the FilePartJoiner class
- Trial/Open Source edition of NDepend does not allow import of NCover reports (that was a disappointment)
- High levels of Efferent Coupling -- need to discover why. Generally this means that a class is tightly coupled to another class, but NDepend states that it filters out framework classes. What's interesting is that this is the main WinForm class. I wonder if the correct behavior here is to remove that class from processing? I wonder how that would affect the net numbers
- The attribute that I've declared "CoverageExcludeAttribute" that NCover is set up to ignore is showing up as incredibly evil to NDepend. I need to figure out how to exclude that attribute from processing in NDepend! This may be two birds with one stone if I am able to make NDepend recognize that attribute as those classes marked with that attribute seem to be the pain points in the app.
My next steps are to resolve the performance issue, as well as reconfigure NDepend to avoide the CoverageExclude attributes & rerun the NDepend results. This may be followed by moving all library-type classes out to a separate DLL. This was going to be a later stage, but I may be going against the grain of proper dependancy standards by holding off until later.
I'm definitely liking the process here, but it'll be interesting to attempt this same evaluation on an enterprise level application.