關於DRY的理解

個人的理解：

如果我們對於乙個功能，或者乙個需求來說，重複次數達到3次以上，那麼可以對其封裝成乙個元件。

但這裡的封裝，並不是把它進行抽象化，模版化，而是應該在滿足當前專案需求的情況下來封裝，也就是需求決定封裝。

舉個例子：

比如說，你每天都需要啟動電腦的所有服務，在專案中鏈結你的資料庫，以及資料庫備份等等等，這些東西，看起來好像是使得你忙忙碌碌，但是，對於乙個優秀的程式設計師來說，他可能化幾天時間寫個指令碼，每天定時執行便代替了忙忙碌碌的你。

再比如說，你是一名不錯的移動端開發工程師，在這次版本迭代中，你需要改某個檢視的ui，你可能真的就只是重新寫這個檢視的ui，然後再重新寫這個檢視的邏輯。但是，對於細心的人，你可能就會發現，這裡的邏輯業務層其實並沒有改動，只是表現層需要變動而已，如果還有下一次，那就盡可能的將兩者分離。

所以我的看法還是一樣，需求決定封裝。