Next Project

I have been working on one large project for a few years now, and while we have done a pretty good job in keeping the code as clean as possible, there are still some endemic characteristics I would like to change if I were to start over.

No DI Framework
We started with Spring.NET, but then ran into the usual XML problems (renames, namespace changes, ugly factory syntax, ugly generics syntax).  So then we moved to Spring-Recoil, a programmatic abstraction over Spring.NET.  Unfortunately, the following are still painful:

• Missing constructor arguments are run-time errors.
• Conditionally loading containers (DI frameworks are declarative).
• Custom object life cycles.
• Substitution of individual classes within a container (useful for creating integration test harnesses).

Yes there are other DI frameworks out there, but they all still suffer from the above.  While dependency injection is invaluable, using a DI framework is more trouble than it’s worth.  As a coworker recently said: “Spring is training wheels for learning dependency injection.”

Enforce no more than 4 arguments per method/constructor
I picked this one up from Clean Code by Uncle Bob.  This is an easy, concrete way to enforce small class/method sizes and Single Responsibility.  Vastly superior than line count.  A reflective automated test will keep this enforced.

Virtually no mocks
There is no easier way to make a brittle test whose functionality has no bearing on the functionality of the system than mocks.  Mocks are for testing how exactly one object interacts with another.  This not useful information.  I want to know the result.  If there is interaction with another object, and I want to isolate the system-under-test, then I will use a stub, hand-rolled if I need a little functionality.  However, I usually prefer to use as many real classes as possible, as I am more closely matching the functionality of the real system (in which case "unit" testing is not the best label).

Enforce a test class for virtually every class
I have tried to religiously practice TDD, but still haven’t gotten there.  For me TDD is more helpful for ensuring correctness than for design as I rarely come back to a class I have trouble testing.  An automated test to reflect through the code and enforce the existence of a class named $class.name$Tests should do the trick, as I am pretty good at keeping the build green.  For classes where this is unnecessary, I will add a white list.   

Web UI
Google Chrome has recently advanced to the point of being able to provide parity with fat client applications.  SVG, Canvas, WebSockets, CSS3, etc. allow for rich user interaction.  Coupled with the vast performance gains in the WebKit rendering engine and the V8 Javascript engine, Chrome is quite fast as well.  Now that it matches fat clients in terms of speed and richness (in most cases, hardware acceleration is still lacking), the advantages of cross platform and central deployment that thick clients lack make web apps the clear winner.  Note this isn’t appropriate for all applications, but is for the domain in which I work.