工程還是藝術

對於軟體開發這檔子事，長期以來一直有兩種截然不同的看法。有人認為軟體開發是一種工程，因此可以採用工程的方法來控管與執行軟體開發的各項活動，希望能藉此開發出高品質的軟體產品。因此，程式設計師被要求紀錄工作時數、每日撰寫程式碼的數量(包含增加、修改與刪除的程式碼行數)、軟體缺陷 (defects)產生的數量與原因、修復缺陷所花費的時間等等。對於身為程式設計師的你而言，最直接的結果就是有一大堆填不完的報表等著你。近幾年政府與學界在台灣推行的軟體流程改善方法，例如 PSP (不是 Sony 的掌上型電玩，而是 Personal Software Process 的簡寫) 與 CMMI 就是兩個典型的例子。

也有人認為軟體開發比較接近於藝術創作，因為軟體開發屬於是思考性與創作性的活動，這一點和大多數的藝術創作很類似。難道我們會要求畢卡索每天記錄工作時間、畫了幾幅畫、浪費了多少顏料與畫布?

將軟體開發視為藝術創作最大的問題可能是生產力難以預估。大多數的人可以接受創作一件藝術品是需要時間的蘊釀，但我們很難告訴顧客說：「目前本公司的 chief architect正在尋找下一個創作的靈感，因此你們產品交貨的時間將被無限期延後」。

不管我們偉大的阿扁總統告訴我們：「沒有所謂的中間路線，或是新中間路線」，我相信通常對於一個問題有兩種截然不同的看法時，真正比較可行的作法總是介於這兩者之間 。近年來廣為流行的 agile methods 就是一種試圖平衡軟體開發的工程面向與藝術面向的一種方法 。

關於軟體開發倒底是什麼東東，我覺得最好的兩個比喻是 Kent Beck 在 Extreme Programming Explained 這本書中所提出的「開車」(driving)，以及 Andrew Hunt 與 David Thomas 在 The Pragmatic Programmer 這本書中所提出的「園藝」(gardening)。 Beck 認為軟體開發好比開車，並非永遠朝直線前進，而是要打起精神，隨時準備向這邊修正一點、向那邊修正一點。由於改變是軟體開發中唯一不變的事情，因此程式設計師永遠要作好修正的準備。有時候我們甚至要朝向一個完全相反的方向前進 (開錯路 ?!)，但這就是程式設計師的宿命。

Hunt 與 Thomas 認為軟體開發是一種園藝，原始碼就好比花園，身為程式設計的我們是就是園丁。因此我們需要「時時勤拂拭，不使惹塵埃」，我們的軟體才會長的頭好壯壯。想像一下你所看過的所有美麗的花園，如果一個月不去整理那會是個怎樣的情況! 千萬別忽視「雜草」的生命力，一周不除草就可能毀掉你心愛的草坪。因此，Hunt 與 Thomas 進一步提出：「All Programming is maintenance programming 」，因為我們鮮少寫真正新的程式碼，大部分的情況是，我們維護已經存在的程式碼 (無論是寫新的程式碼或是修改、刪除原有的程式碼)，使它變的更好。

在大多數的程式碼還是需要依靠人來撰寫的情況下，我們還是需要抱持著「時時勤拂拭，不使惹塵埃」的心態來照顧我們所開發的軟體。也許有一天 MDA (Modern-Driven Architecture) 與程式碼自動產生的技術成熟到可以取代程式設計師的角色，我們方可昇華到「本來無一物，何處惹塵埃」的境界；只是，我們可能需要擔心工作不保了。