The Story so far

It was in the year 2007, when I was asked to do a code review for some of our modules. Code review in this case meant create a document that describes code quality and unveils categories of issues regarding maintainability. It was not the selective kind of code review – tons of code. I thought about what should be in those reviews and how I could automate most of the tasks.
I played a bit with FxCop, wrote rules and applied metrics on what I found. I also searched for code duplications. The process was semi-automated and helped me to point to possible flaws in the overall design. On Roy Osherovs site I found that he embedded his rules into unit tests http://osherove.com/blog/2007/2/24/writing-real-unit-tests-for-your-custom-fxcop-rules.html.

My thought was "The unit testing god proposes to use unit tests for architectural design". His examples were a bit too granular in my opinion. But his article convinced me to add ability for such a granularity to my small tool. Calculate metrics, analyze dependencies on the lowest level possible. By adding an aggregated view the tool really gains flexibility and is improved in its maintainability. But I didn't thought about unit testing with it for a long time. Instead I have added features like code duplication analysis and finding candidates for common gof patterns. I was able to use that tool, but noone else was.

Then in early 2013. We inventoried our current projects architecture. I again used my frickleware tool paired with lot of manual effort. The result was that although we tried our best to follow our own design rules, the dependencies between namespaces diverged from our concept. Is there a way to automatically warn developers when they ruin their architecture?

It called upon my stupid sense for clean code and my will to do something really cool. I invested my spare time to heavily refactor frickleware to a piece of software with stable API and a clearly structured project. When reading again "The art of unit testing" I remembered Roy Osherovs article. Indeed he was right! The developers glue for their software is the automated unit test. Let us apply it to the architecture as well. Run all architecture tests within a few seconds inside the IDE and the integration server and combine them with a disciplined developer team.

On the way from frickleware to DependencyAnalysis I left out a few features. There is no longer a user interface, nor visual dependency graph. This is subject for a suite around the very core DependencyAnalysis is. It will be done later, because there are many tools out there that exactly do this, visualize static analysis. Also code duplication analysis is not part of the first version, though it was an integral part of frickleware. The way it was simple does not fit into the current structure. It will enter the scene again soon. [Update: those features are again part of Egg and Gherkin]

Comparison of related Products

TODO

  1. NDepend
  2. Sonar
  3. FxCop
  4. StyleCop
  5. Visual Studio: Architecture Explorer + Metrics Window
  6. dotTest
  7. JDepend
  8. ArchStudio

Egg and Gherkin is a development tool written in C# to qualify the evolvement of your software architecture within predefined limits. Controlled by the unit test framework of your choice, it gives immediate feedback when breaking architectural constraints.

Last edited Dec 26, 2013 at 12:29 PM by The_eg, version 8

Comments

No comments yet.