XPSD Meeting Minutes Oct2
|
MercilessRefactoringDemoPartINotes
Summary:
1) you do not have to understand all of the code to refactor it.
You can refactor bits of it at a time.
2) Look for "low-hanging fruit"
Refactor those bits of code that are simple and straightforward. If you feel anxious or uneasy about refactoring it, don't do it. Look for some other part of the code to refactor or write Unit Tests.
Look for simple sequential lines of code to be extracted into a "void fn(void)" kind of method. These are relatively safe to do.
Look for code you immediately understand. Refactor it first. Refactoring leads to simpler remaining code which makes the it easier to understand. And so on...
Look to simplify control flow, e.g. untangle nested ifs, convert while() into for() if possible, etc.
3) Write Unit Tests
If you can not find any simple things to refactor, write Unit Tests.
If you are having trouble understanding some code, write Unit Tests.
When you are in doubt, feeling anxious, uneasy, or just plain scared, write Unit Tests.
Use Unit Tests as a diagnostic tool, an x-ray machine-like tool that you can use to look at the code as it runs. Like an x-ray, a Unit Test leaves a permanent record of what you found out (unlike a debugger session).
4) Verify your Unit Tests
Imagine you are about to refactor a bit of code. You think it's safe because you have a Unit Test around that piece of code.
You can verify that your Unit Tests are valid by temporarily introducing a bug in the code under test. The bug should cause the Unit Test to fail. If it doesn't then add a new Unit Test.
Once you have a failing Unit Test, undo your temporary bug and the Unit Test should pass.
5) Look for clues left behind by other developers
Developers have an intuitive sense of code that "belongs" together. Usually you will find an extra blank line or two before and after the bit of code. You may also find a comment preceeding it.
These lines are usually prime candidates for an Extract Method refactoring.
6) Look for lines of code enclosed within statement blocks
In C/C, C#, and Java look for lines of code inside braces { }. They are usually (not always!) strongly associated and are prime candidates for an Extract Method.
7) Extract Method, Extract Class
These two refactorings are the tools of choice for gross-level refactorings. They move the code the greatest distance and to the most likely final resting place.
Use these two refactorings to get the code in a more-or-less good state. Then you can do a final polish, using the refactorings listed in Martin Fowler's book "Refactoring" and on Joshua Kerievsly's site www.industriallogic.com.
8) Typical Sequence
i) extract a few lines of code into a method
ii) refactor that method mercilessly
iii) look for duplication:
- look for similar lines to the method you just extracted
- if you've extracted a conditional into a method, look for the conditional and it's negation
iv) repeat
9) Pause and Understand
Every so often, take a step back, look at the overall glob of code. Look for:
- similar data and code structures.
- strongly associated data
- strongly associated lines of code
- patterns or symmetries in the data and code
- look for methods with similar signatures
e.g. 4 methods all pass the same two parameters, could this be a class (the parameters are it's member variables)?
- look for methods with similar names
e.g. SearchLeftList?(), SearchRightList?(), could this really be two instances (Right and Left) of a class that have a SearchList?() method in it?
10) Encapsulate
Use OO encapsulation! It is an extremely powerful feature of OO and leads to tremendous gains in simplicity and readability for very little effort on your part.
If your language supports it, make as much of the interface private. Make all the data and methods private, recompile and only make as much of the data and methods public as required to remove the compiler warnings. All the remaining methods are either privately called or are dead code.
11) delete all dead code
There is Joy in the Delete Key. Be one with the Key.