Jeremy D. Miller just put up a really good post on some fundamentals. Check out the post here

I got my wisdom teeth taken out on Wednesday and decided to read my new copy of “Working Effectively with Legacy Code” by Michael Feathers. To sum it all up…. I would rather have my wisdom teeth removed than recommend this book to anyone who has any experience with legacy code.

I found that the book was a wrapper for Martin Fowlers Refactoring with a lot of buzz words like TDD, SRP, OCP, and more scattered liberally throughout the book without much about applying these ideas to legacy code. I think that if you have read Refactoring that you should have lots of skills for dealing with legacy code.

The book seemed very focused on breaking apart dependencies and testing. Granted, tight coupling makes it hard to effectively unit test an application and testing is very important. Other than that the book did not really talk about things I was expecting like some legacy code smells and how to effectively deal with them. Also one huge thing for testing is mocking that was barely mentioned in the book.

Part II of the book is broken into questions that I will summarize with my answers to these questions:

1. I Don’t Have Much Time and I Have to Change it

You probably have no time because you keep rushing through things and creating bugs. If there is not enough time then tell your boss that you need more time to get it done right!

2. It Takes Forever to Make a Change

You are probably a crappy programmer and should consider a career change.

3. How Do I Add a Feature?

Seriously? This is a problem people run into? How do I add a feature? WRITE SOME CODE!

5. I Can’t Run This Method in a Test Harness

You should probably learn how to write tests! (Ok I am giving this one a hard time as with dependencies being involved this might not be so easy)

6. I Need to Make a Change. What Methods Should I Test?

You should test everything that could be effected by the change. This is not rocket science.

8. I Need to Make a Change, but I Don’t Know What Tests to Write

Then you probably should ask an adult for help

9. Dependencies on Libraries Are Killing Me

Stop being such an emo kid and man up.

10, My Application Is All API Calls

You should probably add some logic to it then

11. I Don’t Understand the Code Well Enough to Change It

Then you should not be changing it. Find someone who does or write tests around that method until you understand it.

I find that this book fits in that gray area of uselessness. It touches on some good ideas and techniques but really does not get into them enough to be useful. It also does not talk about how to work effectively with legacy code in my mind. It tells you how to get legacy code under test (and I did not think it even did a good job on that).

    At the last edmonton user group meeting I finally won something (besides a t-shirt ). I won a copy of Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams.

    I had heard a lot of good things about this book from others but really had no motivation to buy it. The title is way to exciting and if I leave it out girls might be breaking down my door just to touch it (the book you sickos!). I must say that I was pleasantly supprised with the book and definately think it is worth having a read for developers of all levels.

    The book has lots of good practices in it for more than just
framework developers. I think the name is poor and it should have been
called code/api design guidelines or something to that effect. I found
that a lot of the lessons they talked about I had already learned but
there were lots of other things I had not thought about for how it
would affect future consumers of my code.

    One of the things I really liked is that this book was written and
contributed to by people who wrote the .NET framework. There are little
comments on almost every page that are tips from these people and
several stories about good design items that were put in the framework
and some regrets about things that made it in that were not very
useable. Many good practices that were shown in the book were show in
context of the framework classes that already exist. This was really
good to show a proof that everyone was familiar with.

What I really liked about the book was there were some tips that I read the title of and thought “Why is that a bad practice? I do that!” and then after reading the consequences for every one of those I thought “That is a bad practice! I am not going to do that anymore”. So even though most of the tips I had learned from experience the book helped me avoid some future mistakes and also confirm my existing design decisions from people that have a lot more consumers than my code ever will.

Derik Whittaker had an interesting post about how to access the GAC as though it were a regular file system called Hacking the GAC. A few interesting and different ways were posted that I had never heard of.

The simplest way that I know of is to go start->run and type in c:\windows\assembly\GAC and the cache will open up just like a filesystem.

We actually used this on one project where we could only use third party assemblies on the clients network. What we would do was develop locally (because our net connection in the office was way to slow to remote in all day). Whenever we needed to test we copied our dll’s and pdb’s to the remote systems GAC folder (the strangest xcopy install method I have ever done) and then we could run and debug the application. It was clunky and cludgy but way faster than any other method we could think of at the time.