Succeed With Large Refactorings - The Mikado Method
Session Title: Succeed with large refactorings - The Mikado Method
Submitters: Ola Ellnestam & Daniel Brolund
Abstract:
For any code-base, ill- or well-structured, there usually comes a time when you must change large portions of it to meet new functional requirements, a new business model, or just refactor it to make it read better. But when these change become too extensive, it is easy to get lost in a jungle of dependencies, or on a sea of broken code.
This session will present The Mikado Method, a systematic approach to create a map to your changes, using just pen-and-paper. It helps you visualize, plan and perform business-value-focused refactorings over several iterations, without ever having a broken code-base in the process. It enhances communication, collaboration and learning on a software development team, and it helps any individual stay on track.
The Mikado Method:
Code almost always depend on other pieces of code, hence one change often requires another in an entangled web. When working with software, one usually has to perform a series of refactorings before making the core change to the software, be it to enable adding a new feature or just making a part of the code read better.
This works like the game Mikado (pick-up sticks), where you have to pick up lower scoring sticks in a certain order to reach the higher scoring Mikado stick.
You can build your map of changes using analysis. We would like to present a less demanding way to build the map: 'The Naive Approach':
- You set up a goal for your change.
- Naively implement that goal, as you would wish it to be.
- Compilers, tests, analysis and common sense will then show you immediate problem areas with your naive solution.
- Resolutions to those immediate problems are noted as prerequisites to the goal.
- The current changes are reverted using e.g. a versioning system or undo.
- The prerequisites are now new goals. Repeat 2)-6) for each goal until you find no prerequisites.
- Continue perform changes that have no prerequisites. You will eventually have cleared the prerequisites of other changes that now can be performed. Repeat this step until done, or continue from 2) if you find new prerequisites.
This can be described as a depth-first recursion of refactoring dependencies.
A more extensive description can be found here http://bit.ly/bVa13.
Contents and time line:
This session contains some theory, but focuses mostly on hands-on working with code.
Part 1: Tutorial (30 min)
* Introduction to the method and to refactorings (10 min)
* The presenters demonstrates the method on an example problem, using Eclipse and Java (15 min)
* Q&A (5 min)
Part 2: Dojo: Practice in pairs (60-90 min)
* Repeating the same problem in pairs
* Breaks for reflection and discussion
Part 3: Dojo: Free form (45-90 min)
* Working on code in pairs or randori, using own code or repeating the example
problem
* Breaks for reflection and discussion
Part 1 is essential, part 2 will give hands-on practice and a deeper understanding. Part 3 can be an open space event.
TODO: What are the timeslots available?
Intended audience:
Developers that need to work their way out of messy code while continuously delivering new functionality.
Prerequisites:
Ability to read and understand Java code. Intermediate programming skills in some language. Basic knowledge of refactorings.
Expected benefits:
Participants will get an easy-to-use tool to perform large and focused changes to their code bases. The tool helps to stay on track both over time and in coordinating a team.
|
