As already established and addressed in Refactoring 1, 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.
Also established in Design Patterns 1 is the fact that software design is an aspect of your code.
Refactoring, as a whole, is a deep skill that will take most teams a long time to learn and fully adopt. The next step is to be able to introduce certain key design patterns on demand to a codebase that has already been defined.
This offering focuses on exactly that: how to introduce the concepts in Design Patterns 1 safely to existing code.
Recommended Program
The best way to continue your team’s adoption of refactoring is with a combination of live, expert-led training and coaching. We recommend our Refactoring 2 program, which includes a 3-day course with 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:
- Opening (problem: need to be able to introduce patterns into code, later)
- Review
- Refactoring to Strategy (expanded from Refactoring 1)
- Refactoring to State
- Refactoring to Template
- Refactoring to Abstract Factory
- Refactoring to Builder
- Refactoring to Visitor
- Conclusion
- Workshop (introducing a pattern into your code)
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 a real PBIs to deliver real code the new way. This is typically done in the same Sprint as the course.
In these sessions, the coach will lead the team through refactoring some of their existing code to reflect the patterns in the problem that code is supposed to address. It can be done either in service of a PBI or to clean up a “problem area” of the code.
The coach will start off driving and narrating while the engineers watch. He will then gradually transfer control over to the engineers, transitioning from doing the work while they watch to guiding them through the work while he watches.
This will greatly improve the team’s ability to recall and apply the refactoring recipes they learned in Refactoring 2.
Benefits
Refactoring 1 gave your team the tools it needed to begin transforming design. This takes those skills to the next level. The ability to safely introduce one of the six Level 1 design patterns to your codebase allows your team to keep highly maintainable code friction-free as well as make significant improvements to the design of legacy code.
Knowing patterns lets you write code that is resilient to certain kinds of changes. Knowing how to refactor to patterns allows you to take existing code and add that same resiliency after the fact.
Costs
In our experience, the price tag is just a fraction of the cost of one of these transformations. We feel it is helpful to give a full view into the level of investment typically required for this kind of transformation.
There are a number of components to take into account when considering the cost of this program:
- Impact on capacity
- Time to proficiency
- Risks
- Time to results
Impact on Capacity
This will significantly impact capacity during training and immediately after. The team will not be able to deliver anything during the 3-day course and is likely to deliver at 50% capacity during the two days of coaching thereafter. Therefore, when planning costs, you should consider a 4-day loss of productivity directly related to the training & coaching activities.
Time to Proficiency
You can expect your team(s) to stay in the “practicing” phase of adoption for about six weeks.
Risks
It might take a team longer to become proficient if they do not get the opportunities that they need to practice everything in that time period. This risk can be mitigated by specifically seeking out and targeting problem areas of the code that will give the team the opportunities it needs to practice while also cleaning up some messy code.
It is also possible that the teams will struggle to apply the refactoring recipes the first few times and may fail to make transformative changes as they internalize those new skills. That risk is generally pretty low for a team that has already fully adopted the skills in Refactoring 1, though, but extant, nonetheless.
It is wise to budget a little extra time for cleanup of mistakes made while practicing the recipes in Refactoring 2.
Time to Results
Software design is a deep driver for many effects within a software development effort. As such, repairs to software design can take a long time.
Prerequisites
Enablers
none
