Pair Prog. TDD &簡化的文件
Anthony Tsai
我 們實驗室這次接工業研究技術院(Industrial Technology Research Institute of Taiwan，以下簡
稱 ITRI)的計畫採用 agile method 的開發方式，由我 Silver 與 Brian (張凱霖) 一同完成。以下就分為三點來分享
我們的經驗。
1. Pair-programming
我們在ITRI計畫中也是遵照agile method 的方法去實現，首先我與Brian對系統的整體架構與程式的思考撰寫過程都是採用 pair-
programming，也就是 pair- thinking，畢竟一個人的思考能力有限，兩人一同思考可以減輕彼此的負擔，例如我們當初思考系統的
ontology部份，我們兩個人就會坐下來一人 拿一枝筆在同一張紙上畫出我們的想法，在規劃ont ology 的過程中，我們互相提出自己的想
法，然後對方就會提出他認為不妥或是與他的想法有衝突之處，意見上的衝突是難免的，我們就會彼此說出自己想法的優點，並且 提出對方思考的缺點，試者以
合併兩人想法為目的的討論方式來解決衝突點。pair- programming當然也用在程式的撰寫上，雖然是兩個人撰寫同一支程式，但不代表就是兩
個人分開來撰寫，而是兩個人坐在同一台電腦前共同思考，一個 人負責打字，另一個人則是用眼睛trace 程式上的邏輯是否正確。現在市面上的
Integrated Development Environment(IDE)工具已經可以幫助programmers檢查syntax上的錯誤，
但是邏輯方面的錯誤還是得依靠programmer 自己去檢查。而pair- programming就是有這樣的好處，一個人的邏輯思考上常常會出
現漏洞，兩個人的邏輯思考卻可以降低這樣的漏洞發生。pair- programming不僅可以提昇工作上的品質，更可以營造出融洽的工作氣氛，以往
的programmer都是一個人撰寫一支程式，遇到問題才與同事間 相互討論的方式來解決，或是自己悶著頭上網找資料或想法；若是採用pair-
programming 的方式，兩個人可以在討論問題之餘穿插個閒話家常，這樣看似是在浪費時間，但是實際上是可以降低彼此腦部思考的壓力，因為一直
想同一件事是容易想不通透 的，那何不放下心情來降低腦中的壓力後再來思考，這樣對於事情的進展反而是更有幫助的。
2. Test-Driven Development(TDD)
TDD的精神來自於先有測試，才有程式。我們在計畫中透過思考scenario來產生出class與method的interface，有了這些
interfaces後，我們開始針對interfaces撰寫test code，使用JUnit __frame__work幫助我們完成。而
test code 的內容就是根據scenario中使用者動作來模擬，撰寫使用者可能的input與使用者期望的output方式來完成。接著就是
根據使用者的動作，來撰 寫出這些interface 內部的pseudo code，pseudo code的用意在於紀錄programmer的思
考過程，並且是以一種top-down的方式進行：一開始programmer會先將abstract level高的想法寫下來，在依序的將這些
pseudo code的abstract level逐步降低。一旦完成了pseudo code的撰寫，接著就要在增加test code 的內
容，原先的test code是只有在class與method的interfaces訂定後所撰寫的black box testing，在完成
pseudo code之後所要撰寫的test code則是屬於white box testing，用來驗證邏輯中的各種可能發生的情況，以利於之
後debug時期的錯誤偵測。當pseudo code的abstract level足夠到可以很輕易的補上source code時，才將
source code補上去，接著就是執行最早就完成的test code來驗證我們pseudo code的正確性。對於我們算是第一次使用
agile method來開發正式的計畫來說，一開始是很難適應的，因為以往我們的觀念都是：快速的完成可執行的程式來提前進度。但是這樣的想法其實
是錯誤的，快速 的交件不見得是一件的好事，因為軟體的發展是要看長遠性的，如果軟體不能根據客戶的需求而具有可變更的彈性，那軟體就是失敗，軟體就不
是活的而是死的，這是陳振炎教授一直時時提 我們 的觀念。不過當我們試著去實現agile method，才發現原來一開始看似繁瑣的
test code與pseudo code其實對於日後維護與程式的變更都是有幫助的，所以這就是軟體可以活下去而programmers可以更容易
完成工作的契機。
3. Document 的抉擇
Document一直是programmers心中的噩耗，因為當programmer被要求撰寫文件時，其實是很枯燥乏味的。Agile
method的manifesto中提到：Working software over comprehensive documentation。但
是文件有時候是必要的，那我們要如何拿捏？其實，pseudo code就是最好的文件，programmer在進行程式的維護時，直接可以看到
pseudo code與source code而不必另外開啟一堆文件檔案，因為pseudo code就是programmer當初思考的過程，維
護的人可以很輕易的去回顧或是進入程式中的semantic。所以我們在ITRI計畫中盡量的減少文 件，並且將一些不必要的文件很大膽的直接刪除！因
為文件越多同步化的工作就要越多，programmer的事情一多就很容易造成品質的下降，但是文件如果沒有與programmer的思考同步，那文件
就形 垃 圾。將重要的文件留下，將不要的文件大膽的丟進垃圾桶中。
陳振炎教授時常的提醒我與Brian：Slow, but firm。趕是不對的，工作是要慢條斯理但是卻很踏實的！不要有壓力的工作，才會有更好的品
質。這樣的工作態度似乎與台灣現在的業界背道而馳，但是為何台灣的軟體產業總是走不出國際， 我想這些原因都是值得深思的。