Rule Of Three 原則
如果說 DRY 原則是將抽象發揮到極致，而 KISS 原則是保留抽象盡可能的使其單純化，那麼接下來三次原則（Rule Of Three principle）可以說是這兩個原則之間的中庸之道了。
而三次原則顧名思義其實就是重複到第三次才去抽象它！
還記得之前所提過的 YAGNI 原則（You aren’t gonna need it 原則）嗎？
三次原則可以說是提供了 YAGNI 原則一個準則，使得在重構上（refacting）的時機更有規則，但是為什麼會需要等待第三次才要抽象呢？接著就來思考這個問題。
為什麼要第三次才抽象
如果依據開發迭代的次數來討論這個問題的話，在第一次新專案開發時，對於預設立場上，YAGNI 原則已經解釋了預設立場這件事情並實際去開發未使用到的功能這件事情並不是件好事，原因是因為可能會限制將來開發人員對於該功能會綁手綁腳，甚至出現與實際規格文件不符合的預設立場。而 KISS （Keep it simple and stupid.）原則也指出應該要使開發程式碼盡可能乾淨，以利於往後實際遇到問題時的開發人員可以有足夠的彈性去維護、修改甚至重構原有的程式碼。
除此之外，對於 DRY （Don’t repeat youself.）原則來說，第一次新專案開發中的重複規模可能都偏小，由於第一手開發面向的會是開發文件中的功能。所以比較多是在於想怎麼符合現有的功能，因此需要做樣板（template)的可能已經有個雛形，並非做到才想到這件事。
而迭代到第二次，也就是接著開發、接手維護專案的時候。這時專案中可能充斥著已經上線的程式碼，那些存在伺服器倉庫中的程式碼是已經備受專案經理、測試人員、老闆甚至是使用者的反覆使用所驗證過的程式碼，若沒有特殊情況理論上來說要比新的程式碼還來的可靠。就連上檔也會多少避開假日前的這種敏感時刻。
因此，這時的維護開發多半可能多半會檢查既有程式中有沒有壞味道（Code smell），沒有的話就迎合既有的程式碼的味道，去持續端出穩定的料理，以便於下一個開發人員來維護。而即便從原有規格中發現了不符合新需求的程式碼，重構範圍應該不至於太大才是。
直至第三次再度踏入同專案中，需求功能開發與之前又再度類似，便能擁有更多的信心來確認需求面並依據前面的例子去做抽象。
如果依據代碼重複的次數來討論這個問題的話，則同上方例子，代碼重複第三次時，這時應該會有更多例子來思考要怎麼抽象來符合這些狀況。
總結而論
我們已經從情境模擬而出，第三次才抽象是基於第一次開發應保有它的乾淨；第二次重複的內容則是為了避免限制到將來的功能彈性，重複的實作在這時可以替程式碼增加可讀性；第三次才抽象是因為已有先前兩例可以有足夠的例子來思考抽象後的結構，並且是屬於真正有需求的時機。而至於在迭代下去的開發，如果更改的東西越簡單但開發時程越長時，該考慮的面相可以會變成是要抉擇重構或重寫升級了。