As a software developer you might have heard the term refactoring. But what does it really mean? How is it different from restructuring or rewriting?
Code refactoring has become an essential part of every software developer. For those who don’t know what refactoring means, it is: “disciplined restructuring of the code without modifying its external behaviour.” Restructuring must occur in small segments measured in minutes with running unit tests in between. Code that you are about to restructure must have proper unit test coverage. Unit tests will validate that you did not modify external behavior or broke existing working code.
If you ever had a chance to rewrite some legacy application and it took you days or weeks, you have done a “restructuring” and not a “refactoring.”
Refactoring is the best pill to get rid of code smells in safe manner. Guided by unit tests, progressing in small steps you are de-risking code changes and getting rid of headaches for developers that will have to deal with the code in the future. Code smells what? Hmm, yeah, code smell is pretty accurate term that represents lack of developers comfort with specific part of code. Something smells, you don’t know where its coming from, but you feel that something needs to be done.
I have always done code restructuring, I have always wished the code was better, easier to read, more rigid, but was I doing the right things? My fellow coworker recommended that I read Martin Fowler’s “Refactoring: Improving the Design of Existing Code” book. That was an eye opener. The technical book is super easy to read and confirmed what I was doing right or wrong while improving existing code. If you are a software developer I truly recommend that you read it.
One of the interesting facts I have learned over the years is that it is not recommended to define a final design during design stage of the application. In fact, you should not bother thinking of every detail of your design. You should definitely have a starting point and start with tests, basic implementation and continue changing and improving your design as you write your code by doing refactoring. During the design stage you cannot think of every singe detail, you don’t know all the requirements and you will be wasting time trying to figure out the best design patterns to use. Do what makes sense at the time and worry about final design later during implementation when you are starting to see full set of details. Do not be afraid to refactor.
Martin Fowler’s book inspired me to do a a Beer and Learn on refactoring and share the things I have learned from the book and during my career in the concise set of slides.
Voice over presentation is shared on vimeo:
The slides were also shared on slide share.