接著上一篇的思路聊。既然我們可以把開發者社群看作一個整體，copy-paste別人的blog文章就是在違背DRY的精神，其實所謂"重造輪子"道理也是一樣，既然別人都已經做了相同的事情，并且把它開源了，并且你看了它的代碼以后，覺得做得不錯，為什么還要自己費心去實現同樣的功能呢？自己來實現能給你帶來什么好處呢？
我可以列舉一些我認為可能會讓我們選擇自己來做的理由:
- 我比其他人更了解我們自己的需求。
- 自己實現起來更容易，代碼量更小，也更好用。
- 我是做技術的，能夠DIY，就DIY，這樣更能體現我的價值。
這些理由有它的道理，但是我們有必要仔細掂量掂量:
- 我比其他人更了解我們自己的需求。這是軟件開發中很常見的一個誤區，客戶的需求難以把握，隨著時間的推移，我們自己的技術層面的需求實際上也在不斷變化，開源的框架往往經歷了更多的考慮和驗證，并且有一群熱心的維護者幫你做bug-fix和升級，甚至我們自己就可以成為這群熱心人中的一員。
- 自己實現起來更容易，代碼量更小，也更好用。一開始確實是這樣的，開源的框架為了滿足不同的需要，往往需要比我們自己寫代碼要更加復雜和冗余，但是自制框架意味著我們自己定義的接口規范，這個接口規范能不能夠在整個項目周期保持穩定暫且不談，就算接口實現的再簡單，項目中其他人也需要時間去理解和消化，然后記住一個定義好的調用方式，今后新加入的工程師也需要學習這個接口規范。開源框架則做得更好，一方面在這個項目中積累和學習到的知識，可以直接用在其他采用同一框架的項目中，另一方面新加入的人如果有過該開源框架的開發經驗，上手時間可以縮短。
- 我是做技術的，能夠DIY，就DIY，這樣更能體現我的價值。我必須承認，我本人就親身經歷過這樣的情況。在即將結束的這個項目中，我甚至自己DIY了一個簡易的.NET報表引擎，為的是甩開Crystal Reports。一開始能夠DIY報表引擎的想法讓我興奮得睡不著覺，最終前后花了3天很滿意的完成了設計和開發，并交付報表開發人員重畫報表。可是真正用了一段時間之后，基本的需求滿足了，基本的可擴展性也具備，但是缺少可視化設計器、更靈活的公式、更豐富的報表元素，基本上就定型了，沒有人有時間和精力再去維護它。
在很多開發團隊，大家經常碰在一起討論具體的技術和設計，這很有必要，有時也不可避免。但是也許Joel Spolsky說的對，軟件設計很難，但是比設計軟件更難的，是同整個team一起設計軟件。做技術的，對于自己了解、掌握、做過、嘗試過的東西，對于自己熟悉和信任的東西，多多少少有些偏袒，而對于新的、自己不了解、不熟悉的東西，則難免心存疑慮。這就難怪很多設計討論會最終很難達成一致。這個時候，要么由技術上的最高權威直接拍板，定下來是什么就是什么，要么就分歧雙方或多方各自陳述，然后由項目外部的實體進行獨立仲裁。
我看好開源框架，尤其是那些經過考驗廣泛被采用的框架，因為相比自制框架，它們有著更大的優勢。