敏捷方法實務研討會會後筆記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 使用者聽不進去。建議各位請教陳教授。

相關文章

• 敏捷方法實務研討會會後筆記1 - 溝通與 Pair programming
• 敏捷方法實務研討會會後筆記2 - 駐廠使用專家與使用者參與
• 敏捷方法實務研討會會後筆記3 - 反覆式開發過程
• 敏捷方法實務研討會會後筆記4 - 測試驅動開發與工作時程