中文試譯：FrequencyReducesDifficulty

原文日期：2011/07/11
原文作者：Martin Fowler
原文連結：http://martinfowler.com/bliki/FrequencyReducesDifficulty.html

我最喜愛的一段話是：如果它會造成傷害，那就多作幾次。這句話有奇妙的美感，表面上看起來沒道理，不過當我們深入探索後，會發現一些深具價值的意義。

整合是一個很好的例子。多數程式設計師在很早就了解到，與他人整合這件工作是相當令人沮喪與痛苦的經驗。人們的反應自然是盡可能地避免它。

嘲諷的是，如果我們能夠將痛苦與整合的時間畫出關係圖的話，我們應可發現該圖會像這樣：

如果你有這樣的指數關係，然後用更高的頻率經常地去作事情，你就能夠戲劇性地減輕痛苦。(譯註：當然，每作一次事情是有代價的，需要時間、精力，所以降低每次作事情的代價，也可以讓我們更有勇氣多作幾次。)這也就是持續整合所關注的 - 透過每日整合，整合時的痛苦幾乎消失了。整合的確有代價，所以我們經常地執行它，於是它變得不再痛苦了。

讓痛苦的事情執行地更頻繁在敏捷開發的思想中開花結果。測試、重構、資料庫遷移、與客戶對話、規劃、發佈 - 所有這些活動都以更高的頻率在進行。

是什麼造成這樣的效應？我認為有3個明顯的理由。首先，大多數的工作會在總量變得更多時，有更高的困難度，但是當被分解成較小的工作時就會容易得多。資料庫遷移就是一個很好的例子。明確指出一個大型資料庫的相關表格是非常容易出錯的。不過如果你能夠每次改變一點點，就會更容易讓每一次更改都是正確的。另外，你也可以輕易將這些小遷移串在一起形成一個連續的過程。因此，當你將一個大型的遷移分成多次小型的動作，整件事就會變得容易許多。這也是重構資料庫的基本要素。

回饋是第二個理由。大部份的敏捷想法就是如何去建立回饋迴路以讓我們可以更快地學習。在極限編程中，回饋是一個明確的價值觀。在Ken Schwaber的討論中，這是明確的開發流程與經驗式的開發流程的最大差異之處。在一個像軟體開發這樣複雜的過程裡，你必須非常頻繁地檢視你目前位於何處並作出一連串的修正。要作到這點，你必須找尋任何可以增加回饋迴路的機會並提升頻率，這樣就能夠更快地獲取更多進行修正的回饋。

第3個理由是為了練習。對於任何活動，當我們作的更多，我們就會更進步。大家都知道，要有好的外科手術，就要找一個常常進行手術的外科醫生。練習可以幫助你去除流程中的繡鐵，並讓你對事情不對勁時的徵兆更敏感。如果你對你正在作的事情進行反省，你也就能夠找出如何改善練習的方式。對軟體來說，就是自動化的可能性。當你已經做同樣的事情兩三次後，對於明白如何自動化以及增進自動化的動機都會比較容易。自動化特別的有用，因為能夠加速並減少錯誤的機會。

無論何時，當你面對一個痛苦的活動時，問問自己是否這些誘因足夠。如果可以，增加頻率就能夠令你更有效率並移除壓力來源。