Mikado Method

Mikado Method and how to create Mikado Graphs:

The Mikado Method is a systematic approach to facilitate large-scale refactoring and reorganization of code in a software project. It helps developers identify and manage dependencies between different parts of the code, minimizing the risk of breaking the system while making changes. The method is particularly useful when dealing with legacy code or complex systems that require significant restructuring.

Creating Mikado Graphs:

A Mikado Graph is a visual representation of the dependencies and tasks involved in the refactoring process. It helps you keep track of the changes required and the order in which they need to be implemented. Here’s a step-by-step guide to create a Mikado Graph:

  1. Identify the goal: Define the refactoring goal you want to achieve, such as improving code structure, updating a library, or implementing a new feature. Write the goal at the top of a blank sheet of paper, whiteboard, or digital drawing tool.

  2. Try the simplest solution: Attempt to make the desired change directly in the code. If it works without causing problems, you’re done. If it introduces issues or breaks other parts of the system, proceed to the next step.

  3. Add prerequisites: Identify the issues that need to be resolved before implementing the change. These are your prerequisites, and they should be represented as nodes in the Mikado Graph. Draw arrows from the goal node to each prerequisite node.

  4. Recurse: For each prerequisite node, repeat steps 2 and 3. If the prerequisite can be implemented without causing problems, mark it as done. If it introduces new issues, create new nodes for each new prerequisite and connect them to the current node with arrows.

  5. Undo changes: As you identify new prerequisites, undo any code changes made during the process to maintain a stable system. The Mikado Graph serves as a guide to implement the changes in the correct order later.

  6. Complete prerequisites: Once the graph is complete, start implementing the prerequisites from the bottom up. Each completed node will enable you to tackle its dependent nodes until you finally reach the main goal.

By following the Mikado Method and using Mikado Graphs, you can systematically refactor and reorganize your codebase while minimizing the risk of breaking the system.

Can it be used to update library used in a web application?

Yes, the Mikado Method can be used to update a library used in a web application. The method helps you identify and manage dependencies and required changes in a systematic way, which is particularly useful when updating libraries that might have a significant impact on your application.

Here’s a high-level overview of how to apply the Mikado Method for updating a library in a web application:

  1. Define the goal: The goal is to update the library to a specific version or to replace it with another library. Write this goal at the top of your Mikado Graph.

  2. Update the library: Attempt to update the library directly. If the update is successful and doesn’t cause any issues, you’re done. If it introduces breaking changes or issues, proceed to the next step.

  3. Identify prerequisites: Determine the issues that need to be resolved before the library update can be implemented. These issues could include changes in function signatures, updated configuration settings, or modifications in the library’s behavior. Add these prerequisites as nodes to your Mikado Graph and connect them to the goal node with arrows.

  4. Recurse through prerequisites: For each prerequisite node, try to implement the required changes. If the changes introduce new issues or dependencies, create new prerequisite nodes and connect them to the current node. Remember to undo any code changes made during this process to keep the system stable.

  5. Complete prerequisites: Once you’ve identified all dependencies and required changes in the Mikado Graph, start implementing the prerequisites from the bottom up. As you complete each node, you’ll be able to tackle its dependent nodes, eventually leading to the main goal of updating the library.

By following the Mikado Method, you can systematically update libraries in your web application while minimizing the risk of breaking the system or introducing new issues.

So it is not really restricted to just refactoring a code base?

That’s correct. The Mikado Method is not restricted to just refactoring a codebase. While it is primarily known for its effectiveness in handling large-scale refactoring, it can also be applied to other aspects of software development, such as updating libraries, implementing new features, or reorganizing code.

The strength of the Mikado Method lies in its systematic approach to identifying and managing dependencies and required changes. This makes it a versatile technique that can be adapted to various tasks within software development, ensuring that changes are implemented in a well-structured and organized manner, while minimizing the risk of breaking the system.

Breadth First vs Depth First

How to choose whether to pick breadth first or depth first when using the Mikado method?

When using the Mikado Method, choosing between breadth-first or depth-first traversal depends on the specific refactoring goal, the complexity of the codebase, and personal preferences. Both approaches have their advantages and can be effective in different situations.

Breadth-first traversal:

In breadth-first traversal, you address all immediate prerequisites of a node before moving on to their prerequisites. This approach allows you to identify and understand the full scope of required changes at each level before diving deeper into the dependencies.

Advantages:

  • Provides a clearer picture of the overall scope of changes at each level.
  • May help identify common dependencies or overlapping tasks early in the process, allowing for potential optimization.
  • Easier to parallelize work among team members, as multiple tasks can be tackled at the same level.

Depth-first traversal:

In depth-first traversal, you follow a single chain of prerequisites to its end before backtracking and exploring other chains. This approach allows you to focus on one dependency path at a time, which can be helpful when dealing with complex or deeply nested dependencies.

Advantages:

  • Helps maintain focus on a single chain of dependencies, which can be beneficial in complex codebases.
  • Potentially faster in identifying the full extent of a specific dependency chain.
  • Easier to understand the context and interconnectedness of tasks within a single chain.

To decide which approach to use for the Mikado Method, consider the following factors:

  1. Complexity: If your codebase has a high level of complexity and deeply nested dependencies, depth-first traversal might be more manageable and efficient. For less complex codebases or when the scope of changes is relatively small, breadth-first traversal could provide a better overview.

  2. Familiarity: If you are already familiar with the codebase, you might have a better idea of which traversal method would be more suitable. If you’re new to the codebase, experimenting with both approaches might help you determine the most effective method for your specific situation.

  3. Personal preference: Some developers may prefer the focused approach of depth-first traversal, while others may find the broader perspective of breadth-first traversal more intuitive. Choose the approach that you’re most comfortable with and that aligns with your problem-solving style.

Ultimately, the choice between breadth-first and depth-first traversal in the Mikado Method depends on your specific refactoring goal, the complexity of your codebase, and your personal preferences. You can even switch between the two approaches during the process if it makes sense for your particular situation.