>Cramps on Refactoring

>There have been several fairly interesting posts floating around about coding lately. From Ed Merk’s “Teflon Programming” article to an article about whether it is better to return immediately or have a single return (sorry I lost the blog article link). I also recently blogged about whether there needs to be more java docs for internal api. In many ways, these articles may not seem related, but really they have a common underlying theme. Refactoring.

I thought I knew what refactoring was, until I recently read Martin Fowler’s book, “Refactoring: Improving the Design of Existing Code”. Refactoring is not changing code and cleaning up methods. Refactoring is about making existing code that is already working, better, cleaner, easier to maintain, and possibly smaller foot print wise. Unit testing plays an important role in this process. The overall functionality still works as designed, and the public classes and methods are the same from an interface standpoint.

The most important point about Refactoring is that it doesn’t break existing functionality and that this is determined by having Unit Tests to verify that functionality. You make small changes, and test. In the book is a list of Code Smells. These were documented in 1999, and are still relevant today. There is also a list of common refactoring patterns that can be applied to fix issues.

Refactoring doesn’t have to be something that is a stop everything for several weeks and refactor the code, it can be included in the daily work. If you work on a bug, make sure there is a unit test for the bug. If you are in some code that just reeks like a “Long Method” smell, take a bit of time to refactor it so that it is easier to understand.

So, if every eclipse project took some time to apply a handful of refactorings several things would eventually occur:

  • The code would have a larger and wider number of tests for the existing functionality.
  • The code will become easier to maintain and enhance.
  • The number of lines of code will shrink.
  • The memory footprint of eclipse as a whole will shrink.
  • Some possibly cool new refactoring features would be added to JDT to help with the refactoring of eclipse as a whole.

Some signs you may have eclipse code that needs refactoring:

  • You dread going into certain classes or portions of the system to fix a bug.
  • The code as is currently designed can’t be tested or you don’t know how to test it.
  • There are lots of comments through out the code explaining what sections do.

It is our responsibility as committers to make sure that we are writing maintainable code. If somebody from the community is having a hard time understanding what the code is doing, then the code isn’t as cleanly designed as we might have thought. Take a few moments, enhance the design and maintainability of eclipse, and help make it easier for the community as a whole to maintain. Who knows you might be the person that has to maintain somebody else’s “Long Method” smell in the future.

Martin Fowler maintains some resources on refactoring.

Resources on Refactoring.

Advertisements
This entry was posted in agile, eclipse. Bookmark the permalink.

One Response to >Cramps on Refactoring

  1. >I’d wanted to blog about this for a long time, but never had time to really get down to it.I think you’ve raised some really good issues here, that we as a community should try to answer.I’m myself really frustrated with the entire quality of the code that eclipse ships with. It works, it’s just that it could be far better, cleaner, testable and readable.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s