Sunday, June 1, 2014

Lessons learned from reading Martin Fowler's "Refactoring" book

 A few rules of refactoring
 1. Refactoring should not change the output of a program. It should only change the structure of the code.

2. The code you're about to refactor should have tests in place before starting. Tests should then be ran after each small refactoring step.

3. Because of schedule constraints it's often best to "nibble around the edges" instead of diving into a big refactoring. 

4. Before starting a coding task (feature or fixing a bug) refactor the area you're going to be working in, then make the change.

Knowledge found here that was found in other places
1. Duplication is bad

2. Write code with clear intentions. 

3. Comments should explain why, not how. The code explains how.

4. I started reading another book at the same time as this one called Head First Design Patterns. I saw several patterns achieved as the result of refactoring. This means in existing systems design patterns should be strived towards. 

Refactoring catalog
Too many to copy or comment on.

No comments:

Post a Comment