Table of Contents
What is refactoring and why do we do it in agile
When we are talking about refactoring, we are really referring to all the changes that we make to the structure of our code in order to improve it. For example, when you comment out a line of code, this is an act of “refactoring”, as no actual line has been deleted, just the line of code. In agile we refer to these changes as “refactoring” and this reflects the fact that we are constantly making changes to our code without actually throwing it away and starting from scratch.
I am sure you have written a piece of code that looks something like this:
public class Account { private int m_balance; public void withdraw(int amount) { if(m_balance >= amount) { m_balance -= amount; System.out.println(“You have withdrawn ” + amount + ” from your account”); } else { System.out.println(“You do not have enough funds to withdraw ” + amount); } } public int getBalance() { return m_balance; } public boolean isAuthorizedToWithdraw(int amount) { return m_balance >= amount; } public void setBalance(int amount) { if(m_balance == amount) { return; } m_balance = amount; System.out.println(“You have deposited ” + amount + ” to your account”); }
… and then we see that the API has changed. We now have a new method called withdraw :
The benefits of refactoring
These are some of the benefits of refactoring that you can achieve with agile software development:
1. It can help with improving the design of the system, which will make it easier to maintain in the long term.
2. With refactoring, you can get more visibility on your product and understand it more easily. This ultimately leads to a more precise communication with stakeholders on what needs to be done next.
3. Refactoring also helps you stay on top of duplication. When there are many things to do, it is easy to forget about doing them. The accumulation of “stuff that should have been done” can turn into a big problem at the end of the sprint.
4. Refactoring helps you avoid technical debt by making the code more maintainable in the short and long term: you avoid having to throw away working code because it has become too complex and hard to manage over time.
How to refactor your code
Most of the time refactoring is done on a class-by-class basis so that you can’t observe the changes without stepping into the code. The way to start refactoring is to stop and think about what you want to do. Next, try to write some code that does this using TDD. You then run your tests against it and if they are green, you can start to change the code. If your tests fail, then you need to document exactly why they fail and maybe use some refactoring techniques in order to make them pass. Next, do nothing and just let it sit there for a while. Don’t rush off and make a lot of changes over night. Wait until you have had time to think about the way that your code is doing things and make sure that you are making changes which will benefit the application as a whole.
The big mistake is to change the code in a way which will make your tests pass, but at the same time doesn’t really benefit the application. If you are doing that then you are just going to be doing more work to change it again later.
Also when you first start learning refactoring, don’t try and apply all of them at once. Start off by doing a small chunk of the code, which will give you time to see what is going on and hopefully get things running. If you have a class which has lots of methods, don’t refactor all of that at once. Try to keep your tests running as you do so. It is a good idea to test out the code before doing any refactoring with your tests.
The key benefit of TDD is that you can see what you are doing and how it will alter the code structure.
Tips for avoiding common problems with refactoring
When refactoring your code, you need to be careful that you don’t change the functionality of your code as well as the structure. This is easy to do if you have poor test coverage which lots of people do in the initial stages of development. When you have changed your code and tested it you will know whether you have broke what was working before or not. The other thing to be careful of is that when you change your code, make sure that it doesn’t break the functionality of any other part of your system. When in doubt, keep the old code around and just test the new one using TDD upfront so that you don’t break anything else.
==LINK== “Tips for avoiding common problems with refactoring” – [http://anti-patterns.com/refactoring_tips.html]
http://anti-patterns.com/refactoring_tips.html
==LIFE BEFORE TDD==
“It seemed that the really valuable software that I was writing was “common stuff”. It would just make my life easier when I made a change. The real hard problems were more often than not, hard to test. “I could have a couple of developers working for me, each one tackling only a small portion of the problem and they could collaborate on it.” “I wrote code in class hierarchies … this worked well until it didn’t any more. Refactoring … seemed like a good way to improve my code.” “I stopped adding new features and focused on those I had already improved. I tried to refactor the old stuff first, but the costs kept going up. So, I wrote more software.”
==LIFE AFTER TDD== :”We implemented an e-commerce system that solved all of our needs, except for testing. We decided to do TDD for that problem and we’re glad we did.”
Examples of successful refactoring projects
The two examples that were used at the conference as examples of successful refactoring projects were: System#1: A system that was developed to provide reports with two-dimensional map information. System#2: A system designed to correlate video frames of the same scene recorded on different days.
