Mikado

買了一本講 Mikado 方法的書。好像在台灣沒什麼人講過這個方法的樣子。

我試著就我的理解講一下我讀到的 Mikado 方法好了，請注意，這段描述大多數是我的語言，而不是書裡的內容。

這個方法要解決的問題是如何讓 Refactor 的過程變得可以管理。我們以前讀 refactoring 的時候，那些書主要在討論工程師應該察覺什麼時候應該 refactor，例如聞到像是「有重複的程式碼」這類的怪氣味，接下來就是對付這些怪氣味的各種招數，什麼把 method 抽到上層或是一到下層，把一些 method 拆出去變成另外一個 class 諸如此類。

但是在工作上，當你打算做一輪 refactor 的時候，你的 PM 一定會問你一個問題：這次 refactor 要做多久？原本那些講 refactoring 的書，卻沒有提供你估算難度與時程，將 refactoring 的工程納入管理的方法。或是，當你開始做 refactoring 的時候，因為閱讀程式碼，又分心去修了一堆原本不在既定目標內的問題。

Mikado 算是與目前既有的 refactoring 知識互補的另外一塊。大概在講的是，做一次 refactoring 應該要按照一個流程

• 確定這次 refactoring 的目標，超過這個目標的事情不應該做
• 規劃到達終極 refactoring 目標的過程中，到底需要改動哪些子項目，然後用圖表列出這些項目的相依性，確認這一輪 refactoring 到底要做哪些事，並且把巨大的 refactoring 變成多個較小而較容易的修改
• 根據上一步建立的圖表，追蹤目前的 refactoring 進度，知道我們是否偏離目標
• 如果每一次的小修改失敗，應該要能夠 rollback 回之前的狀態

說起來，這些本來就是在做 refactoring 的時候要做的事，而 Mikado 將這樣的步驟系統化。一方面可以說是如何從 PM 的角度看 refactoring，而像是要你先把一次很大的 refactoring 分而化之各個擊破這個流程，應該也可以增加工程師願意開始 refactor 自己的程式、或 legacy code 的信心。

http://mikadomethod.org/