軟體開發是"抽象化"原則（Abstraction）的一種體現。
所謂"抽象化"，就是指從具體問題中，提取出具有共性的模式，再使用通用的解決方法加以處理。
開發軟體的時候，一方面，我們總是希望使用別人已經寫好的程式碼，另一方面，又希望自己寫的程式碼儘可能重用，以求減少工作量。要做到這兩個目標，這需要"抽象化"。
最近，我讀到美國程式設計師Derick Bailey的一篇文章，談到"抽象化"應該遵循的三個原則，覺得很有啟發。
一、DRY原則
DRY是 Don't repeat yourself 的縮寫，意思是"不要重複自己"。
軟體工程名著《The Pragmatic Programmer》首先提出了這個原則。它的涵義是，系統的每一個功能都應該有唯一的實現。也就是說，如果多次遇到同樣的問題，就應該抽象出一個共同的解決方法，不要重複開發同樣的功能。
這個原則有時也稱為"一次且僅一次"原則（Once and Only Once）。
二、YAGNI原則
YAGNI是 You aren't gonna need it 的縮寫，意思是"你不會需要它"。
這是"極限程式設計"提倡的原則，指的是你自以為有用的功能，實際上都是用不到的。因此，除了最核心的功能，其他功能一概不要部署，這樣可以大大加快開發。
它背後的指導思想，就是儘可能快、儘可能簡單地讓軟體執行起來（do the simplest thing that could possibly work）。
但是，這裡出現了一個問題。仔細推敲的話，你會發現DRY原則和YAGNI原則並非完全相容。前者追求"抽象化"，要求找到通用的解決方法；後者追求"快和省"，意味著不要把精力放在抽象化上面，因為很可能"你不會需要它"。所以，就有了第三個原則。
三、Rule Of Three原則
Rule of three 稱為"三次原則"，指的是當某個功能第三次出現時，才進行"抽象化"。
這是軟體開發大家Martin Fowler在《Refactoring》一書中提出的。
它的涵義是，第一次用到某個功能時，你寫一個特定的解決方法；第二次又用到的時候，你複製上一次的程式碼；第三次出現的時候，你才著手"抽象化"，寫出通用的解決方法。
這樣做有幾個理由：
（1）省事。如果一種功能只有一到兩個地方會用到，就不需要在"抽象化"上面耗費時間了。
（2）容易發現模式。"抽象化"需要找到問題的模式，問題出現的場合越多，就越容易看出模式，從而可以更準確地"抽象化"。
比如，對於一個數列來說，兩個元素不足以判斷出規律：
1, 2, _, _, _, _,
第三個元素出現後，規律就變得較清晰了：
1, 2, 4, _, _, _,
（3）防止過度冗餘。如果一種功能同時有多個實現，管理起來非常麻煩，修改的時候需要修改多處。在實際工作中，重複實現最多可以容忍出現一次，再多就無法接受了。
綜上所述，"三次原則"是DRY原則和YAGNI原則的折衷，是程式碼冗餘和開發成本的平衡點，值得我們在"抽象化"時遵循。
==========================================================
附：
[廣告]
圖靈公司打算重新出版《Joel on Software》的中文版，正在尋找譯者。如果你對此有興趣，請與朱巍編輯聯絡（Email：zhuw(at)turingbook.com）試譯。關於此書的更多情況，可參考我翻譯的續集《More Joel on Software》。特別提醒：翻譯是非常辛苦、但是報酬很低的工作，寫信前請想清楚，你是真的想翻譯這本書。
（完）