打造輪子的樂趣

程式設計發展至今，軟體的規模與架構日益龐大，想要開發一個應用程式，並全部從無到有自行打造，就現今的程式開發者來說，多半認為費時、費力，是件幾近不可能的任務。

在開放原始碼當道的現今世界來說，選擇如此之多，「不要重新打造輪子」似乎成了一句神聖的口號，甚至成了實現想法與尋找樂趣的阻力了！

打造輪子不好嗎？

你上一次想要打造輪子的想法，是什麼時候出現的？採取了具體行動嗎？或者因為種種的理由而打退堂鼓了呢？像是網路上早有現成的方案，或者是旁人的勸阻：「你想做的這個東西，已經有人做了」，也許「Reinventing the wheel」這句話在你心中已是個邪惡象徵，想到就覺得有罪惡感，而作罷了？

從輪子發明以來，據學者研究已有近6000年的歷史了，也因此，有人還在努力發明輪子，就常會被賦予徒勞無功的形象，在網路上搜尋「發明輪子」、「打造輪子」，多半會看到一堆文章，告知重造輪子的種種問題，像是費時、費力、浪費了過去歷經重重考驗而留下來的基礎等。

就軟體而言，重造輪子往往也代表了可能產生新的臭蟲或瑕疵等，歷史上有幾個重新打造軟體而失敗的例子，常被拿來作為有力的佐證，像是《約耳趣談軟體》中〈你絕對不應該做的事之一〉就提到了Netscape等重寫的幾個例子，並說那是「最糟的策略錯誤」。

當然，對於程式開發者普遍存在的「非我發明症（Not-Invented-Here）」疾病而言，這是一則良方，可以阻卻有些開發者什麼事都想自己來的誘惑，而在開放原始碼興盛的今日，幾乎你想打造的輪子，往往早就有人發明了，還有什麼東西是需要自行打造的？最多就是將其中不合用的稍做修改，這總比重新打造來得快速嘛！Startup的興盛更助長了這個想法，想要個什麼應用程式，東拉一堆、西扯一些，全部撮在一起，就有了……

漸漸地，許多人就都成了「Google工程師」，用Google搜尋來寫程式的工程師。雖然重新打造輪子，可以省去開發相關組件的時間與人力，然而，花費在學習既有輪子如何使用、修正既有臭蟲，以及各種輪子之間如何彼此協調合作的成本越來越高，各式輪子有著各自成堆的文件、頻繁的更新、升級（以及功能廢棄）等，這些著實都造成了現今開發者的諸多負擔，面對著滿坑滿谷的輪子，不禁開始會想問「打造輪子不好嗎？」

從造輪中學習與釐清需求

就現今而言，選擇一個合用的輪子是個大問題！加入一個「非我發明」的輪子，意謂新增了一個相依性，因而現在不斷地有一些文件出現，告訴大家如何挑選程式庫與框架，像是查看它們的更新時間與頻率，修改記錄（changelog）、作者（或團隊）修正問題的速率，版本語義與相容性，作者（或團隊）的信譽，以及是否有良好的文件與使用者社群等，有時甚至得察看一下原始碼，瞭解程式庫或框架的品質。

最重要的是得確定，選擇的輪子是否真正符合需求。使用既有的程式庫或框架固然可以避免自行開發、測試與維護的成本，然而它們也有著一定的約束性。

正如我在〈找出框架的「框」〉中提過的，好的框架雖然不一定能帶你上天堂，但不好的框架絕對能讓你住套房。此時，先自行打造輪子就可以是一種選項，這可從中學習複雜的概念，瞭解到想要使用的輪子之要素與技術，打造出來的原型框架或許可以繼續使用，或者也能作為評估既有方案的一個依據。

這也牽連到一個事實，現在許多程式庫或框架，為了滿足各式需求而越來越龐大，有時可能採用了一個框架，然而只用到其中一小部份，日後卻可能得在該框架的版本更迭過程中，不斷付出更新框架的成本，或者選擇待在舊版本中自行修正相關臭蟲，這時還不如根據真正的需求，自行打造適當尺寸、合用的輪子。

雖然〈你絕對不應該做的事之一〉中談到，重寫是最糟的策略錯誤，然而，約耳也在〈為非我發明症辯護〉中談到了打造輪子的重要性，他以「主廚若真的需要新鮮薰衣草會自己種」作為例子，也以「關鍵的業務拿去外包，就會瞭解外包其實是個地獄」來說明「如果是核心的事業功能，不管是什麼都要自己來做。」

有時，不找出輪子，也許更好

在今日，幾乎你想要打造的輪子，往往早就有人發明了，真是令人洩氣不是嗎？然而，仔細想想，重新發明這件事本身為什麼會被普遍地認定為不好？理由往往是為了「產能」，如果打造輪子帶來的價值，無法高過使用既有輪子的產能增益，那麼，造輪的提案就會被否決，久而久之，重新發明的熱血與憧憬，就逐漸消失得無影無蹤了。

然而，重新發明本身的價值，就只能從產能方面來衡量嗎？想想看你的過去，曾經想要重新發明輪子時，是基於什麼樣的情境與原因，那其中一定有著產能之外的價值考量，也許是想實現某個想法，也許是想挑戰，或許只是單純覺得好玩，發明本身是件好事，就算想做的這個東西，已經有人做了，在重新發明的過程中，也不會做出完全一模一樣的東西，而價值往往存在於這樣的差異之中。

就我個人而言，從程式設計跨入Maker圈的這一年多來，偶而看到「你想做的這個東西，已經有人做了」這類話時，越來越覺得那是個負面的話語了，當事人的熱情與可能性往往就這麼被澆熄，就創造的角度來看，有時不找出或不告知當事人已經有輪子了，也許更好。實際上，Maker圈中往往有許多新的創意，都是在打造輪子的過程中被發掘出來的。

最近我在玩OpenSCAD，就特意採用不找出輪子的方式，就算只是個簡單的字串剖析函式，也試著自行打造。當然，真的要找出OpenSCAD既有的程式庫，也是有不少可以直接使用的，不過，親手打造顯然帶來了更多的樂趣，除了對使用程式建模有更深入的認識之外，也漸漸地累積出一些可重用的元件模組。

從造輪中激發想法與樂趣

有機會可以看看Thingiverse這個網站，會發現上頭有許多概念類似或重複的模型被創造出來，然而，未曾看過有留言寫到，這個模型已經有誰實現了，也許正因為如此，才會有許多人在本身有需求或想法時，樂於創造與分享，也願意彼此模仿與學習，有時在這樣的過程中，想法與樂趣就源源不斷地被激發出來。

回過頭來反思程式設計這個領域，「打造輪子」這個詞應該回歸到中性，有時在某些因素的綜合下，我們確實不應打造輪子，然而，不要打造輪子，不應該成為一個萬用口號，特別是這個口號只會讓你有想法，卻遲遲裹足不前。

別忘了，網路上有許多的開放原始碼，就是不斷打造而產生出來的新輪子，有時甚至會發現自己原地踏步的若干年後，有人把你當初的想法打造出來了。

如果曾經有打造輪子的想法，別管有沒有人做過了，試著打造看看吧！如果還沒有過打造輪子的經驗，那麼或許可以找個有興趣的，做做看。

就算做出來的輪子醜又如何呢？也許多做過幾個醜的，當經驗累積的夠多時，也能做出合用而與眾不同的輪子呢！