多用程式, 少寫程式
把組合的觀念用在個人的知識, 我們會將自己的舊知識盡量拿出來重複使用; 同樣的觀念用在人類的集體知識, 我們應該盡量使用既有的程式來解決我們的問題, 也就是要 "站在前人的肩膀上", 而不要一直 "重新發明輪子", 甚或像某些軟體公司一樣, 老是 "踩在前人的腳趾頭上"。
在 著手寫程式 之前, 你可曾用心地從下列資源當中 尋找可用的程式, 來減輕你的工作份量?
1. 手邊現成的應用軟體。
要把 X-Window 上的某個視窗印出來嗎? RedHat 或 CLE 的 CD 上本來就有一個 xwpick 可以用 (轉換檔案格式要配合 libgr-progs 內的工具)。 要限制部分網頁的瀏覽權限? 在 apache 內只要設定數個 Auth* directives 就可以了, 不必寫 cgi 程式。 要把整個目錄下所有的 .php 檔改成 .html 檔? 可以用 find 和 sed 啊! (對不起, 我只舉得出 Linux 上的例子; 不過我相信 MS Windows 下的程式一樣還有許多待人發掘的特異功能; 你知道光是 MS Word 的巨集功能就可以做多少與文書處理不相關的事嗎?)
2. 網路上現成的應用軟體。
Linux Software Map 內或許可以找到你要的程式, 甚至已有 現成的 rpm 檔 可以直接拿來使用。 (自己編譯核心或應用程式當然也是一個很好的練習方式; 但初學者為了趕快上手多用編譯好的程式不也是 "站在前人的肩膀上" 嗎?) 要把你的 html 檔案好好地整理乾淨? 有 tidy 可以用。 要作複雜的線性代數, 甚至迴歸分析或統計學的運算? 何不試試 octave 或 rlab 以及 R。 要畫 (離散數學當中的) graph 嗎? dia, xfig 和 angela! 都可以的。
3. 你所使用的語言內所附的標準程式庫。
要用 C 語言排序嗎? 在 stdlib 當中有 qsort。 要用 C++ 寫 symbol table 嗎? 在 STL 當中的 map 就是為此而設計的。 要用 perl 寫 CGI 程式嗎? 何不直接 use CGI;
4. 現成的外掛程式庫。
要在文字模式下移動遊標, 改變顏色, ...? 不妨試試 ncurses。 要寫漂亮的圖形界面? 只要你選用的語言不是一個 evolutionary deadend, 一定可以與 Tk 連結。 剛才矩陣運算的問題, 如果真的有必要在這麼低階的層次做的話, 可以考慮 libblas, liblapack, ..。 等等。 要把程式目前的狀態存入檔案中嗎? 在 perl 內有 Data:
umper 可以用。
而且所謂 "可用的程式" 可能遠比我們想像的更要無所不在。 很多時候限制一個軟體使用範圍的, 可能不是程式本身, 而是使用者的想像力與對該軟體的了解。 C 的標準程式庫當中既已提供了 qsort, 實在不需要再自己重寫排序程式; 眾多應用程式都支援 regular expression, 有很多場合實在不需要再用滑鼠辛苦地重複剪貼工作。 尤其像是 perl 這類 scripting language, 乍看之下似乎與我們要解決的問題無關, 但事實上卻經常是最簡單的 "可用程式"。 例如想要分析一天當中, 每個小時上我們網站的人次, 可以下:
perl -ne 'print "$1\n" if /
\d+):/' /var/log/httpd/access_log > x
sort x | uniq -c | perl -pale '$_=join " ", reverse @F' > y
然後進入 gnuplot 下
set style data lines
plot "y"
就完成了。 究竟多花一些時間寫程式比較值得呢? 還是多花一些時間學用程式比較值得呢? 學寫完整的程式容易呢? 還是學用程式容易呢? (註: 嚴格來說應該只計算讀取成功的部分。 上例中比對字串處應修改如下: ..。 if /
\d+):.*"(GET|POST).*?"\s+200\s/ ..。 但再怎麼改, 這個 "命令" 的長度還是比相同功能的 java 或 c 程式短很多.)
有人說我們一般人的大腦只使用了十分之一不到; 隨著軟體越來越多, 越來越複雜, 我們對既有軟體的使用程度可能遠在這個數字之下, 甚至不知道找了好久的功能其實就在自己每天隨身攜帶的 CD 當中, 甚至就在自己天天使用的某個軟體之中! (我自己的切身經驗啦 ...) 換句話說, 我們這個社會真正最缺乏的其實並不是專門製作 "全功能應用程式" 設計師, 而是懂得把既有的數個應用程式適當設定, 重新組合, 完成連這些程式作者都沒想像過的工作, 這種會思考的使用者。
目前有許多企業僱主的思考方式依舊是: "花錢買軟體的使用權" 而不是 "花錢僱人幫我善用或小幅修改既有軟體", 所以這種人才的就業市場或許還不是很成熟。 告訴這些僱主 "擁有得多, 不如使用得巧" 正是我未來的工作重點之一。 不論社會大眾何時覺醒, 我們資訊從業人員都應該把眼光放遠, 及早開始做長遠的學習投資, 用有效率的學習方式, 學習可以活用組合的知識。 希望有一天, 社會大眾終於會知道: 僱用一位 會思考/選擇/組合既有程式的使用者, 比買一套具有漂亮使用者介面的 "全功能應用程式" 更能幫助自己解決切身獨特的問題; 希望有一天, 社會大眾終於會知道: 身邊有一位 會思考/選擇/組合既有知識的讀書人, 比擁有一套印刷精美的 "宇宙真理全集" 更能幫助自己解決切身獨特的問題。
當然筆者並非反對寫程式, 只是說寫程式之前要三思 (然後認真找過)。 什麼時候該寫程式呢?
1. 寫程式不是手段, 而是目的: 例如純粹為了興趣而創作 (就像很多人畫圖, 寫歌, 寫詩, ..。 純粹為了興趣而創作一樣)。 以興趣為動機而創作的人, 是最幸福的人。 不論你寫的程式有沒有用, 不論是否已有現成的程式可以用, 請盡量寫吧!
2. 為了要練習, 為了要了解。 例如寫老師出的作業, 寫課本與參考書上的習題。 就像數學系的學生要不斷地重複證明前人已證過的定理一樣, 練習是學習過程當中很重要的一個環節。
3. 你需要解決的問題確實沒有人解決過, 而且這是一支「組合性」低的程式: 它只適用於此時此地, 專為滿足這位主管或客戶的要求所設計; 換個應用場合就必須看得懂程式的人再進入加以修改。 例如網頁設計或資訊管理系統等往往是這樣的狀況。 這當然非自己寫不可; 但是其中經常仍有不少地方可以撿現成的程式庫來組合。 (順便一提, 寫這種程式並不是靠版稅賣錢, 而是靠服務賺錢; 與自由軟體的觀念並不衝突.) 通常最適合這種狀況的語言是某種 scripting language
4. 你需要解決的問題確實沒有人解決過。 而且這是一支「組合性」高的程式: 它的功能介定非常明確, 操作或使用的介面與實作的細節非常獨立, 可以讓很多不了解細節的人在不同的場合使用。 如果你首先寫出來這樣的程式, 不僅可以解決自己眼前的問題, 說不定還可以參與 CLE 計劃 之類的計劃, 把你的成果以 GPL 或 XFree86/FreeBSD 等方式公開授權給大家使用, 成為一位受大家尊敬的駭客。
至於如果寫程式的動機是販售程式使用權, 那恐怕就要三思了。 哺乳動物時代來臨之後, 地球上還是有爬蟲類; 不過那畢竟是少數。 在自由軟體時代來臨之後, 或許還是會有軟體公司能夠持續以版權私有軟體方式生存, 但恐怕也是少數。
從錯誤訊息當中學習
在 Windows 下, 遇到程式出問題時怎麼辦? 「按 OK」 「重新開機」 「重灌應用軟體」 「重灌作業系統」 這些是最常聽到的答案。
這也是令你永遠受制於電腦, 難有進步的答案。
高手與常人的第一個差別在於 "偵探小說" (注意線索) 的學習法 vs 盲目的 "嘗試錯誤" 學習法。 對於自由軟體豐富的錯誤訊息不但不要抱著害怕的態度, 更要把它當成改正下次行為的珍貴線索。 來自 MS Windows 世界的人經常忽略這些非常重要的學習資訊。 這可以理解: 因為 Windows 和上面的許多 proprietary software 在印錯誤訊息時必須非常小心, 不要把過錯攬到自己身上; 而 Windows 的使用者在習於看到沒有意義的錯誤訊息 ("請與程式設計師聯絡" -- "可是我到那裡去找程式設計師的電話號碼啊? 而且, 就算我查得到...他會理大補帖的使用者嗎?") 之後, 便很自然地養成了忽略錯誤訊息的習慣。 但 Linux 和其上的自由軟體則大不相同, 錯誤訊息的目的在於幫助使用者找出問題所在, 那怕是必須承認程式自己的極限或錯誤也無所謂。
想變成電腦高手, 最重要的就是養成注意錯誤訊息的習慣, 要根據錯誤訊息來找出解決方案。 錯誤訊息可以拿來當做關鍵字, 到文件目錄底下搜尋: grep -i '...' `find /usr/share/doc/... -type f` 也可以拿來上 google 搜尋。
對於 server 類的程式, 往往無法直接看到錯誤訊息, 因此 log 檔也非常重要。