通俗的講就是儘量少貼上複製。

DRY簡而言之，就是不要寫重複的程式碼。原則本身很簡單，但是，對於OOAD來說，有著非常重大的意義。

1合理的抽象，程式碼提取
DRY利用的方法就是抽象：把共同的事物抽象出來，把程式碼抽取到一個地方去。這樣就可以避免寫重複的程式碼。

舉一個DRY的典型例子，如果在一個類構造的時候，需要進行成員的初始化，在進行了某些操作以後，同樣要進行初始化，那麼就可以把“初始化”抽象出來，做成一個方法Initial()，在構造和需要用到的地方呼叫它。

雖然，抽取重複程式碼是利用DRY的一個好的開端，但DRY的實質是，一個需求，用一個部分來完成。當你試圖避免重複程式碼的時候，實際上，你做的應該是用一段程式碼來完成一個需求。

為什麼要用DRY原則?DRY會給程式碼維護帶來很大的好處。以類的初始化為例，假設類修改了，增加、減少或是修改了成員，如果不寫 Initial()，那麼你可能至少要修改兩處，而且，修改之處也可能出現不一致，維護成本大大增加。而寫了Initial()方法，那麼只要集中修改 Initial()就行了。

2正確的姿勢使用開源庫
開源絕對是個好東西。
凡是，我們不能從頭開始吧。
選擇一個知名度高，文件齊全，比較成熟的開源庫。

3 How to select open source libraries
1. 首先根據自己的專案性質選擇合適的開源許可證。

 對你所開發軟體的顧客和應用物件來說，許可證是否適用非常重要。例如，在受監管的環境下，通常只有Apache2可用。
 

1. 確定你要解決的問題型別。

   例如需要解決的是軟體的分發、快取、永續性還是鬆散耦合？

2. 提煉出問題的元標籤和描述性短語。

   例如，如果你需要解決的問題是關於在多個機器中的最佳路徑，你的標籤或短語可能會是遺傳演算法、job-Shop Scheduling、規劃圖、優化排程演算法、最短路徑等。

3. 瀏覽codeplex, google code or sourceforge (github.com 也是個很有價值的網站) ，並列出初步篩選到的開源庫。

   例如：在IoC/DI列表裡，可以找到ninject, structuremap, autofac, windsor等開源專案。

4. 找到這些專案的主頁，分別檢視專案的最新進展，標出那些很久沒有更新或者已經停止開發的專案。

   注意主頁上的新聞、釋出通告、提交記錄、網站更新等。我一般會從列表中刪除掉那些超過6個月沒有做更新的專案。

5. 到程式碼庫頁找到相關測試元件。

   建議你將沒有單元測試元件的專案從列表中刪去，也許你覺得這個要求過於苛刻了，但如果沒有單元測試，如何能保證這個專案的質量呢？

6. 在專案主頁中確認有相關文件。

   從選好的專案列表中刪去那些沒有文件、程式碼示例或適用指南的專案。畢竟學習一個全新的工具或框架我們需要付出一定的精力，一個全面細緻的文件是非常必要的。

7. 從版本控制系統中取出專案原始碼，檢視是否有擴充套件點（extension points)。

   理想的開源庫或框架並不限制你使用特定的日誌框架或依賴注入容器（DI container）。而多種擴充套件點可以為你提供定製化日誌系統、容器等的可能性。

還有其他一些篩選原則，你可以根據所作專案的需求進行考查：

是否附有構建指令碼（build script）？

該開源專案小組是否持續使用同一整合開發環境?

該開源專案是否有清晰的road map?

該專案是否設有問題跟蹤器（issue tracker）？

是否很快就有社群補丁推出？

在社群中，關於該專案的問題反饋是否迅速？

其他的開發者是否樂於使用該開源庫，在社群中關於該專案的知識技巧是否很快傳播?

有多少活躍的專案貢獻者？

版本號管理是否清晰？