作者：丁儀
來源：https://chengxuzhixin.com/blog/post/wei_shi_me_yao_gu_li_zhong_fu_zao_lun_zi.html
“不要重複造輪子”恐怕是僅次於“php是最好的語言”之後最流行的話了。各種論壇，各種文章，都在說不要重複造輪子，那我們到底造不造呢？回想這幾年的工作經歷，個人或團隊重複造的輪子也有幾個，整體上還是比較認可這種工作方式的。在適當的時機造輪子有時候也是最佳選擇。
不重複造輪子的理由，主要就是通過複用減少工作量，而且開源社群的很多專案質量也比較可靠。比如 Spring 框架，在很多大公司的重要專案中都有使用，事實也證明了可靠性，恐怕沒有幾個團隊會自己實現一套 IOC 框架並用於生產環境。開源專案集聚了很多優秀程式設計師的心血和付出，經過大規模的使用和小心謹慎的問題修復，無論是架構設計還是專案質量，大部分還是有保證的。自己造輪子所面對的工作量、缺陷數、安全性是比較大的阻礙，投入產出比不高。
但是，我們也發現，有很多人長期處在僅僅使用開源框架的層面，沒有進一步深入。雖然工作了挺長時間，但是技術深度還浮於表面。其實道理很簡單，只有真正理解框架的原理，才能更好地使用框架。對於能夠複用的東西，優先考慮複用，少造輪子。但是造輪子也不一定是壞事，站在前人的肩膀上，也可以有更多突破。
造輪子，能夠極大提升技術水平。比如曾經做爬蟲模擬使用者登入的時候，最初僅是依靠 httpclient 訪問 URL，然後寫了很多業務程式碼做資料分析。但是過了 3 個月，發現有大量重複的程式碼，而且整個系統有一種確定的模式，於是造了一個爬蟲模擬使用者登入的框架，極大提升了開發效率，技術水平有了一次飛躍。
造輪子，能提升個人影響力。比如曾經火了一把的 flv.js，作為 B 站在用的網頁播放器讓作者謙謙火了一把，讓大家開始關注這個年輕的 95 後，並開始為其抱不平。謙謙是高中學歷，在程式設計師群體中屬於不太突出的，工資也只有 5000 左右。如果沒有 flv.js 開源專案，可能一輩子也得不到大家的關注。現在工作能力得到了認可，想必會有不錯的發展吧。
造輪子，解決不能滿足的需求。Spring 框架解決了 IOC 和 MVC 問題，Mybatis 解決了資料儲存問題，dubbo 解決了分散式呼叫問題，然而業務實現還需要具體問題具體分析，case by case 進行設計。一個表單的資料採集，就有數不清的業務場景，針對性地設計了幾個產品來滿足不同的業務訴求。開源輪子也無法完全滿足所有場景，所以有 RocketMQ、Tair、diamond 等內部實現。
造輪子，能推動公司技術進步和沉澱。這可能是所有網際網路公司的“通病”，對技術創新比較看重，晉升、加薪都有傾斜，同時對一般的日常維護比較淡漠。所以同一家公司往往有多個框架或產品，在解決同一類問題，同時在各自重點突破的領域內也建立了一定的技術壁壘。不過最終往往會走向統一，由其中較為突出的一個逐漸取代其他框架或產品，從而完成了公司的技術突破。
要不要造輪子呢？可能還得具體問題具體分析，綜合考量。無論是個人還是組織，最好是鼓勵高水平創新，防止低水平重複。重複造輪子不可怕，沒有思考和創新，僅僅是 copy 了一份，一定是沒有價值的重複工作。在充分調研和思考後，出於謹慎的權衡考量，造出一個有特點、有突破的新輪子也是大功一件。
微.信.搜.一.搜.程式之心，每週一三五原創更新。
推薦閱讀：