增量式遷移

軟體開發就像任何專業領域一樣，有許多經常被遺忘的活動，這些活動通常會被忽略，但卻會在最不恰當的時機反撲。其中一項就是資料遷移。

大多數新的軟體專案都涉及資料，這些資料以前儲存在別的地方，現在需要在系統上線後移轉到新系統中。系統替換可能必須移轉所有舊資料，新的功能可能會導致資料從其他系統載入。

不重視這項任務是很常見的。畢竟，這只是讀取一些資料、稍微整理一下，然後載入新系統而已。此外，這段程式碼只會執行一次，因此沒有必要特別快或漂亮。一旦遷移完成，就可以安全地丟棄這段程式碼。

當然，無需擔心這件事，直到專案結束，因為你只希望在新系統上線前執行遷移。

我對我的讀者有很高的評價，只因為他們對軟體寫作的品味，所以我確信我能看到他們若有所思的微笑。資料遷移從白板抽象的安全性來看通常看起來很容易，但通常充滿了會讓你絆倒的討厭細節。

• 你可能會懷疑現有資料有點亂，但每個人通常都會對資料實際上有多髒感到驚訝。因此，整個練習通常比它應該的複雜得多。
• 因為這是單次使用的拋棄式程式碼，所以人們不會花太多設計精力在遷移程式碼上，因為他們假設它低於 DesignPayoffLine。這種假設通常是錯誤的，特別是針對前一個項目符號。
• 從事一項活動，最後變成比你想像中更困難的事情，這一點都不好玩，但是如果你把它留到接近出貨日期，你就是在給麻煩一個大大的簽約獎金。

在敏捷環境中，我喜歡使用一個簡短的說法：如果感到困難，就更常去做。表面上看來不合邏輯，但卻令人印象深刻，而且其中蘊含著真正的道理。許多困難的活動，只要更頻繁地執行，就能變得更簡單。XP 人員特別擅長將此原則應用於測試、整合、設計和規劃，因此將其應用於資料移轉，應該不會讓任何人感到意外。

我第一次看到此做法，是由我的同事 Josh Mackenzie 在一個中等規模的專案（十幾位開發人員，為期一年）中執行的，該專案在不久前曾失敗過兩次。他決定每兩週的迭代就移轉一次資料。在每次迭代中，團隊都會找出他們需要新增哪些資料，以支援正在建置的新功能，並更新資料移轉系統，以從實際系統移轉這些額外資料。

與這些事情常有的情況一樣，最後發現這項工作遠比人們擔心的容易，而且降低了風險和壓力，因此成為一個值得的選擇。他們欣賞明顯的好處，這些好處歸結為在接近上線時，明顯地沒有倉促的恐慌。

然而，最有趣的好處是他們始料未及的。增量移轉大幅改善了與領域專家的溝通。通常，當您想與領域專家討論使用案例時，您會編造一些假設的情境。透過使用增量資料移轉，團隊養成了使用實際範例的習慣，而領域專家更容易理解這些範例。此外，當開發人員提供可供領域專家檢視的建置時，其中包含實際資料的副本。因此，領域專家可以調查新系統如何處理他們最近遇到的棘手案例。特別棘手的困境可以輕鬆地複製到測試環境中。

即使沒有改善溝通，執行增量移轉也是值得的。如果您執行，請做好準備，利用機會使用實際資料與領域專家交談。