XPSD Meeting Minutes Feb6
|
The full presentation notes are in RefactoringDemo?. The handout is in RefactoringNotes?.
- Refactoring changes the design of existing code while leaving its behavior the same.
- Programmers refactor because writing behavior teaches them what design a program is "asking for".
- the code must have fine-grained automated tests; your editor must run them when you hit its Go button.
- find the maximum number of points where you can stop and test.
- if you make a mistake, hit Undo.
- John Brant is credited with naming the practice.
- a "code smell" is a feeling about design's quality, not a perfect metric.
- the demo showed an easy target for refactoring; the 'main' function was 355 lines long.
- The most common symptom is duplication. As a metric for good design, programmers seeking to refactor are learning how wide they can stretch the definition of duplication.
- Apply prescriptions in order from simplest to hardest.
- Your first step identifies the high-level design you want. If you can't see it yet, then you can procede to the second step anyway.
- find the easiest refactor to do that might improve things.
- Repeat with each minor refactor you find.
- The major refactor you may have planned is now just another minor refactor.
- comparison to writers editing drafts (from ''Elements of Style'' by Strunk & White):
- omit needless words
- use active voice
- use parallel construction on parallel concepts
- metaphor: peeling an onion, and seeing what each layer smells like.
- metaphor: Michelangelo Buonarti "refactoring" a huge block of white marble to see what shape it has inside it.
- after Refactoring spend time improving self-documentation.
- the demo showed, before-and-after, converting a large 'switch' statement into a map of function pointers - Replace Conditional with Polymorphism
- 'if' or 'switch' resist change and defy re-use. Code with virtual functions, or function pointers, can look a little more mysterious, but accept re-use and upgrades easily.
- Open Closed Principle: Class's interfaces typically say "use me like this". If a class gets frequent refactors, it starts to say "change me like this". The class is "open for extension, but closed to modifications"
- Some consider Polymorphism the "distinction" of Object Oriented Programming - the way to unambiguously define any system's OO-ness.
- Rename Identifier: one does it >after< the others. When the design's cleaner, then you name it correctly so it self-documents.
- name a variable after its intent. Say "why" the variable exists.
- The "clean the kitchen daily" metaphor. The legendary "cost of change curve" comes from never cleaning the kitchen but still trying to make meals
- the demo showed, in real time, merging two blocks that looked the same. Not by jamming them together, but by finding individual lines within them and merging these into tiny functions. Phlip hit Go after changing only 1 to 3 lines of code at a time.
- He simulated an error to demonstrate the tests catching it, rolled the code back with Undo, and immediately tested again to restore confidence.
- metaphor: Like pulling the arm on a slot machine over and over again. And winning every time.
- discussion of the importance of a visual Green Bar to give you a Pavlovian reflex
- half-refactored code permits the old design to peacefully co-exist with the new design. The tests don't care. You can demo, or even release, before returning to the refactoring sequence.
- Refactoring leads to "many small functions", which may itself be a design smell - the Pass the Buck Antipattern.
- "Contractive Delegation" - many small functions should be adding what they know to their arguments, and passing results to delegating methods. "Contractive", meaning each method takes its arguments and makes them >more< specific, thus >reducing< their degrees of freedom, and >adding< contractual responsibilities. "Delegation" because each small function immediately calls another small function.
- further refactors remove artifacts of refactoring. If A calls B calls C, and if B adds no value, retire B.
- We get layers of "command and control" code, that sends orders out to the "troops". They follow orders without bothering us with the details.
- One of the professional XP coaches has reported seeing another one take code with two parts that looked completely different and declare it was duplication. Then he mutated one part of the code until it looked like the other (testing at each step step of course). Then he removed the duplication. The line count went down.
- If you have lots of little functions, you have lots of opportunities to name things, and make entire statements read like sentences. If you have a choice between one hour writing documentation for your code, or one hour just re-ordering the sequence of methods in a class, you pick the latter.
- conclusion: Refactoring changes the design of existing code!