在敏捷印度2012的一次研討會上，daniel brolund介紹了mikado方法。此方法主張敏捷團隊在面臨低質的遺留**時，採用簡單的方法，分成小部分逐步完成重構。
\u0026#xd;\n
通常，當你想在遺留應用程式中做個簡單的改動時，經常會有某些事情出錯而使這個改動無法執行——如編譯出錯、驗收測試失敗（如果有驗收測試！）等。當你修復這些問題後，更多的問題又出現了——直到看上去事情全都失控，你都恨不得來重寫這個系統了。
\u0026#xd;\n
mikado方法提出了簡單的解決方案。當你進行重構時，一旦發現某些依賴的部分出錯了，則畫一張圖表來表示這些錯誤，並標明真正去修復錯誤之前，需要先做什麼事情。然後還原你的改動，開始觀察那張依賴圖中的某個葉子結點。修復那個錯誤，看它是否會引起更多的問題——如果不會，重複這個過程——繼續對剩餘部分進行重構並在圖中畫出更多的葉子、還原你的改動，並再從某個葉子結點開始修復工作。
\u0026#xd;\n
每當還原**時，你可能覺得自己又回到了原點，而實際上並沒有——比起剛開始，你已經掌握了更多的資訊。而且，你也主要是在編譯能通過（並且測試通過！）的**上做修改，而不是大量無法編譯的**， 所以也有可能可以使用ide重構工具。每當乙個葉子結點上的問題都修復完了、且不再引起更多錯誤時，就可以簽入**，在依賴圖上把這個葉子結點標記為綠色；當某個結點上的所有葉子結點都是綠色了，你就可以以那個結點為基準開始工作，重複上述的過程，直到完成所有原定的重構工作。這意味著**是以很小的增量逐漸簽入的，且可以直接在主幹**上工作（而不用為此再打分支）。
\u0026#xd;\n
對於重構大型應用系統，似乎這個圖表會變得太龐大且難以控制，但是daniel說通常並不是這樣的——依賴圖的規模與**的規模通常並不直接成比例。依賴圖的主要目的是清楚地記錄每一步重構開始時的目標和範圍，以便讓自己只朝著這個目標工作，而不是試圖一次做太多改動。
\u0026#xd;\n檢視英文原文：mikado method for refactoring legacy software
用Mikado方法重構遺留軟體
在敏捷印度2012的一次研討會上，daniel brolund介紹了mikado方法。此方法主張敏捷團隊在面臨低質的遺留 時，採用簡單的方法，分成小部分逐步完成重構。通常，當你想在遺留應用程式中做個簡單的改動時，經常會有某些事情出錯而使這個改動無法執行 如編譯出錯 驗收測試失敗 如果有驗收測試！等。...
軟體測試 判定錶用例設計方法
判定表是分析和表達多種輸入條件下系統執行不同動作的工具，它可以把複雜的邏輯關係和多種條件組合的情況表達得既具體又明確。1 條件樁 列出系統所有的輸入和條件 2 條件項 所有輸入和條件的真假值 3 動作樁 列出系統可能採取的操作和輸出 4 動作項 列出在所處條件項下，系統出現的動作 確定輸入和輸出,列...
軟體開發中的理想與現實（三） 用重構來清掃戰場
2月17日的早晨非常寒冷，就算躲在被子裡也可以清楚地感覺到，不過到實驗室就不會覺得冷了 嗯，有空調就是好啊 所以，我很早就來了。重新檢查大家的 我有種想重寫的衝動 呵呵 不過這正合我意，因為今天的工作就是清掃戰場，做清掃的人當然是大家。首先我把需要修改的內容列一下 在算prime的時候沒有採用最優化...