Learning From Refactoring

by Krishna on June 9, 2007

The longer one works in software development, the more one is exposed to both elegantly crafted applications as well as egregiously designed and coded projects. The learning process involves learning from both good and bad code. Good code can teach architectural concepts, design patterns, code organization and logical ways of solving practical problems. Such code encourages copying and imitation. You are also filled with enthusiasm to create something similar.

Learning from bad code is not as straightforward. You normally have to deal with such code when you inherit an application from some other person or organization. Normally when you see the quality of such code, you don’t waste time reading it. That is, until you have to make changes to meet new business or customer requirements.

At first, you are frustrated because you cannot make any sense of the application. But there is always a method to the madness. As you understand the twisted logic of the original programmer, you start making small changes to the application to help you understand how to push it towards the proposed changes. The reason why you do this is that the entire application is too huge to spend time on rewriting it. You also don’t want to mess around with parts of the system you don’t understand because it may introduce new bugs and an endless cycle of debugging.

Once in a while, though, you get a badly written application where you have the opportunity to learn. A couple of things should ideally fall into place for you to do this:

  • Code Size: It is difficult for one person to start refactoring an application that has many thousands of lines of code written by several people. You want something manageable where the problem itself is not too complex to distract from understanding and fixing the code. At the same time, you want to have enough bad code to refactor, instead of just 1-2 methods. The right amount of code changes from person to person. Also, as you become more experienced, you have the ability to deal with greater amounts of code.
  • Time Availability: More time gives you greater flexibility in refactoring. You can afford to break the application when you make changes. You can devote more time to trying to understand the thoughts and logic of the original programmer. You can play with various strategies for fixing the code, including dead-end ones. Sometimes, one refactoring technique may result in less code, but have a performance penalty.

One particular example in the past comes to my mind. When the code was originally received from an external source, there was no expectation of it being poor as the original developer (doing the hand-off) seemed to talk a lot about design. Apparently, talk was all there was – a fact made clear when the code was examined. The circumstances allowed us to refactor and work with the code for several months. Here are a few of the issues that we discovered and fixed:

  • Inconsistent naming conventions: Various classes, methods and variables were named inconsistently or incorrectly. This made it difficult to follow the code properly. This is an easy problem to fix using the IDE’s refactoring capabilities. But there were also some improperly named database tables that were referenced in the application. That look longer to rectify.
  • Lack of encapsulation: The developer had used several classes, but each one was a collection of methods. This seems to be a particular problem with novice programmers who don’t understand object-oriented programming well, but know they have to “use classes and objects”. A unique thing done in this program was the use of a Hashtable to store individual pieces of data, instead of using a tightly encapsulated class.
  • Copy-and-paste code: Some code was repeated over and over again with just a slight change in a variable or a constant value. I have always been amazed at programmers who do this because it takes just a few minutes to create a parameterized routine and save hours of typing and bug fixing. Some people just like doing it the macho way!
  • Performance problems: There were only a few places in the application that performance really mattered. One of those places had a loop in which an innocent-looking database call was called repeatedly. The only purpose of the database call was to obtain a lookup value from a static table. Replacing that call with a simple hashtable lookup improved performance by 40 times.
  • Improper error handling: Many run-time errors (database exceptions, wrongly initialized objects, etc.) were hidden by simply using a try-catch block with an empty catch. Compiler warnings were also ignored. Upon making the errors visible, it was discovered that the application was really only processing 90% of the records properly, because INSERT SQL queries were formulated using concatenated strings instead of parameters and hence were bombing out because of unescaped characters.

The developer had done a few things right. The user interface of the application was designed well. There was an effort to divide the application into reasonable-sized classes, although the strategy was more functional than object-oriented. Interfaces were used to enforce certain functionality in some classes. The code was formatted properly. All of which meant that at first glance, the application seemed much better than it actually was internally.

This is, of course, an extreme example where there were too many things gone wrong. But that is the point: You learn more when you get such poor code. If your organization has a good control on code quality, the only way you can obtain this experience is by inheriting code from an external entity for various business reasons. In a controlled project, you typically learn only about code intended for one solution and not scaling up to meet a new requirement.

{ 2 comments }

icici March 24, 2008 at 6:56 am

Hi all

i am unable to see my inbox mails after i login

how to slove it

Krish March 24, 2008 at 7:48 am

@icici

Not sure how that question is related to this essay. But I will be glad to help you. Please email me details using my contact form

Comments on this entry are closed.

Previous post:

Next post: