Code Obsession

I've been using a ServiceLocator class for IoC for the last year and a half. Never really got the point of the containers until the last week. We had a strange API requirement for a component for another group. I didn't agree with it, but basically, they wouldn't let us do constructor or setter injection of the dependencies. Let's not get into that, but lets just say that grabbing StructureMap 2.5 and throwing it into the mix saved me a ton of time. Also, I now get it. The container took what would have been 30-50 lines of ServiceLocator.cs and made it less than a dozen. And they were very clean and easy to read. And since you can initialize the objectfactory where ever you need to, I was still able to test those blocks and get a high level of coverage. I have been using RhinoMocks since I first started TDD and I am pretty fond of it. The AutoMocker in StuctureMap has forced me to shift from the using(mocks.Record()){}... style to the Arrange-Act-Assert style. ...

So after realizing that the 10,000 page book on ASP.NET is better as a reference than as a training guide (seems like someone said that several times before we started this book), we voted on whether to read Clean Code or Refactoring to Patterns next. Considering the make up of our team and the state of our code, I lobbied fairly hard to get Clean Code in front of everyone before we dive into patterns (again). It seems that a lot of our more experienced developers are pretty resistant to reading Clean Code. I think there is a mentality that "the way I do it is right and there is no need to change or improve." I think that is pretty sad. I read Clean Code a few months ago, and it has helped me vastly. It is amazing how much more maintainable my code is now. Anyway, I think that for my team (we have not quite a 3 to 1 ratio of juniors to seniors) we need to have a purpose to our refactoring. Making our code more readable and reducing our coupling seems like a pretty worth...