總是要到驗收前，才會發現程式品質有問題？(上)

葉木金 2008/01/30 05:00:00 張艾嘉的＂童年＂唱著＂總是要等到睡覺以前，才知道功課只做了一點點。其實，軟體專案團隊在專案開發的過程中，常會面臨總是要到驗收前，才會發現程式品質有問題的困境。需求的不斷變化、資源的短缺、時間的急迫性、以及技術的難以掌握等。這些事件雖然都將直接影響專案的產出與品質，並且會令開發者會感到相當困擾，但只要存在希望，問題都還是可以有解決之道的。然而，在什麼情況下，專案發生了什麼事會讓開發者完全失去希望，並且感到他的世界相當悲慘呢？

相信許多人都會同意，總要等到專案驗收前，才發現程式品質有問題是一件很令人沮喪的事情。而筆者根據軟體專案實務經驗也發現，對軟體開發者而 言，最悲慘的事件莫過於在專案臨驗收之際，才發現程式沒有合乎品質上要求。

軟體開發者的悲慘世界

筆者用一個笑話來比喻這種開發者的悲慘世界。話說有三兄弟開車回家，就在車停妥在停車場時，突然發現大樓停電了。很不巧的是，他們住在五十樓，停電沒辦法坐電梯，於是他們只能用爬樓梯的方式回到他們居住的地方。

爬到十樓的時候，大哥建議每人講一個最悲慘的故事，並且從他開始。大哥說：「從前有一個人從小就沒有父親，是由母親含辛茹苦地養大，好不容易稍稍有了一點小成就想要報答母親時，母親卻病死了。」，說完時他們己經到了二十樓。

二哥接著說：「從前有一對情侶非常相愛，男孩要出國留學，女孩也發誓不管多久一定會等他回來，四年之後男孩終於學成歸國，女孩也堅貞如是，但是女孩卻在去接他的途中出車禍，當場死亡。」講到這裡時，不知不覺的已經到了四十樓。

這個時候，沒想到三弟只不過說了一句話，三兄弟馬上坐在樓梯上大哭。他說：「大哥，二哥，對不起，我忘了把鑰匙放在車上了！」

軟體開發者的悲慘世界就像這個笑話一樣，眼看目標就在眼前，這時卻發現最關鍵的地方，軟體品質沒有達到要求而即將前功盡棄。而更令人絕望的是，在最後一刻才發現這樣的窘境，此時要及時彌補缺失卻是相當困難的。

就像笑話中的三兄弟一樣，他們必須有人回車上拿鑰匙，而原來走過的路要再重新再走一次。軟體專案開發也是一樣，先前沒做好的開發作業必須回過頭重新把它們做好，而後續的開發作業也必須重做一次。但問題是客戶馬上就要驗收，開發者通常已經沒有足夠的時間來解決問題了。

對於開發者而言，這樣的悲慘世界可真是可怕的夢魘呀。然而，這樣的現象為什麼老是一而再，再而三地發生，到底是什麼地方出了問題呢？顯然問題多半出在開發者無法儘早發現程式瑕疵並及時因應，卻讓自己在茫然無知的狀況下，讓問題不斷地惡化下去。

依據筆者的實務經驗顯示，這種現象可以從開發者的紀律、確認與驗證的過程兩方面來理解。

開發者的紀律

可能有些人會把無法早期發現程式瑕疵歸咎於「無常」兩字，就像笑話中大哥、二哥所提供的故事一樣。的確，軟體專案的本質是充滿不確定性的，實際上會發生的問題是很難事先預料得到的。然而，但當我們經過深入地去檢討後卻常常可以發現，藉由良好的開發者紀律可以減少因為一時疏忽而產生不良後果。就如同笑話中三弟所言的疏忽一樣，許多程式的瑕疵是因此在剛開始分析或設計時就己經存在了需求或設計規格中，但卻直到最後一刻才會被發現。

依據筆者的觀察，一些軟體開發者在分析或設計時，經常不會事先思考需求或設計規格的驗證問題，而是等到程式實作出來過後才會開始思考測試該如何進行。由於在需求或設計規格上，並沒有思考到如何驗證的問題，其內容就常常就會因為不夠完備而顯得草率而馬虎，自然使得程式碼的產出常常會缺東漏西，甚至產生一些錯誤。

而等到開發者在開始進行編程時，規格上所缺漏的部分自然就不會被實作出來，而需求與設計的錯誤更會具體地被實作在程式碼當中。當然部分需求或設計的疏漏與錯誤，可藉由在實作的過程中被發現。但對於一些經驗、能力不足、或態度不夠積極的程式實作人員而言，他們通常只會按照規格來開發程式，而不會去進行溝通並發展良好的程式結構來解決工作上的問題。

另外，有些開發者會習慣於暫緩程式的驗證，他們總以為進行程式的開發遠比進行測試驗證還來得要有生產力，甚至在面對時程的壓力時，會選擇省略功能測試，期望以整合測試或系統測試來將測試問題延後處理。

因此，以上種種原因，使得測試作業太慢開始、程式碼之中散佈著因為需求或設計規格、或實作結構問題所產生的一些疏漏或錯誤，這些現象使得程式瑕疵擴散或蔓延的速度比修正的速度還來得快。當程式的瑕疵愈變愈多、除錯就會顯得更困難，對程式的除錯與測試都是個沉重的負擔，更不用說可以及早發現程式中的瑕疵了。