DEV Community

Discussion on: How is refactoring discussed at your organization?

Collapse
 
peerreynders profile image
peerreynders • Edited

Martin Fowler:
"As soon as you talk about refactoring or attention to good design and modularity in terms of professionalism and keeping your code clean and all that kind of stuff you've lost. As soon as you try to make this argument you're screwed. This argument you want to ignore, get rid of it. Instead focus your argument on simple economics: We're doing this to be able to deliver more functionality more quickly. That's the only reason you should be refactoring".

J.B. Rainsberger:
"The only reason to refactor is to reduce volatility of the marginal cost of a feature."

Kent Beck:
"for each desired change, make the change easy (warning: this may be hard), then make the easy change"

Make it work, make it right, make it fast

Red-Green-Refactor:

  • Red: Write a failing test that verifies expected outputs for a fixed set of inputs.
  • Green: (Make it work) Write whatever horrible code is necessary to make the test pass. Write code to help understand the full scope of the problem.
  • Refactor: (Make it right) Formulate the solution now that you have a better understanding of the problem with working tests as a safety net.

People are still referencing Working Effectively with Legacy Code (2004) today

FYI: Michael Feathers is a classicist so he doesn't use mock objects buts relies on wrappers and fakes; some people are under the impression that lack of mocks is a sign of an outdated methodology; in fact it's different schools (Detroit/Chicago (1999) vs London (2000)) of thought - in fact proper use of mocks is a recurring topic of controversy.