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

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

打造輪子不好嗎?

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

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

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

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

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

從造輪中學習與釐清需求

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

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

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

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

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

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

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

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

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

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

從造輪中激發想法與樂趣

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

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

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

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

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

專欄作者

熱門新聞

Advertisement