Pragmatic Refactoring

If we would have realized,we come across these two terms, ‘Pragmatic’ &  ‘Refactoring’ quite often on day to day basis on various scenario’s especially within the computing world. We also get to read lots of classic books on the same. One such awesome book I get to read again and again is ‘Refactoring‘ by Martin Fowler. He exposes various tools and techniques that we need for refactoring and also beautifully explains how and when we should use them for refactoring.
But some of the lessons that we need to learn about refactoring can be acquired only through our experience. When we are working on a real time project as part of the team the term ‘refactoring’ just doesn’t end only with the tools and techniques. There is a need for more pragmatic approach while refactoring.

The following are some of the points that I learnt during the course of my work experience in various companies.  I hope you too would agree with most of my points that is needed to be considered when we decide to go about refactoring a real time project while working as part of a team.

1. As a beginning, always try to answer to the question that why would someone had written a code in a way that needs a refactoring? The quest for finding the answer to this question would help us to identify all the dependencies injected on the code either from internal soruce or from external frameworks/tools.

2. The next step should be to find an answer to another question whether everyone in the team (esp., senior folks) were aware of the code that we wish to refactor? This can be achieved through some casual discussions with the team regarding the functionality and that in turn would give us more insight on details of the current implementation as well as would help us to assert that we are going in the right direction.

3. Its always good to maintain a seperate workspace for all the refactoring work that we do if we find the changes to be bit eloborate. This way we can continue playing with the committed stories without affecting any of the existing functionalities. A too large change or refactoring is no more just a refactoring and can be considered for a open discussion on the changes and probably create a seperate story for the same.

4. Ensure that the interfaces exposed to the public does not undergo major modifications and only the implementation details get refactored. This would avoid lots of unwanted confusion in the team who are eventually using the API.

5. Schedule the check-in of the refactored code during the begining stages of any iteration. This would help rest of the team to start their new stories with the refactored code changes and also would help the QA team to do any regression testing on the changes made and would help them avoid getting loaded with more work as the iteration completion date gets closer.

6. Finally always ensure that the effort we put on refactoring adds equivalent value to the final outcome in the form of productivity etc., How much ever the refactoring is good enough, its better to wait for the right moment for doing this refactoring. Ideally it should be done as a part of the regular story that we are currently playing, rather refactoring some code in total isolation.

Bottom Line: The bottom line for any refactoring is, it should never break the existing functionality no matter what. Regression on existing functionality is something the customers/users of our application would never tolerate.

These were some of the points that I always set as ground rules when I decide to go for refactoring.

Please feel free to add your comment/thoughts on pragmatic refactoring.


About this entry