c语言中mikado_蜜蜂如何使用mikado方法

c语言中mikado

Performing a large code refactoring or implementing a new feature in a legacy codebase is a great undertaking for any team. Even in a well architected codebase, tasks will likely be complex and require careful thought. Such endeavours may span several weeks or even months, requiring a high level of communication, understanding, and agreement amongst the team.

对于任何团队来说，执行大型代码重构或在旧版代码库中实现新功能都是一项艰巨的任务。 即使在结构良好的代码库中，任务也可能很复杂，需要仔细考虑。 这样的努力可能需要数周甚至数月，需要团队之间的高度沟通，理解和同意。

Recently the Honeybees team decided to read The Mikado Method, and discuss our thoughts weekly as part of a book club. The aim was to learn new skills for large scale refactoring, as we are planning to refactor a sizable chunk of our codebase in the near future. To evaluate the technique, we decided to use it to change the logging library used in SQL Prompt.

最近，蜜蜂小组决定阅读“天皇方法” ，并作为一个读书俱乐部的一部分，每周讨论我们的想法。 目的是学习大规模重构的新技能，因为我们计划在不久的将来重构我们代码库的相当大一部分。 为了评估该技术，我们决定使用它来更改SQL Prompt中使用的日志记录库。

天皇方法 (The Mikado Method)

The Mikado method is a technique used to explore and understand how a task could be performed, identifying the key actions to complete it. The first step is to define a goal. This should be the abstract idea that is to be achieved, for example:

Mikado方法是一种用于探索和理解如何执行任务，确定完成任务的关键操作的技术。 第一步是定义一个目标。 这应该是要实现的抽象概念，例如：

“Replace the logger with an approved logging framework”

“用批准的日志记录框架替换记录器”

With the goal determined, the most abstract steps (prerequisites) to achieve the goal are added to the graph. Once the first level of prerequisites has been chosen, each leaf node is explored to discover its own prerequisites. This process repeats until all leaf nodes are relatively trivial tasks. As a node grows further away from the goal the task should become more concrete. The book tells us the nodes can be explored using either a depth-first or breadth-first approach. For us, the best solution was somewhere in the middle — explore each layer briefly and when there are no more obvious prerequisites, we drill down into one node depth-first.

确定目标之后，将达到目标的最抽象的步骤(前提条件)添加到图中。 一旦选择了第一级别的先决条件，便会探索每个叶子节点以发现自己的先决条件。 重复此过程，直到所有叶节点都是相对琐碎的任务。 随着节点远离目标的增长，任务应变得更加具体。 这本书告诉我们可以使用深度优先或宽度优先的方法来探索节点。 对于我们来说，最好的解决方案是在中间的某个地方—简要地探索每一层，并且当没有其他明显的先决条件时，我们将首先深入到一个节点。

The controversial magic of the Mikado method is that code changes are regularly discarded. During exploration, the goal or prerequisite is implemented naively and then a decision must be made to keep or discard the code immediately, based on whether the changes make sense and what errors have been introduced. This feels very unnatural at first as you may spend 15 minutes refactoring a class only to revert the changes. The key realisation here is the time has not been wasted! Instead the time has been used to learn about the code structure and expand the Mikado graph, hence creating a superior plan. Code changes can be stashed if they are valuable but currently produce non-trivial build errors. However, this increases the complexity of the process and the eventual merge may offset the time saved by stashing.

Mikado方法的有争议的魔术是规则更改经常被丢弃。 在探索过程中，目标或前提条件天真地实现，然后必须根据更改是否有意义以及引入了哪些错误来决定立即保留或丢弃代码。 刚开始这感觉很不自然，因为您可能需要花费15分钟的时间来重构课程，以恢复所做的更改。 这里的关键实现是时间没有浪费！ 取而代之的是花时间来学习代码结构并扩展Mikado图，从而创建了一个更好的计划。 如果代码更改很有价值，但当前会产生非常重要的构建错误，则可以将代码更改隐藏起来。 但是，这增加了过程的复杂性，最终合并可能会抵消存储所节省的时间。

“If you are hacking the next step, you’d be building on assumptions and guesswork. Avoid the temptation” — A quote from our book club.

“如果您要攻克下一步，那么您将以假设和猜测为基础。 避免诱惑”-我们读书俱乐部的名言。

The Mikado graph we created while replacing our logger.

我们在替换记录器时创建的Mikado图。

Once the graph has been explored to a reasonable extent and the resulting leaf nodes represent achievable chunks of work, we can begin making changes to the code. Decide on the most logical leaf node to start at and begin working towards the goal, completing each prerequisite one-by-one. By the time the graph is completed you will have a feel for where to start. Tick off each prerequisite when the code is committed.

一旦对图进行了合理程度的探索并且所得到的叶节点代表了可以完成的工作，我们就可以开始对代码进行更改。 确定最逻辑的叶节点开始并开始朝着目标努力，一步一步地完成每个先决条件。 到图形完成时，您将对从哪里开始有了一种感觉。 提交代码后，勾选每个先决条件。

The key thing to remember is that the graph should be treated as a living document, so making changes and exploring further during the work is acceptable and encouraged — we live in an agile development world after all!

要记住的关键是，应将图形视为活动文档，因此在工作中进行更改和进一步探索是可以接受和鼓励的-我们毕竟生活在敏捷的开发世界中！

我们的想法 (Our Thoughts)

The primary focus of the Mikado method is planning how a piece of work could be carried out. This is reasonable and it is an effective tool, however it’s far more valuable than that.

Mikado方法的主要重点是计划如何执行一项工作。 这是合理的，并且是有效的工具，但是它远不止于此。

FocusWhen working on a task that stretches over several weeks or months a developer may lose focus of the end goal or get lost in a task as more and more complexity is added. This can lead to scope creep and ultimately inefficient working. The Mikado graph allows work to be tracked and a clear working path to be visualised.

专注当执行一项持续数周或数月的任务时，开发人员可能会失去对最终目标的关注，或者随着越来越多的复杂性而迷失在一项任务中。 这会导致示波器蠕变并最终导致工作效率低下。 Mikado图形允许跟踪工作并显示清晰的工作路径。

TeamsA piece of work completed by a pair or team, either as a mob or splitting up the work and coding asynchronously, must be well understood by all members of the team so that the result is what everyone expects. Using a graph to illustrate this allows the team to agree on the abstract steps that need to be taken, an end goal, and the direction to get there. This is particularly important where a team may be working remotely and quick discussions about the approach may be more challenging to coordinate.

团队团队或团队完成的工作，无论是暴民还是拆分工作，并以异步方式进行编码，都必须为团队的所有成员所理解，以便结果是每个人的期望。 使用图表来说明这一点，团队可以就需要采取的抽象步骤，最终目标以及实现该目标的方向达成一致。 这在团队可能正在远程工作并且快速讨论该方法可能更具挑战性的情况下尤其重要。

Code ReviewUsing the Mikado method allows an individual or team’s thought processes to be written down in a clear way that can be understood by someone who is not well versed with the problem. This means that during a refactoring code review where a reviewer may be faced with a 150+ file change pull request, the thought process and reasoning behind why a piece of code has been changed can be understood much more easily. This means that code reviews can be more effective and faster.

使用Mikado方法进行代码审查可以使个人或团队的思维过程以清晰的方式写下来，那些不熟悉该问题的人可以理解。 这意味着在重构代码审阅过程中，审阅者可能面临150多个文件更改请求请求，可以很容易地理解为什么更改了一段代码的思考过程和推理。 这意味着代码审查可以更有效，更快。

“The Mikado method is what an experienced developer would normally do subconsciously, plus the discipline and courage to undo changes” — A quote from our book club.

“ Mikado方法是经验丰富的开发人员通常会在不知不觉中做的事情，再加上纪律和勇于撤消更改的勇气” –来自我们读书俱乐部的引述。

The Mikado method is a great refactoring tool for any developer. The method provides a great deal of support with longer running tasks, especially when working in teams. Making the steps to achieve success visible is particularly important in the remote working world. As such the Mikado method should be treated as both a refactoring and a communication tool.

Mikado方法对于任何开发人员都是一个很好的重构工具。 该方法为长时间运行的任务提供了大量支持，尤其是在团队合作中。 在远程工作环境中，使获得成功的步骤清晰可见尤其重要。 因此，Mikado方法应被视为重构和通信工具。

Give the Mikado method a try and share your graph in the comments! P.S. we recommend using an online whiteboard app such as Mural.

尝试使用Mikado方法，并在评论中分享您的图表！ 附言：我们建议使用在线白板应用程序，例如Mural 。

翻译自: https://medium.com/ingeniouslysimple/how-the-honeybees-use-the-mikado-method-d2b9fa34184f

c语言中mikado