最近更新: 2007-06-25

敏捷方法實務研討會會後筆記5 - 資料結構與虛擬碼

資料結構與演算法

喔,各位沒看錯,陳教授確實把資料結構與演算法列入他規劃的敏捷方法 (myAgile) 條目中。我看到這一點是非常 Orz

陳教授有提到理由,台灣的程式設計教育重視計算與解題,而不重視思考與建構。所以程序員常常學了資料結構與演算法之後,卻不會運用在實際的編程工作上。故此他特別把這一點列入 myAgile 條目中。

陳教授的說詞很婉轉,要我的話就直接說台灣的教育失敗,教出了一堆不及格的程序員。連我這個非科班生都知道什麼時候該用什麼資料結構與演算法,那些科班生竟然不知道。不如砍掉重練,當掉重修。

陳教授還提到一些包含 Refactoring, Design patterns 在內的編程內容。但都指向同一問題,即程序員的技術功底不夠紮實,需要進行在職訓練。拳訣有云「練拳不練功,到老一場空」。十幾年前,包含我在內的程序員,每個都想當 Bill Gates ;現在每個都想當楊致遠。可我那時至少還知道 Bill Gates 是個有十足技術功底的 BASIC 解譯器開發者(不信的人去看看《彈指乾坤:蓋茲微軟傳奇》的內容,那本書當年可是程序員人手一冊的勵志讀物),楊致遠也是研究搜尋演算法的博士。那些菜鳥的功底在哪?才寫三、五年程式就想要升官當經理。那還遠遠不夠啊。台灣的軟體產業缺乏資深程序員,早非一日之寒。

基本上我認為在 Pair programming 的過程中,這些編程經驗就可以潛移默化到新進人員身上了。

虛擬碼(pseudo code)的使用

陳教授太強調虛擬碼,基本上這不是敏捷方法的通則,只針對 Java/C# 的程序員才有此需要。

陳教授對虛擬碼的使用有些極端了。他說我們應該把虛擬碼放在前面,程式碼放在後面不顯眼的地方。這句話聽在 Python 使用者耳中,八成要當場高喊「有異議」了。Python 是非常重視可讀性的動態語言,直接把空格的使用納入語法規則中,以縮排和空行表達區塊。按陳教授的用法來寫 Python 程式,解譯時必將錯誤連連。我也覺得不妥。在我看來,高階程式語言就具有可讀性,我們應該只需要在部份較不直覺的內容後添加適當的注釋即可。

《人月神話》中提到,隨著程式語言的高階化,我們可以直接用程式碼並保持可讀性。而這句話的背景是從組合語言(Assembly)到 PL/I 語言的時代。

自我說明程式。資料處理的基本原則告訴我們,嘗試同步維護不同的文件是件愚蠢的事... 我認為解決方案是合併文件,把書面說明整合到程式碼,這種做法稱為程式的自我說明 (self-documenting)。很明顯地,把流程圖納入程式裡是很糟的做法,但如果取消流程圖的必要性,並改以高階語言為主,這將使程式與文件的整合變為可行。 Brooks,人月神話

附帶一提,在前篇《會後筆記3》中,我提到了 Ruby on Rails 的高生產力。《人月神話》也指出運用高階語言和交談式程式編寫(interactive programming)可以倍數提高生產力。如果採用了合適的高階語言,軟體開發的生產力也許可以提升到五倍(第8章)。Harr 所提供的資料顯示,若以交談式工具來編寫軟體程式,至少會得到兩倍生產力的效果(第12章)(Brooks,人月神話)。動態語言符合這兩個條件。以此推算, Ruby 和 PHP 等語言的生產力高於 Java 5~10倍的說法,早有經驗與數據支持。

我剛學程式設計時,學得是 QuickBASIC 跟組合語言,並在同一程式中混用兩種語言進行開發工作。基於此一經驗,我十分認同 Brooks 的說法。較高階的程式語言本身就具有較高的可讀性。當我們開始使用高階語言時,就應該讓程式碼本身具備可讀性。至於用虛擬碼取代程式碼在視覺上之主導地位 (亦即令虛擬碼在前,程式碼在後) 的方式,不僅沒有必要,還會增加編寫與修改上的困擾。我個人喜歡誇張地說:「好的程序員看程式碼像在看報紙。同時,在編寫時就會令程式碼像報紙一樣可讀。」

對 PHP, Ruby, Python 等語言的使用者而言,實在沒必要如此強調虛擬碼的使用。因為它們的語法已經非常接近虛擬碼了。

為什麼 Java 沒有帶來可讀性,使陳教授認為 Java 程序員該用虛擬碼?由於我心中早有定見並捨棄了 Java 。同時我也不想在此掀起無謂的筆戰 - 反正我不是 Java 權威,我說的內容,Java 使用者聽不進去。建議各位請教陳教授。

相關文章
樂多舊網址: http://blog.roodo.com/rocksaying/archives/3527607.html