Refactoring is a poorly understood discipline. Most people use the term as a synonym for “changing” or perhaps “changing to address a design flaw”. However, most of what people call “refactoring” is really just “changing design” and it’s usually done in a way that carries significant risk and cost.
The word “refactoring” means “changing the design of code without affecting its external behavior.” There are precise techniques or recipes for accomplishing this and those techniques can be applied with or without tools. The tools just make it easier, faster, and often even safer.
Refactoring, as a whole, is a deep skill that will take most teams a long time to learn and fully adopt. However, like most deep skills, it can be broken into “packages”.
This offering boils refactoring down to its essence and teaches a few core techniques that help a team get in the habit of truly refactoring code when they need to change design. The impact is relatively quick but it’s just the start of what a team can accomplish.
Recommended Program
The best way to kick-start your team’s adoption of refactoring is with a combination of live, expert-led training and coaching. We recommend our Refactoring 1 program, which includes a 3-day course and 2 days of follow-up coaching so the expert can help your team apply this technique to their real work.
Course
This 3-day course covers the basics of Refactoring along with all the requisite underlying theory to make it work, along with the practice required to make it stick.
Topics covered include:
- Why is code so hard to change?
- The importance of design
- Refactoring theory
- Extract Method, Extract Variable, Inverse Operations
- Transformative logic operations
- Split class
- Refactoring to encapsulated variation
The course is interspersed with plenty of examples and exercises to help cement the ideas and practices in the learner’s mind.
Coaching
Afterward, a recommended 3-day coaching package helps learners implement what they learned in their real code using real PBIs to deliver real code the new way. This is usually done in a single Sprint. In this session, the coach will lead the team through applying what they’ve learned to their own code, ideally using real PBIs/SBIs to drive it. The coach will start out doing a lot of the refactoring himself while the team watches. He will then gradually transfer control of the work to the team as they become comfortable with the techniques involved. By the end of the sessions, the coach should be “coaching from the back of the room” – guiding the work the team is doing without actually actively participating in it.
Benefits
Refactoring – true refactoring – completely changes how a team interacts with code. The better a team is at this skill, the more safely they can change and the more designs they can safely change.
While Refactoring 1 won’t turn a team into refactoring experts overnight, it will give them a good start along with a few key recipes and how to use them. When someone is truly skilled at a refactoring recipe, they feel safe applying it even to code that has no tests.
After attaining proficiency, the team will have the skills required to safely decompose both large methods and large classes, encapsulate functionality behind an abstraction, and perform transformative operations on a method’s internal logic.
These are all the skills you need to begin refurbishing legacy code and, indeed, one application of these techniques will be to change the design of legacy code in order to make it easier to write tests for it. However, the benefits go far beyond that.
This will fundamentally change how your team(s) approach(es) updates to code that necessitate design changes. While they may have been shy about doing something like that, before, on account of the risk, they will begin to be more open to the idea. They will stop being victims of past decisions and take a proactive role in the structure of your codebase.
This is the first step toward a truly evolutionary approach to the design of a software product.
A side effect of being able to complete design changes safely will be an increase in output as a result of the team making fewer mistakes and doing less rework.
Risks
Time to proficiency may create some additional capacity loss but, most likely, it will express in the form of mistakes. The team may make some errors, thinking they are applying safe, transformative modifications to design but not fully or correctly following one of the recipes.
Once the team learns to pair program and hold each other accountable for the core principles of refactoring, this will go away. You may need to plan for additional capacity loss or testing requirements during this period of overconfidence.
Prerequisites
none
Enablers
none
Other Assets
In addition to the course and coaching, your team will get access to the following downloadable assets:
- The source code used in the course to be used in code katas, later.
- An exercise workbook that can enhance the exercises and be used to turn the exercises into code katas, later
- A snapshot the solution to each coding exercise
- A 70+ page refactoring “cheat sheet”, with an explanation of each refactoring recipe shown in the training
- Our JetBrains pattern library, which can be used to automate several of the refactoring recipes we show
