[devnexus 2024] refactoring after fowler: some large refactoring patterns

Speakers: Aaron McClennen & M. Jeff Wilson

For more, see the 2024 DevNexus Blog Table of Contents


This talk inspired by books:

  • Fowler’s Refactoring
  • Kerievsky Refactoring to Patterns
  • Gamma (Gang of Four)
  • Feather’s working effectively with legacy code

Refactoring

  • Restructuring code without changing behavior
  • Purpose of computer language is to tell other programmers what to do. The computer uses ones and zeros
  • Make it work, make it right, make it fast
  • If put it off, will never have time
  • Code smallers to remove – showed screen of examples
  • Refactor to reduce WTF/s minute rate in a code review
  • SAFe 11. 4 “refactor to support the new behavior of the code” – one of the built in quality practices
  • Do when need to change code, bug hard to fix, need to reduce tech debt, etc

Staying safe

  • Want high test coverage
  • Start small
  • Proceed incrementally
  • Test after each change. Undo last change if fails
  • Use tools like Veracode and Sonar to find code that needs changing

Simple Example

  • Need to add a flag.
  • Introduce Parameter from Fowler.
  • Showed how adding another flag is trivial

Planning a refactoring

  • Think about like planning a trip.
  • Decide trip is necessary – overcome inertia
  • Scratch refactoring from Feathers – do a refactoring to get familiar with code and revert when done. Helps figure out what to do, Think of as “exploratory refactoring”
  • Select a destination – Understand what would like it to look like
  • High level refactoring plan
  • Refining the route – more details
  • Make it so

Example

  • Showed method with two parameters – a dto and interfaces
  • Showed Template Method Pattern
  • Plan make a base class, turn implementations into subclasses, remove interfaces and stop parameter passing
  • Refine plan: map to concrete steps like drop the interface and stop using the interface. 13 steps to do the four higher level steps

My take

The intro felt very long. Would have been nice to see if audience needed an intro to refactoring. First example at 20 minute mark (for the Fowler example) and 23 minute mark for first mention of planning for large refactorings. I was speaking after and left early to get ready. So I suspect I missed some of the best parts. I was expecting more of it to be about patterns. The part I saw was too easy for me.

Leave a Reply

Your email address will not be published. Required fields are marked *