“不要重復(fù)發(fā)明輪子”，很多開發(fā)者在新入行不久，就經(jīng)常會被這樣叮囑：這個世界上程序員已經(jīng)太多，遇到的問題已經(jīng)夠多，而解決方案層出不窮。你走過的路，跳下的坑，已經(jīng)有無數(shù)的先驅(qū)在你之前路過，跳過。
所以在做技術(shù)選擇的很多時候，你不需要自己從頭去實現(xiàn)一個東西，就可以在現(xiàn)實世界中找到現(xiàn)成的趁手的利器，小到一個類庫，工具，大到一個框架，平臺，來滿足自己的“需求”。你以為你看到了絕美的風(fēng)景，后面是一馬平川。
而這，只是不愿意拒絕懶惰和誘惑的借口，背后很可能面臨更多的困難，陷入其中不得自拔。
開發(fā)者在技術(shù)選型的過程中，很容易對已有的神往已久的某個技術(shù)或者工具情有獨鐘。
“什么都是現(xiàn)成的，直接拿來用（一套）就好了！”
而往往忽略了它們在后期定制化需求，或者彈性及擴展方面對自己可能存在的限制。下面看兩個例子。
關(guān)于構(gòu)建工具的例子
比如Maven在Java的世界里很長時間都是主要的自動化構(gòu)建工具，它的插件化結(jié)構(gòu)，提供的很多現(xiàn)成的archetype和插件，以及命令行和插件化擴展的可能讓很多程序員眼前一亮。
而隨著手頭的項目變得愈加復(fù)雜的時候，你會發(fā)現(xiàn)Maven的XML聲明式結(jié)構(gòu)和插件化，恰恰是阻礙自身伴隨項目復(fù)雜度進化的絆腳石，因為它缺乏靈活性，以及對于自動化測試實踐的支持，尤其在持續(xù)交付方面。
而Ant有同樣的問題，我們不斷發(fā)現(xiàn)團隊在不可維護的Ant和Nant構(gòu)建腳本上耗費了巨大的精力。由于工具自身與生俱來缺少的表現(xiàn)力以及清晰的模塊性，這些腳本難以理解和擴展。
XML配置文件中太多讓人覺得多余的尖括號，以及粗糙的插件架構(gòu)。雖然語法問題可以通過升級換代來解決，但插件化架構(gòu)嚴重限制了構(gòu)建工具隨著項目變得愈加復(fù)雜自我優(yōu)雅進化的能力。我們發(fā)覺插件的抽象層次是錯誤的，相反我們更青睞基于語言的工具，比如Gradle和Rake，因為提供了細粒度的抽象，以及更多的靈活性。
Gradle是一個把理智帶入企業(yè)級構(gòu)建世界的嘗試，它把劃時代的技術(shù)和最佳工具組合相結(jié)合。Gradle可以讓你訪問你已有的Maven倉庫，但通過清晰的領(lǐng)域特定語言為你的構(gòu)建添加腳本功能。
相對于像Ant和Maven這樣基于XML和插件的構(gòu)建工具，像Gradle和Rake這種基于語言的構(gòu)建工具，在持續(xù)提供細粒度的抽象和更多的靈活性。這樣它們就能伴隨項目變得越來越復(fù)雜而隨機優(yōu)雅地應(yīng)對。
關(guān)于前端可視化框架的例子
另外一個例子是關(guān)于前端（可視化）框架的選擇上，一些提供了豐富UI渲染樣式的框架庫很是奪人眼球，漂亮的表格和圖表樣式，簡單的Demo示例代碼，讓開發(fā)人員都以為這是實現(xiàn)當(dāng)下棘手UI需求的不二法寶，可以極大地提高開發(fā)的效率。
比如ExtJS，開發(fā)人員在經(jīng)歷了初期的甜蜜之后，會發(fā)現(xiàn)他們很難控制Ext渲染出的HTML和DOM，而編寫功能測試代碼看起來也不太可能，尤其是當(dāng)對UI的外觀和樣式有個性化的定制變化需求時，會顯得一籌莫展。
Ext會把你限制在它的UI實現(xiàn)思想框框里面，這樣也許可以在那些不需要投資UX的團隊里面工作得很好。
Highcharts是個另外一個例子，豐富的圖表類型，以及基于提供的圖表類型的定制化功能，優(yōu)異的JavaScript引擎，對HTML內(nèi)嵌SVG文檔的支持，一度是我們在項目中選擇前端圖表展現(xiàn)庫的不二選擇：
但隨著對圖表渲染的個性化UX定制需求的加入，我們會發(fā)現(xiàn)Highcharts通過公開API提供的很多靈活性，比如對于X軸、Y軸和渲染細節(jié)的定制，已經(jīng)很難滿足我們對更多圖表本身的修改，和添加新的樣式。
而這時候，如果不是讓UX設(shè)計遷就Hightcharts既有的實現(xiàn)，也許更好的選擇是D3，雖然它會在開始顯得底層，需要團隊更多的精力來創(chuàng)建通用的不那么復(fù)雜的可視化元素，但這也意味著更多的靈活性，加上它的插件模型，以及像Rickshaw和Crossfilter這樣的庫支持，會讓D3比以前更具親和性。
最后
所以對于技術(shù)的官方網(wǎng)站提供的所見即所得的特性展示，簡單的示例代碼，和想當(dāng)然的心滿意足，開發(fā)者需要在接受誘惑的同時，多考慮一些在技術(shù)投資后可能存在的風(fēng)險，以及是否有足夠的支持。
需要考量的因素和角度可能但不限于：
- 文檔和社區(qū)支持的成熟度
- 復(fù)雜的代碼示例
- 可能的功能性需求變化
- UI呈現(xiàn)上可能的需求變化
- 性能，安全等非功能性需求
- 團隊知識和學(xué)習(xí)能力
- 后期的維護成本
需要針對這些因素，做一一的評估和偵測，才能最大限度地保護成本的投入。
有的時候，你真的需要重復(fù)發(fā)明輪子。
