土炮精神

在那個程式碼重覆使用（reuse）概念都還沒有相當成型的年代裡，大多數程式設計者，經常做著從頭到尾、刻出所有一套系統所需程式碼的事情。

為何過去程式設計者傾向自己造輪？

即使許多程式語言都有著「程式庫」的機制，但大多數能重覆使用程式碼的範圍，也只限於同一個程式設計者，或同一個開發團隊之內。

我們可以說，那是一個許多程式設計者都重覆地造著「輪子」的年代──為了打造出一部能在道路上行駛的汽車，許多人選擇或是被迫選擇，從輪子開始做起。

除了根本手上根本沒有輪子可用，只好自己從輪子開始造起的情況之外，自命程式設計功力高強的設計者，更偏愛什麼都自己來，因為別人寫的東西自己怎麼看得上眼？

所以，有些高手甚至連基礎的程式庫都自己來，從I/O 、字串處理、日期時間、……甚至到網路伺服器、客戶端程式的程式庫，都不假他人之手，一定是自己一手從頭打造。

程式設計者如今鮮少造輪，大多以組裝軟體組件為主

在過去，我也曾經提過這種心態會產生一種負面的影響，也就是為了從頭打造這些程式碼，以建造新的軟體組件，需要投入相當的生產力，倘若已經有現成的組件可用，不論是程式庫或是應用程式框架，但卻又自己決定自行打造，而這一點無疑是生產力的浪費。

更別說，程式碼的品質需要相當漫長的時間，才能達到一定程度的穩定，現成的軟體組件，多半已經歷過許多開發者，以及專案開發實務的考驗，使其達到一定水平的品質。這代表著，重新建造輪子時，除了撰寫程式碼所需的生產力投入之外，讓程式碼品質穩定到足以應付產品化的需求，更是需要不少的時間。

倘若，大多的開發者選擇針對相當的主題及應用範圍，重覆地建造輪子，那麼，整個世界形同要投入大量的資源及人力，卻浪費在相同的事物之上。

除了生產力的考量之外，重新建造輪子的舉動，多少也帶著不相信別人做的比自己好的心態。就像前面提到的，在那個廣泛自建輪子的年代裡，通常愈是自視甚高的高手，愈是喜歡從輪子做起，反倒是自覺平庸者，在有現成輪子可用的情況下，多半不會考慮自建。為什麼？因為所謂的「高手」不覺得其他人能做的比自己好，而自己一定要用最好的東西。

但事實上呢？這世上能人多到難以想像，到了這個時候，更是天下英雄盡出。許多「輪子」級的程式庫或應用程式框架，都是出自大師手筆。更別提在開放原始碼的協同合作開發模式下，許多程式庫或應用程式框架，都是集眾人之智而成。想要超越，不是不可能，但難度並不低。最多只能安慰自己，起碼，自己設計的，自己用起來比較得心應手罷了。

因此，從生產力或從所得產物優劣的觀點來看，向來都是呼籲大家，應該盡量避免重新建造輪子。挑一個好的輪子，比起建造一個自己覺得會比較稱手的輪子，而且，在大多數情況下，這都會是比較好的選擇。

其實，最近的這些年來，還真的挺少看到什麼開發者重新建造輪子的舉動。我相信，影響這個現象的基礎要件，是軟體元件化的觀念，已經普及到像陽光、空氣和水一樣，大家都習慣了基於現成的軟體元件來開發。

而在這之上，不論是開放原始碼或非開放原始碼的領域中，都有大量唾手可得的軟體元件可用，開發者早就視這些為開發時的「基礎設施」，並且習慣在這些基礎設施之上開發。

而事實也證明，透過這些愈來愈廣泛、愈來愈強大的「基礎設施」，軟體世界的進展一日千里，現時軟體的開發速度，絕非二十年前可相提並論。

現在不要說「輪子」了，就連引擎、變速箱、車架，都有諸多現成品，可供君挑選，依自己的應用需求，做好決定之後，就只要再施加些功夫，就能將它們組裝起來，很快地，變成一部部可以在路上奔馳的汽車了。

現時的開發者，早就習慣透過如此的模式，來獲得高效的生產力，以致於重新建造輪子這個「傳統」的活動，反而不多見了。

自己動手造輪仍有其必要性

幾個月前，同事為了一些目的，自己「土炮」了一個 CDN（Content Delivery Network）的系統。

或許有些人不明白「土炮」的意思，我這麼解釋好了。土炮大概就像是有正規的方法或產物不用，而自己依照自己的方法來達成了。就像 CDN 服務一樣，許多雲端的服務商都提供了 CDN 的服務，也就是說，只要付費，就可以輕易運用他們所提供的 CDN 機制，而且這些機制既完善又可靠。而我們自己做了自己的 CDN 機制，這當然就有不少的「土炮」意味存在。

同事之所以「土炮」了自己的 CDN，當然是基於一些現成的 CDN 所無法滿足其需求的考量。不過這讓我想到了，在這個不太有人自造輪子的年代裡，就少了當年人人土炮各種軟體元件的現象，甚至人們也不土炮些什麼了。

因為重要的軟體組成，幾乎都有現成品可用，從生產力的觀點來看，從用更好產物的觀點來看，都沒有道理再自己土炮了。

這是沒錯的，但是，土炮的精神時至今日還是有其重要性。

我還記得在《世紀末軟體革命》這本書裡，作者之一的劉燈，介紹了自己所做的一個基於事件驅動式的視窗 GUI 系統。當然，產品化的視窗 GUI 系統，會有其更強大的功能，但是自己從無到有建造這樣的系統，有一個很大的好處，是可以幫助你了解、思考建立這樣的系統需要的理論、觀念，更可以幫助你接觸實務上需要考慮的技術細節。

倘若你只是做為一個使用者，或許並沒有辦法如同親身打造一個如此系統一樣，更深入一步去了解及體驗。

做一個系統，畢竟跟用一個系統還是不同。我覺得這就是「土炮」的精神，即使有現成的、類似的產物存在了，但是自己動手做做看，可以看到更多做為使用者時所看不到的東西、接觸更多做為使用者時所接觸不到的東西，更可以讓自己思考更多做為使用者時所不會思考到的東西。

如果我們在軟體開發的領域裡，只做使用者，那麼，很多基礎的東西，我們會愈來愈陌生，甚至就失去把它們做出來的能力了。

自己把某個主題做了一次，即使做的沒有現成的那麼好、那麼強大，但是一些基礎的核心議題必然經歷過一輪，之後，即使只當使用者了，也會更了解這個主題。

而或者，這個「土炮」出來的產物，未來，得以繼續發展，而漸漸地，有了和其他產品分庭抗禮的實力。你能擁有自己土炮的實力之後，當現成的產物無法那麼貼切的滿足自己的需求，才有機會透過自己來滿足這些需求。

從生產力的角度來看，去「土炮」已有的東西，當然是和生產力矛盾的，但正如我所說的，土炮也有土炮的好處，有充足的時間、適合的時機和題目，當然是可以考慮土炮一下。