Thursday, March 26, 2015

Strategic Improvement

After soaking for a bit in the bath of refactoring, I took a walk down the road of a major overhaul to some components of one application. The "component" in question is responsible for doing several things - determining whether user entered data from a control should be saved(inserted, updated, or deleted), mapping the values from the control to the data object, formatting the data before saving, coordinating the data updates, and updating contextual data. That seemed like a lot for one class to do, also it is being done in a rather procedural way. Somehow, parts of it are covered with "unit tests".

The tests themselves are not written in a way that was easy to follow, but I eventually got through them and understand what they are covering. There is a specific scenario that we found a defect for which was not covered.

The first approach I took was to get the code itself into a state where it made more sense. I did some reorganizing and a little refactoring. After a bit of this, I understood enough to make the thing a bit more OO. I started down that road and came into some of the more complex behaviors of the system.

Near the end of my allotted time, two things happened - I spent more time than I originally anticipated, and some other work I did earlier to clean up the rotting code turned out to be buggy (in dev still of course).

After a conversation with a colleague about strategic improvement (planned) vs just doing it because it needs to be done(unplanned), I abandoned the effort of making the poorly written and maintained code more OO. I went back to the unit tests and found that a bunch were failing. I fixed those up and continued with a little more reorganization. I added the missing test, made that pass, and now the defect is repaired.

All in all, I'm glad I went down the path I did since it offered a valuable experience and lesson. I learned a great deal about the existing code. This is valuable when we consider strategic improvement. Because I backed out, I didn't have to learn the hardest way - buggy code in qa or worse prod. It may or may not have caused more harm than good, but one thing for sure is that it was taking more time.

If you have the time planned (as we did for this particular case) you can use it to learn a great deal, but don't abuse it. Leave options open. One way to do this is to branch if possible, if not, create new classes and files then hook them into existing code in a minimally invasive way so you can undo the changes easily without affecting existing code. This approach allowed me to bail on plan A and go to plan B when it was clear that plan A was doomed. I hadn't even integrated the changes from plan A into the existing code base yet so it was easy to abandon them.

No comments:

Post a Comment