All Segments
Martin Fowler @ OOP2014 "Workflows of Refactoring"
14 segments available
Over the last decade or so, Refactoring has become a widely used technique to keep a high internal quality for a codebase. However most teams don't make enough use of refactoring because they aren't aware of the various workflows in which you can use it. In this keynote talk from OOP 2014 in Munich, Martin Fowler explores some of these workflows: such as Litter-Pickup Refactoring, Comprehension Refactoring, and Preparatory Refactoring. Martin also reminds people why common justifications for refactoring will sabotage your best efforts. (This talk also has a treatment as an infodeck.) More information about Martin Fowler: www.martinfowler.com More information about OOP Conference: www.oopconference.com
Segments Timeline
The Keynote Kickoff
Martin Fowler introduces his keynote at OOP 2014, addressing concerns about repeating his previous talk. He explains his approach of delivering two new short talks instead of one long one, setting the stage for his discussion on workflows of refactoring.
"[Applause] When I was asked to uh give a keynote this time and I sent in the details of my talk, the title and the description um people were a bit alarmed because they said, "You spoke here two years..."
Understanding Refactoring Workflows
Fowler discusses the importance of recognizing various workflows for refactoring in software development. He highlights that many teams miss opportunities for refactoring due to a narrow view of when it is applicable, emphasizing the need to capture different situations where refactoring is beneficial.
"me when they all go completely wrong. So for the first talk I'm going to talk about workflows of refactoring. And I started thinking about this from conversations with various of my colleagues and fro..."
The Red-Green-Refactor Cycle
In this segment, Fowler explains the common cycle of test-driven development (TDD) involving red, green, and refactor phases. He describes how developers typically add a failing test, implement functionality to pass the test, and then refactor the code to improve its structure without changing its behavior.
"Now for many what seems to be the most common case that people talk about doing refactoring is in the context of the cycle of testdriven development. You've probably seen this many many times. People ..."
Two Hats of Programming
Fowler introduces the metaphor of 'two hats' in programming, distinguishing between the modes of adding functionality and refactoring. He emphasizes the importance of focusing on one mode at a time to maintain clarity and effectiveness in the coding process.
"that's there. And you might wonder or many people might wonder why do we separate out the two steps of of writing the code which is making it work and making it clean. Why do we think of those as two ..."
The Rhythm of Refactoring
This segment delves into the distinct rhythms of adding functionality versus refactoring. Fowler explains how the mindset during refactoring is about preserving behavior while improving internal structure, and how this differs from the mindset of introducing new features.
"refactoring and typically done on top of a a test suite that you're able to run regularly as you go so that you're able to detect if you make any mistakes. When you're refactoring, even if you're comi..."
Embracing Opportunistic Refactoring
Fowler discusses the concept of opportunistic refactoring, where developers should actively address messy code as they encounter it. He argues that maintaining a high standard of code quality is essential to combat the natural entropy in software design, encouraging a proactive approach to refactoring.
"And obviously within the test-driven development cycle, that's the separation between these two parts where you're touching your production code. At the beginning stage, you're adding function. In the..."
Litter Pickup Refactoring
In this segment, Fowler introduces 'litter pickup refactoring,' a metaphor for cleaning up code as you encounter it. He discusses the Boy Scout rule, which encourages developers to leave code cleaner than they found it, highlighting the importance of making small improvements over time.
"You have to have a conscious counterforce. And one of those counterforces is an intolerance for stuff that does is just not working right. It may have been fine two months ago when you wrote it. Um bu..."
Comprehension Refactoring
Fowler explains 'comprehension refactoring,' which occurs when a developer gains a new understanding of complex code. He stresses the need to document this understanding through refactoring to ensure clarity for future developers, preventing knowledge loss.
"try to make it at least a little bit better. At least a small improvement. And then if it's code that you're regularly hitting over time, multiple small improvements will make it really quite nice. Bu..."
Integrating Refactoring into Workflows
Fowler discusses the importance of integrating refactoring into regular development workflows. He advises developers to address code issues immediately when they arise, rather than treating refactoring as a separate task, to maintain code quality and efficiency.
"to spend time figuring out how it works. Figuring out how something complicated and and not easy to see works. That's a good thing in a detective novel. It's a bad thing in code. So, make sure that yo..."
New Insights Triggering Refactoring
In this segment, Fowler highlights how new insights about code can prompt refactoring. He illustrates the frustration developers feel when they realize that existing code could be improved to accommodate new functionality, emphasizing the need for ongoing refactoring.
"work. Another trigger for refactoring is when you look at some code and you realize, I've now got a new insight about how the code could work that I didn't have before, particularly in the context of ..."
The Case Against Planned Refactoring
Fowler critiques the practice of planned refactoring, arguing that it often indicates a failure to integrate refactoring into daily tasks. He believes that a well-functioning team should continuously refactor as part of their regular work, making planned refactoring unnecessary. This segment highlights the importance of maintaining a clean codebase and suggests that developers should focus on small, incremental improvements rather than large, planned refactoring efforts.
"refactored code base. Now, a lot of people complain about refactoring taking time away from other things and slowing you down. Um, which as I'll point out in a moment is is definitely not the case. Bu..."
Long-Term Refactoring: Gradual Improvements
Fowler discusses strategies for long-term refactoring, emphasizing the need for a vision of the desired codebase state. He advocates for a gradual approach, where developers make small improvements over time rather than attempting large-scale refactoring all at once. This method not only keeps the code stable and ready for deployment but also allows teams to learn and adapt as they progress towards their goals. The key takeaway is to break down changes into manageable steps for effective refactoring.
"refactoring. Now this of course presumes all of this kind of presumes something which is it kind of assumes that you have refactoring tasks that you can always complete in a relatively short period of..."
Why Refactoring Matters: The Economic Argument
In this segment, Fowler addresses common misconceptions about refactoring being wasteful. He argues that refactoring is essential for maintaining a clean codebase, which ultimately allows teams to deliver functionality more quickly. He emphasizes that the justification for refactoring should focus on economic benefits rather than professionalism, making it easier to communicate its importance to management.
"was just reworking stuff. It was an indication that you'd failed. It was waste. The reason that I feel that refactoring is important comes down to something that I refer to as the design stamina hypot..."
Refactoring as Professional Responsibility
Fowler concludes by asserting that maintaining a clean codebase is a professional responsibility of programmers. He argues that only those working within the codebase can assess its quality and the impact on productivity. This segment reinforces the idea that neglecting refactoring can lead to inefficiencies, ultimately costing customers more time and money.
"design and modularity in terms of professionalism and keeping your code clean and all that kind of stuff, you've lost. Soon as you try to make this argument you're screwed. This argument you want to i..."