Sunday, May 16, 2004

Rule for Refactoring Code These are the rules I've developed over the years that I follow when refactoring code.  They're rules in the sense that I always regret it if I fail to follow them for any reason. Unit Testing: Don't Even Start Without It.  You won't know your refactoring didn't break the code unless you have unit test coverage of the affected code.  If you don't have that coverage already, add new tests. Keep Each Refactoring Narrowly-Focused.  Don't combine unrelated changes, refactor each one separately. Keep Your Unit Tests Fine-Grained.  If a refactoring involves multiple functions, you're best off having unit tests for each function.  If you depend on a single unit test for a function that then calls the refactored functions, a test failure leaves you not knowing which refactored function failed. Use Many Small Refactorings, Even When It Seems Inefficient.  I prefer making a small refactoring even when I know that a subsequent refactoring will change that same code yet again.  This is critical for refactoring tangled, poorly-written code. Unit Test Each Refactoring.  Don't wait. Refactor Separate Functionality Into Separate Functions.  If I encounter code that combines too much distinct functionality into one function, I try to break it apart into separate, individually-testable functions.  With unit tests for each new function. 5:47:12 PM  comment []

© Copyright 2004 Michael Kent. Last update: 6/15/2004; 4:14:00 PM. This theme is based on the SoundWaves (blue) Manila theme.

Previous/Next