Every Second Counts

Several days ago, I downloaded Cygwin, which is a collection of tools, library, and API that provide Unix-like functionality on Windows platform. Installation is quite easy, we only need to download a small setup file, then run it to further select and download packages we need.

Using Cygwin, we can develop and build applications normally written for POSIX operating system, and run them on Windows from Cygwin shell. This is possible because Cygwin provides DLL that complements Win32 API with additional POSIX-like API, which is called Cygwin API.

I personally use Cygwin to run ProFTPD, because there’s a need for testing my program with Unix-based FTP server. I could have used linux, but I was just too lazy to install linux on my office PC

My first experience with Test Driven Development (TDD) was about 2 years ago, when I worked on a project to develop h.264 codec at my previous company. At first, the notion of creating the test before writing the code seemed confusing. How are we supposed to test the code that we haven’t written yet ? That was the first question that popped into my mind when my co-worker explained the process.

After I actually applied TDD, the idea became more obvious to me. In TDD, because the test was written before the code, it will obviously fail. Our next step is to write the code that will make the test pass. After all the tests pass, it’s time to add another feature, that we state in new tests. These new tests will pass after we write the code for the new feature. This process will repeat until we implement all of the features in our program.

In TDD, this test is called unit test, which verify the correctness of one module or class. This unit test should not be confused with acceptance test, which verify the behaviour of the whole application. Unit tests will grow as we add new class and functionality, and should be run every time we build the application.

One of the advantage of TDD is, as we add new code, we will be informed quickly if the newly added code break the functionality of previous code, indicated by failed test(s). TDD will also help the programmer to think about how the interface of the new class or module should look like. To make the class or module easy to test, it should be made modular and less coupled, which in turn, will improve the design of the whole application.

As a software developer, when I hear the word ‘legacy code’, what comes to mind is code from the past, with functions containing hundreds line of unstructured code which is very hard to understand. If there’s documentation, it usually makes us more confused because it’s never been updated since the first version of the code. In my opinion, understanding and maintaining legacy code is one of the most difficult tasks for software developers.

Although working with legacy code is difficult, it is something we can hardly avoid, because many working systems that we should maintain and enhance, are written as legacy code. Rewriting such systems may be not an option for most organizations we are working at. Clearly, we need some strategies and techniques that will help us conquer the complexity in legacy code. Unfortunately, there are not many books which talk about legacy code, compared to the number of books about designing and programming from the scratch.

When I browse around, I found a very good article from Michael Feathers, Object Mentor, which contained several strategies to work effectively with legacy code. You can find the article in Object Mentor website. From that article, I learn an interesting point that what distinguishes legacy code from non-legacy code is tests. If we write new code without adequate tests, actually we write legacy code. It’s a bit extreme actually, but if you are extreme programming follower, that idea should be familiar. That article then present techniques to add tests to legacy code, which is called test coverings. After that, the authour shows some strategies to make ’safe changes’ to legacy code by breaking some dependencies and add test for each change we make.