Constantly Refactoring

Posted by santosj on July 5, 2007

Frequent refactoring can save time and processing in the long run. Once a function, method, or class becomes too long, then it is time to split it up into smaller pieces. By doing so, you create a library which can be reused over and over again, instead of rewriting the same functionality in multiple functions, methods, or classes.

I am finding that there are disadvantages, but I firmly believe that by breaking large components into smaller ones serves the better good. It does increase the time of development and documentation is even more important to keep track of where every piece went. To demonstrate, I’ll discuss recent projects and what I learned.

Read on if you are interested.

Example 1: Email Filter

In a recent project, I came across a filter that I had forgotten where the definition was and why I had it there. Without comments, I thought it appeared to be like another filter I had created, but the definition didn’t match correctly.

After I while I remembered that it was there in case the issue with long subject lines in email. Some mail agents don’t allow subjects longer than 78 characters, erroneously, since the max should be 998 characters. I had placed the filter there in case the issue ever came up, I’ll have the mechanism in place to quickly fix the problem. Need to remember to comment that piece of code tomorrow or complete the filter.

Example 2: Subscribe2

I did contact the author and submitted my changes, but I’m not going to release the change since it would create an additional version. I don’t feel that having two branches would benefit anyone. Also, there were complications in the code.

I spent a while refactoring the Subscribe2 plugin to split the Singleton into multiple smaller classes. I was able to get a portion to correctly work, but other features did not. I could have spent even more time fixing the broke parts, but it would have taken more time testing than it was worth.

The maintainer of the plugin didn’t like the refactoring either, so that convinced me to take another approach to the issue. The problem was that I wanted to add or change certain parts of the code, but GPL would require me to release the changes. It would be better to use filters and actions to modify strings and methods than to try to find the code and modify it manually. If the filters were documented correctly, it would take less time to write a filter or action than it would be to track down the piece of code to modify or add a feature.

Currently, it is up to the maintainer to decide what he wants to do with it. I still have a few more areas I want to work on before I’m finished, however my priorities have since shifted. I’m putting off any more refactoring until later.

Example 3: Untitled Project

The first iteration was okay, but I was unhappy with how it had to be implemented. It is stable, well tested, and works. I was able to quickly step through a couple of projects with few modifications to the original code. Those projects did not warrant spending the extra time to implement the changes I wanted to make.

I came across a better way of implementing the feature, while researching filters and actions. The project required a little bit more involvement, so I decided to finally implement the refactoring. It is actually going faster than I had thought and can be reused in its current form for any sort of project.

Reusing the first iteration code, has made the progress of the second permutation go faster. The issue is that I have to make sure that everything worked the way it did before. The changes need more testing to make sure there were no regressions in the previous feature set.

I am happy with what I have implemented so far, the changes will make manual editing, in most cases, not needed. Most of the functionality for actions is placed in multiple functions and uses actions, filters, and options to manage customizations. Adding the implementation is also easier and quicker than before. The previous requirement that increased development time (by a small amount) has been removed.

Whereas the first version required hand coding every change, the second requires very little. Where code was duplicated over many different places in the first version, the second version does not and has enough specialized methods that refactoring is made easier.

While it has been longer, than if I had just kept the original code and hand coded the changes. I believe in the long run that the current code set is worthy. Well, at least until I find some better method.

Possibly Related Posts:


Projects

2 Comments.

Trackbacks and Pingbacks: