Archive for September, 2007
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.
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.
For those of us in the *nix space the whole SCO debacle has been going on for years. They claimed that they bought what was UNIX (UNIX actually does not actually exists as a technology really anymore and is more of a family of products now) and that all sorts of linux distributions stole code from it and were therefore violating copyright infringements. They then seemed to put all of their energy and money into suing distributions of (usually) free.
While I can see where they are comming from that it was their code but then they started to sue everyone they could which is not a very friendly action towards the open source community and really angered a lot of people.
In a supprising turn of events it turns out that Novell actually owns the UNIX copyrights so SCOs lawsuits (which it won some big money) are null and void meaning they have to refund all the money they weaseled out of people (in my opinion). So in a not so supprising turn of the SCOtanic they have filed for bankrupcy protection.
Novell says they will not sue people for using code that is 15 years old and really wants to encourage the Linux community.
An article was out in the Edmonton Journal this weekend about the current project I am doing part of:
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.