- The next one to prove the first is wrong
- Choose a name inline with the concept in the domain.
- Good OO code names concepts, not worried about implementation
- Terseness is cleverness (not goodness), stop picking on each other for being simple.
- Smallest change you can make to prove the last test insuficient.
- Solve the easy problems first, then maybe the hard ones become easy.
- DRY is good, but sometimes duplication makes sense, if it passes the inebriation test, check it in and walk away
- Open/Close Add new features without adding new code
- lean on the green
- first implement the Null object
- Write code such that you can refactor it when you're drunk
- "Inline method refactoring", take your conditionals and put them back inline, in place of the callers.
- sunk cost falacy: staying in a bad movie because you paid for it
- There are hidden concepts in the domain. Leave them hidden if they don't matter. To implement new features it may be important to refactor them out.
- Pick two strigs that are most alike
- Find the smallest difference
- Make the smallest change that will removes the difference.
- Parse: run code, check for errors
- execute without using result
- execute using the result
- delete unused code
- If you go red, undo.
- Only change one line at a time.
- The only exception is when defining a method.
- Is this open to the requirement?
- Do I know how to make it open to the new requirement?
- Make the smallest change to improve OO design.
expose the max info about the domain, without regard for duplication There are abstractions I don't understand with the most intention revealing way
- Martin Fowler, code smells