This is a modest number
but I am happy to have reached it, especially taking account that I spend several hours for each post. I try to maintain around one post per week
since June 2007.
I am the lead developer
of the tool NDepend
for .NET developers. This blog is often used to inform readers about
capabilities and new versions. NDepend features are built around
development concepts. Code bases are amongst the most complex and
costly engineering object conceived today. Tools like NDepend are more and
more needed to help engineers understanding and controlling what is
happening in their development shop. 5 years ago when I began working on NDepend during my spare time, some developers’ mates didn’t even get the point of such tool. Nowadays, I believe concepts underlying
NDepend are about to become mainstream: just have a look at architect features of VisualStudio 2010 if you are not yet convinced.
On this blog, I do my best to explain the why and how of all these development concepts. If I would have to keep the 5 most important practices where NDepend can be of
unique help, I would choose:
- Avoid having cycles in the
namespace dependency graph.
This will maintain your code base in a constant clean design that will greatly help for evolution and maintenance. Continuously clean design fosters evolutive design, so prevalent in all agile methodologies.
- Reduce the number of
assemblies and increase the number of namespaces. Namespaces then become your component units. The main advantage to use namespaces over assemblies to define components is that namespace is a logical thing whil assembly is something physical. A component should be not too small (to foster clean big picture with not too many components) nor too big (for individual unit maintenance): 1000 to 2000 Lines of Code per namespace seems to me reasonable.
Applying this advice will help being more agile thanks to finer, logical and controllable componentization, shorter compilation time and less deployment
- Release often and focusing your energy on the delta between last released version and upcoming version. This include making sure to maintain a high
quality on added and refactored code before each release. More specifically you can make sure that fresh code is properly covered by tests (>
80%) and also focus code reviews on added
and refactored code before each release. This will help repaying your technical debt
step by step. Also code that haven’t been modified contains no known bug (you would have then fixed them by touching code, wouldn’t you?), and thus will likely work fine in next version.
- Explicitely underline intentions put in the code through active conventions. An active convention is a rule that will warn if the initial intentions is violated. Thanks to the support of Code Query Language (CQL), NDepend covers a wide range of possible active conventions that can be declared including controlling:
- how the code should be structured (like the UI layer shouldn’t depends on the DB layer or no dependency cycles is allowed),
- how the code should be covered by tests (like, class A should remain 100% covered by tests, even if it is refactored),
- how and where side-effects should occurs (like class A should remain immutable and method M should remain pure),
- how code elements should be named (like interface names should begin with an I),
- how the code can or cannot evolve (like this particular algorithm shouldn’t be changed),
- how quality metrics are ensured (like we don’t want big and complex methods),
- how code smells are prohibited (like we don’t want dead code or non-commented code),
- how tier code is used (like Thread.Sleep(…) shouldn’t be called at all),
- Learn about type immutability
and use this powerful concept.
Parallelizing your code will be then much easier without the necessity to
synchronize read-access to your objects.
Frankly, we are relentlessly
applying these practices to develop NDepend and this really pay off.
This blog is also a
chance to share development difficulties we are facing and the solutions we
found. This goes from GDI+ bugs
or Windows Forms bugs, RichTextBox tips,
framework we are using like Cecil, LINQ details,
or performance tips.
I also did a few book
reviews including C# in
LINQ in Action
and WPF Unleashed.
I doubt you’ll see me bashing a book here because typically, when I decide to
read a software book I try to select the ones that will meet my expectations. More generally, as all of
us, there are tons of things I dislike and would like to complain publicly about. Afterthought,
I think negative talks is giving too much credit to the lame subject and won’t likely interest much readers. Moreover
doing so would let less room to talk about positive stuff.
I plan to continue blogging
this way. You are welcome to feedback any suggestions.