Refactoring

Dawn of the dead

One of the problems with the code base that we’re refactoring is that it’s full of dead code. This week we dealt with it… Throughout the system there were swathes of code that were commented out, there was very little in the way of explanation as to why the code was not currently required and when it might be required again. It may have been old code that wasn’t required any more, or was broken or new code that wasn’t finished yet, or was broken.

On Cringely On Refactoring

Bob Cringely has been upsetting some programmers with his comments on refactoring. Initially, he had this to say: “Cleaning up code” is a terrible thing. Redesigning WORKING code into different WORKING code (also known as refactoring) is terrible. The reason is that once you touch WORKING code, it becomes NON-WORKING code, and the changes you make (once you get it working again) will never be known. It is basically a programmer’s ego trip and nothing else.

The Joel Test

Joel Spolsky has a quick test to rate how good your software development process is. I thought it would be useful to see how the refactoring project scores. 1. Do you use source control? Yes. The main part of the team has always used CVS for source control and do it properly (tags, branches, all kinds of stuff). This project’s lead developer didn’t believe in source control, but eventually the rest of the team dragged him into the light.

Understanding bad code

I always used to think that there was probably a good reason behind things I didn’t understand. Now I’m far quicker at deciding that the reason is that the person who created the thing didn’t understand either. I’m currently working with a client to aid in the handover of some source code from the original developer to the rest of the development team. An unusual project because the original developer is still around for a while.