在那個程式碼重覆使用(reuse)概念都還沒有相當成型的年代裡,大多數程式設計者,經常做著從頭到尾、刻出所有一套系統所需程式碼的事情。
為何過去程式設計者傾向自己造輪?
即使許多程式語言都有著「程式庫」的機制,但大多數能重覆使用程式碼的範圍,也只限於同一個程式設計者,或同一個開發團隊之內。
我們可以說,那是一個許多程式設計者都重覆地造著「輪子」的年代──為了打造出一部能在道路上行駛的汽車,許多人選擇或是被迫選擇,從輪子開始做起。
除了根本手上根本沒有輪子可用,只好自己從輪子開始造起的情況之外,自命程式設計功力高強的設計者,更偏愛什麼都自己來,因為別人寫的東西自己怎麼看得上眼?
所以,有些高手甚至連基礎的程式庫都自己來,從I/O 、字串處理、日期時間、……甚至到網路伺服器、客戶端程式的程式庫,都不假他人之手,一定是自己一手從頭打造。
程式設計者如今鮮少造輪,大多以組裝軟體組件為主
在過去,我也曾經提過這種心態會產生一種負面的影響,也就是為了從頭打造這些程式碼,以建造新的軟體組件,需要投入相當的生產力,倘若已經有現成的組件可用,不論是程式庫或是應用程式框架,但卻又自己決定自行打造,而這一點無疑是生產力的浪費。
更別說,程式碼的品質需要相當漫長的時間,才能達到一定程度的穩定,現成的軟體組件,多半已經歷過許多開發者,以及專案開發實務的考驗,使其達到一定水平的品質。這代表著,重新建造輪子時,除了撰寫程式碼所需的生產力投入之外,讓程式碼品質穩定到足以應付產品化的需求,更是需要不少的時間。
倘若,大多的開發者選擇針對相當的主題及應用範圍,重覆地建造輪子,那麼,整個世界形同要投入大量的資源及人力,卻浪費在相同的事物之上。
除了生產力的考量之外,重新建造輪子的舉動,多少也帶著不相信別人做的比自己好的心態。就像前面提到的,在那個廣泛自建輪子的年代裡,通常愈是自視甚高的高手,愈是喜歡從輪子做起,反倒是自覺平庸者,在有現成輪子可用的情況下,多半不會考慮自建。為什麼?因為所謂的「高手」不覺得其他人能做的比自己好,而自己一定要用最好的東西。
但事實上呢?這世上能人多到難以想像,到了這個時候,更是天下英雄盡出。許多「輪子」級的程式庫或應用程式框架,都是出自大師手筆。更別提在開放原始碼的協同合作開發模式下,許多程式庫或應用程式框架,都是集眾人之智而成。想要超越,不是不可能,但難度並不低。最多只能安慰自己,起碼,自己設計的,自己用起來比較得心應手罷了。
因此,從生產力或從所得產物優劣的觀點來看,向來都是呼籲大家,應該盡量避免重新建造輪子。挑一個好的輪子,比起建造一個自己覺得會比較稱手的輪子,而且,在大多數情況下,這都會是比較好的選擇。
其實,最近的這些年來,還真的挺少看到什麼開發者重新建造輪子的舉動。我相信,影響這個現象的基礎要件,是軟體元件化的觀念,已經普及到像陽光、空氣和水一樣,大家都習慣了基於現成的軟體元件來開發。
而在這之上,不論是開放原始碼或非開放原始碼的領域中,都有大量唾手可得的軟體元件可用,開發者早就視這些為開發時的「基礎設施」,並且習慣在這些基礎設施之上開發。
而事實也證明,透過這些愈來愈廣泛、愈來愈強大的「基礎設施」,軟體世界的進展一日千里,現時軟體的開發速度,絕非二十年前可相提並論。
現在不要說「輪子」了,就連引擎、變速箱、車架,都有諸多現成品,可供君挑選,依自己的應用需求,做好決定之後,就只要再施加些功夫,就能將它們組裝起來,很快地,變成一部部可以在路上奔馳的汽車了。
現時的開發者,早就習慣透過如此的模式,來獲得高效的生產力,以致於重新建造輪子這個「傳統」的活動,反而不多見了。
自己動手造輪仍有其必要性
幾個月前,同事為了一些目的,自己「土炮」了一個 CDN(Content Delivery Network)的系統。
或許有些人不明白「土炮」的意思,我這麼解釋好了。土炮大概就像是有正規的方法或產物不用,而自己依照自己的方法來達成了。就像 CDN 服務一樣,許多雲端的服務商都提供了 CDN 的服務,也就是說,只要付費,就可以輕易運用他們所提供的 CDN 機制,而且這些機制既完善又可靠。而我們自己做了自己的 CDN 機制,這當然就有不少的「土炮」意味存在。
同事之所以「土炮」了自己的 CDN,當然是基於一些現成的 CDN 所無法滿足其需求的考量。不過這讓我想到了,在這個不太有人自造輪子的年代裡,就少了當年人人土炮各種軟體元件的現象,甚至人們也不土炮些什麼了。
因為重要的軟體組成,幾乎都有現成品可用,從生產力的觀點來看,從用更好產物的觀點來看,都沒有道理再自己土炮了。
這是沒錯的,但是,土炮的精神時至今日還是有其重要性。
我還記得在《世紀末軟體革命》這本書裡,作者之一的劉燈,介紹了自己所做的一個基於事件驅動式的視窗 GUI 系統。當然,產品化的視窗 GUI 系統,會有其更強大的功能,但是自己從無到有建造這樣的系統,有一個很大的好處,是可以幫助你了解、思考建立這樣的系統需要的理論、觀念,更可以幫助你接觸實務上需要考慮的技術細節。
倘若你只是做為一個使用者,或許並沒有辦法如同親身打造一個如此系統一樣,更深入一步去了解及體驗。
做一個系統,畢竟跟用一個系統還是不同。我覺得這就是「土炮」的精神,即使有現成的、類似的產物存在了,但是自己動手做做看,可以看到更多做為使用者時所看不到的東西、接觸更多做為使用者時所接觸不到的東西,更可以讓自己思考更多做為使用者時所不會思考到的東西。
如果我們在軟體開發的領域裡,只做使用者,那麼,很多基礎的東西,我們會愈來愈陌生,甚至就失去把它們做出來的能力了。
自己把某個主題做了一次,即使做的沒有現成的那麼好、那麼強大,但是一些基礎的核心議題必然經歷過一輪,之後,即使只當使用者了,也會更了解這個主題。
而或者,這個「土炮」出來的產物,未來,得以繼續發展,而漸漸地,有了和其他產品分庭抗禮的實力。你能擁有自己土炮的實力之後,當現成的產物無法那麼貼切的滿足自己的需求,才有機會透過自己來滿足這些需求。
從生產力的角度來看,去「土炮」已有的東西,當然是和生產力矛盾的,但正如我所說的,土炮也有土炮的好處,有充足的時間、適合的時機和題目,當然是可以考慮土炮一下。
專欄作者
熱門新聞
2024-11-05
2024-11-05
2024-11-07
2024-11-04
2024-11-02
2024-11-07