While at UberConf I had the great opportunity to attend a talk by Venkat Subramaniam titled “How to Approach Refactoring”. The following is a quick summary of his talk and what I took from it.
- Reduce code
- Avoid clever code – keep it simple!
- Make it small and cohesive – single responsibility
- Eliminate duplication – DRY
- Eliminate dependencies – rather than striving to reduce dependencies, strive to remove them
- Write self documenting code – make comments unnecessary
- Code should be understandable in seconds – it is not just about reducing the amount of code, but also about clearly expressing meaning.
- Avoid primitive obsession – focus on creating higher level abstractions
- Checkin frequently, take small steps – every commit should be only one change.
- Shorter feedback cycle
- Other developers are kept in the loop
- Avoid large painful merges
- Keep code at one level of abstraction – each method should do one thing, and delegate to other methods that each do one thing.
When not to Refactor
Never refactor while making any other code change. Take a note of the refactoring and complete it after the bug fix or functionality change has been committed. Never commit a refactoring at the same time as any other code change. If you do break a build, having small, single change commits, will make spotting the problem that much easier.
- When you spot a code smell – take a note of it
- Finish your change
- Never refactor alone. You should always have a second set of eyes on the problem. Pair programming is essential while refactoring. The second person will be their to help ensure we are making the code easier to understand, using good names, and helping to ensure we are not breaking any existing logic.
When to Refactor
- You can refactor before or after a bug fix or a functionality change
- If you think the change will improve the design of the code
- If you think the change will improve the readability of the code for other developers