漫談開發流程 － 半吊子的輕量級開發

在前一回中，我們提到了徒具形式的開發流程。許多團隊的開發流程，看似井井有條、制度完整，但流程中所規劃的活動，卻無法在開發參與者的進行下，達到它應有的效用。很容易讓程式員產生一種負面的印象
－ 開發流程下的活動不過只是表面文章，只是敷衍了事、徒做虛功。也讓許多開發者，對於開發活程中的活動是敬而遠之。

因此，在光譜的另一邊，也有著一類團隊，他們盡可能的裁減他們所需的開發流程活動。這樣子的團隊，多半是以程式員為主的團隊，對他們來說，程式撰寫以外的工作幾乎都會被歸類為
”overhead（額外負擔）”，就像我們很常見到的，程式員視紙上作業為overhead，因為寫在紙上的東西，往往不能直接轉換成為程式碼，而且有時候甚至和程式碼的產出一點關係都沒有。對他們來說，開發想要更有效率，就要盡可能的減少overhead。當然，文件的撰寫肯定是他們首先要打倒的萬惡罪魁，非到萬不得已、山窮水盡的局面，絕對不讓團隊成員撰寫任何文件，也不會安排任何的文件撰寫活動。我甚至看過，有些團隊的管理者，認為版本管理的活動，是一種對開發者的overhead，因此，雖然他們也建置了版本管理的伺服器，但是，開發者卻不利用版本管理伺服器來進行版本管理的活動。這某種程度算是管理者體貼開發者的一份心意，因為管理者也希望讓程式員專心的撰寫程式碼，盡量的避免其他的活動干擾到這個最主要的工作。對這類的管理者來說，追求制度不過只是形式上的表面功夫，事實上，裡子更勝於面子，產品應該以更有效的方式開發，而要達成這目的，應該盡量的摒除對程式員施加的各種overhead。

尤其近來輕量級的開發方法大行其道，這更讓這類的團隊找到一個依靠，當中有許多人宣稱他們自己是輕量級的開發方法，因為他們摒除了許多開發流程所帶來的overhead，所以他們認為自己的開發方式輕盈無比。我曾經聽過不只一位朋友說過類似的話：「我們採取的開發方法是XP（eXtreme
Programming），我們的釋出週期很短、需求也變更的很頻繁、甚至也沒有太詳細的需求記錄文件、我們幾乎不做細部設計。」這看起來，應該算是誤解了XP，而且只從XP裡頭挑一些對程式員來說算是甜頭的東西出來實行。

怎麼說呢？XP有十二項施行的準則，其中有許多準則是互為支持的。例如，倘若你希望小版本的持續釋出（也就是說需求能夠變更的更為頻繁），你得強化單元測試以及重構。因為當你的需求變更的頻繁時，自然造成程式碼的變更頻繁，倘若沒有足夠的單元測試做為後盾，那麼變更頻繁的程式碼，勢必頻繁的造成副作用，對程式的穩定度造成很大的衝擊。同樣的，倘若沒有持續的進行重構，那麼程式碼最後也會形成疊床架屋的情況。

小版本持續釋出是甜頭，因為需求的提供者可以更快的看到自己所許下的願望被實現。允許需求變更的更為頻繁是甜頭，因為這使得需求提供者能更快的反饋他對開發產物的修正意見。但是，許多號稱是採XP開發方法的團隊，都不做單元測試，他們也不持續的進行重構，因為這兩個工作都是苦差事。單元測試是苦差事，因為在XP強調的測試先行之下，還沒撰寫程式碼之前就得先寫好測試案例，而且每個程式碼單元，都應該搭配著相對的測試案例。要一般的程式員養成撰寫測試案例的習慣，簡直比要他們撰寫文件還要命。重構也是苦差事，不僅許多程式員不具備重構的技巧，即使具備了重構的能力，也抱持著「做好的事，何必再改變」的心態，對於整理程式碼漸漸產生的遺毒，始終興趣缺缺。像單元測試及重構，在許多人的認知裡，都是對程式員的某種
“overhead”。所以，許多團隊柿子挑軟的吃，他們的眼裡只看到可以抄捷徑的地方，卻沒有在意，這些輕量級的開發方法之所以能抄捷徑，是因為有其他的配套。好比，XP之所以允許對需求的描繪盡量精簡，是因為施行準則中有一則是要求客戶駐點，也就是說，客戶（需求提供者）和開發團隊位在同一個地點，因此，客戶能夠很快的看到系統的面貌及行為，也能夠面對面的和開發團隊溝通，減少了所需的文件。倘若沒有客戶駐點的條件相配合，那麼過於精簡的需求描述方式，就會產生極大的危機，因為開發團隊對於需求產生誤解的機會就大上許多。

徒具形式的開發流程固然可怕，但半吊子的輕量級開發，也是兇險異常。這樣子的開發表面上似乎提昇了效率，但是，骨子裡卻暗地的付出許多隱形的overhead－不論開發團隊是否有意識到。例如，因為節省了需求規格文件的撰寫，但又沒有搭配客戶駐點的條件，使得開發團隊不能準確的捕捉客戶的需求，時常在開發完成後，客戶才發現不合預期，因而引發了更多修改的請求，反而白白浪費開發的力氣。又例如，因為允許頻繁的變更，但又無單元測試及重構的活動與之相對應，因而導致程式修改的副作用頻繁發生、程式品質也降低，程式碼架構也漸漸趨向疊床架屋。表面上開發團隊節省了一些功夫，但是無形中卻可能損失更多。

有些開發團隊由於團隊中的程式員技巧高超，所以即使缺乏了某些相對應的配套活動，整體造成的衝擊相較而言有可能不那麼大，因此顯現出來的負面效應也不會太明顯。但這不意謂著抽掉這些活動，對所有的團隊來說都是適宜的。

開發流程是用來輔助開發團隊邁向完成開發目標的一個工具。正如前文中所提到的，開發流程中的活動某種程度來說，算是一種額外的成本，但也是一種投資，我們希望投入一些額外的力氣，使得我們開發的整體成本降低，品質也能維持。這個額外的成本，理想的情況下，我們自然希望能夠降到最低，但又能維持整體成本最低、品質不變（或變的更好）。而輕量級的開發，便是希望能夠降低這投入的成本。

降低因為開發流程活動而造成的損耗，大方向是對的。但是，究竟能節省那些活動，必須根據所面臨的環境、開發的標的物為何、以及開發的限制條件（包括人力的多寡、人力的素質）來決定。

當你的開發團隊決定採取較為輕量化的開發時，最好還是先對一般較為重量級的開發方法有基礎的認識。所有開發方法的發明及設計，都有其動機。開發方法中的活動安排，也都有其原因。你在輕量的開發方法下能略去某些活動，多半都是因為你有其他的條件或是輔助的活動可以相對應，而不致於引發問題。

開發團隊在選用一個開發的流程時，無論輕重與否，都應該根據目前所處的環境以及專案所面對的開發目標，設定所使用的開發流程所應具備的條件。例如，你的開發流程究竟要不要管理需求的變更？你必須知道，若要管理需求變更，究竟會付出多大的代價（好比你可能需要有額外的活動審核需求變更、確定需求變更可能造成的衝擊、並且重新評估開發時程），但可以得到多少好處。倘若不管理需求變更，那麼可以省掉多少力氣，但又會增加多少潛在的風險，而這些風險以專案的環境及條件是否可以降低或是接受。

總的來說，我想表達的是，我們想省掉一些功夫，是因為我們知道因為有某種因素的存在，所以我們可以省去。或者，是因為我們因為某些資源的缺乏（例如時間、人力），也意識到可能會有的風險，而在判斷這風險是可以接受的情況下決定省去。但絕對不是在我們不知道究竟會引發多少負面效果的情況下，冒然的取捷徑。

Posted at 11:31下午 五月 22, 2009 by Chien-Hsing Wang in General  |  迴響[0]