Explain Mikodo method and creating Mikodo graphs
It seems like you might be referring to "Mikado Method" and "Mikado Graphs." If that's the case, here's an explanation of the 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:
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.
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.
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.
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.
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.
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.
Are there any resources to learn how to apply it for Rails code base?
While there aren't many resources specifically dedicated to applying the Mikado Method to a Ruby on Rails codebase, you can still learn the method and apply it to any codebase, including Rails projects. The concepts and practices of the Mikado Method are universal and can be adapted to various programming languages and frameworks.
Here are some resources to help you learn the Mikado Method:
The Mikado Method book: The primary resource for learning the Mikado Method is the book "The Mikado Method" by Ola Ellnestam and Daniel Brolund. This book provides a detailed explanation of the method along with examples and case studies. Although not focused on Rails, the book's principles can be applied to Rails projects.
Book link: https://www.manning.com/books/the-mikado-method
Blog posts and articles: There are several blog posts and articles available online that explain the Mikado Method and its application. Here are a few examples:
https://medium.com/@_nikkormat/mikado-method-a-structured-way-to-make-big-changes-3db35e3aa3c
https://www.methodsandtools.com/archive/mikado.php
Videos and presentations: Various recorded talks and presentations can help you learn the Mikado Method through visual explanations. Here are a couple of examples:
https://www.youtube.com/watch?v=bGk_VM9Xgxo
https://vimeo.com/123635803
To apply the Mikado Method to a Rails codebase, you can follow the general principles and adapt them to Rails-specific concepts and components. As you gain a deeper understanding of the method, you'll be able to apply it effectively to refactor and reorganize Rails projects or any other codebase.
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:
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.
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.
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.
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.
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.
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:
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.
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.
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.
