Gheorghe Curelet-Balan Blog

Friday, October 24, 2014

Transcript notes on "Workflows of Refactoring" talk by Martin Fowler

Martin Fowler's first part of the talk @OOP2014 "Software Development in the 21st Century" was on "Workflows of Refactoring"  http://youtu.be/vqEg37e4Mkw.

His main idea is that developers are not using software refactoring in all applicable situations. In this talk he identifies what are the different situations when refactoring makes sense.

Below are my time stamped notes of the video in the "@mmss" (@MinutesSeconds) format (time stamps are approximate):
@0110. People are not using refactoring in all applicable situations. What are diff situations when refactoring makes sense

@0205 FIRST refactoring type: TDD refactoring. The most common refactoring scenario is in the red green cycle of TDD. Quickly write working code, then refactor it.
@0350 the need for 2 steps: write / refactor explained with the Kent Beck metaphor of programmer's 2 hats: add new functionality  vs. preserve it but improve code
@0522 other "hats" the developer might wear: performance refactoring and exploratory refactoring

@0730 SECOND refactoring type: Litter pickup refactoring. Fix in small steps the messy code you come by (the Boy Scouts rule). Fight the software design entropy.

@1030 THIRD refactoring type: Comprehension refactoring. Rewrite hard to understand code making it easier
@1300 Question: when find fixable stuff...should I fix it now and how to go about it?

@1445 FORTH refactoring type: Preparatory refactoring. When feel the need to change how code was done in order to add new feature. Good upfront design can avoid this BUT it is hard to do.

@1750 FIFTH refactoring type: Planned refactoring. When refactoring is part of project plan. Good team should NOT have this SINCE if work is broken in small pieces then ongoing refactoring can be done while new features are added

@1930 SIXTH refactoring type: Long term refactoring, WHEN BIGGER issues pop up while getting more into project. Weird dependencies are identified. Fix it in small steps with each iteration

@2210 WHY REFACTOR? Because of ECONOMICS i.e.DESIGN STAMINA HYPOTHESIS. If you don't ongoing care about design then adding new features will be harder: THE CODE FIGHTS YOU.

Labels: , , ,