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