Code Library

Consider the classic definition offered by Fred Brooks in The Mythical Man Month of what happens as a software system is modified over time.

All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress.

Fortunately, since 1975 when Brooks first wrote this, our industry has learned ways to modify systems such that the system does not decay further with each modification. The ability to modify without introducing decay is essential to Scrum because Scrum teams build products incrementally. As Ron Jeffries says, "In agile, the design simply must start simple and grow up. The way to do this is refactoring."

Refactoring refers to changing the structure but not the behavior of code. Let me give you an example. Suppose a programmer has two methods that each contain three identical statements. These three common statements can be extracted from both methods and put into one new method that is called from both of the old locations. This refactoring (formally known as extract metlwtf) has slightly improved the readability and maintainability of the program because it is now more obvious that some code is reused and the duplicated code has been moved to a single place. The structure of the code has been changed while its behavior has not.

Refactoring is not only crucial to the success of TDD, but it also helps prevent code rot. Code rot is the typical syndrome in which a product is released, its code is allowed to decay for a few years, and then an entire rewrite is needed. By constantly refactoring and fixing small problems before they become big problems, we can keep our applications rot free. Robert C. Martin calls this the Boy Scout Rule.

The Boy Scouts of America have a simple rule that we can apply to our profession: Leave the campground cleaner than you found it. If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot.



"If they wrote it right the first time , they wouldn't need to refactor now."

This is kind of like saying, "If Toyota built better cars, they wouldn't need oil changes, new tires, or any maintenance ever." Applications will need maintenance; refactoring is choosing to do it a little at a time when doing so is cheap. Most of the managers or product owners I've met who take a "you aren't allowed to refactor" stance do so because teams have abused the ability to refactor in the past. A typical example is the team that reserves the last three days of every tenday sprint for refactoring. Another is the team that tells its product owner, "No, w e can't do that important feature this sprint because w e need to refactor what w e wrote the last sprint." If the whole team needs three days to refactor every sprint, that's a sign of different troubles. If the team has planned refactorings that are so large they have to turn down features the product owner would like included, the refactoring probably belongs on the product backlog itself.



THINGS TO TRY NOW
• Start a refactoring backlog of all the things you want to clean up. If the team is collocated, simply write it on a big sheet of paper hanging somewhere. If not, use the electronic equivalent. You want the list to be as informal as possible. The goal is to fix all the issues and then destroy the list. Institutionalizing the refactoring list in a custom-built database w i t h a custom web client, RSS feeds, and iPhone support will encourage the list to remain forever.

• Learn the refactorings that can be performed automatically by your integrated development environment.

• When a refactoring opportunity is identified, have team members write it on an index card. Post the cards in a small, delineated area on a wall in the team room. As the area fills, feel mounting pressure to complete one or more refactoring.

• At the end of your next two-hour-long programming session, spend 20 or 30 minutes cleaning up something you noticed as you were touching or looking at existing code.

• During your next retrospective, facilitate a discussion about refactoring with your teammates, including the product owner. At what threshold should refactoring switch from a personal decision to a whole-team decision? Clearly, I can rename a poorly named variable I come across without a t e am discussion. What if the developers come across a two-day change; can they just make it, or does the product owner need to approve the effort first?

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010