[I decided to go a little light hearted today... When I get done writing for How To Select, I'll take some time and post an entry with Code... until then..]
I was thinking today about one of my skills (at least I think its a skill). Recently I have had to touch a couple projects that the developer was no long since gone. In one case I needed to fix the
remaining bugs on a project done by a consultant whose contract was over and whose project still had a few bugs. I used a method that I have heard mentioned here on CodeBetter... refactoring to patterns. At first I had no clue how the app worked. The app was originally all in a single module with a couple rudementary classes (no properties and mostly no methods). I started by creating a few different classes with nothing but static methods so that I could organize the code. Once I had done this I began to look at the various modules and found things that were common (so they could be refactored and simplified). After this round of mostly reorganization I started to understand the application. I was now able to really refactor the app (by moving even more things into separate classes/methods). Finally I was able to understand the app enough that I could find the bugs by following the process flow. The consultant missed a few things in his logic. Actually an important item, so I had to create some new code to better handle his flow. I was not overly intrusive in this; I decided not to waste a lot of time rewriting everything, just the portion that was problematic. I guess in some respects I'm embracing XP.
I've also had times in the past where I was called upon to figure out why. Why does this person's -- who is no longer with us -- code crash all our web servers. Why does it corrupt the database? Etc. Like the TV show, CSI, how many of you are Coding Forensic experts?
Print | posted on Tuesday, June 28, 2005 2:24 PM