淺談軟體開發中設計的重要性以及錯誤設計的避免和修正

 

淺談軟體開發中設計的重要性以及錯誤設計的避免和修正

 

"If you are failing to plan, you are planning to fail."

—Unknown

 

    前不久的《程式設計師》還專門為黃柳青先生開闢來談“面向構件的開發”。頗有感觸，覺得一個好的軟體設計會讓開發組省力、讓公司省錢、使用者省心。事實上，作為公司其市場受益度還遠遠比這個大，而開發組成員則能在這個開發過程中學習好多的開發經驗。當然，好的軟體設計肯定不是一個專案的成功全部保證，但是絕對是最關鍵的保證之一。

    人們對“軟體設計”的重要性已經有太多的強調，但是我認為無論再怎麼強調也不過分，因為一個好的軟體設計至少會提高軟體的質量、節約開發成本。建立一個軟體系統與其它需要耗費人力與財力的工程是一樣的。如果你要造一幢房子，在開始砌第一塊磚之前，你必須事先畫好建築圖與藍圖。在你開始澆鑄水泥之前，你必須讓人評審你的藍圖並獲得通過，在軟體開發中事先做計劃也與此類似。當然，你也可以反駁我說Linux 系統的實現在事先就沒有詳細的設計說明，是的，但是沒有文字說明並不意味著就沒有設計，相反每一個Linux模組的細節在Linus.Torvalds動手編寫程式碼之前在他的大腦中已經非常清楚了，當然，你也可以不用文字說明你的設計——除非你有Linus.Torvalds那樣的大腦。那麼，“好”的軟體設計有沒有標準呢？John Erik Hansen and Carsten Thomsen  在他們的《Enterprise Development with Visual Studio .NET, UML, and MSF》中簡單的給出以下幾點參考：1.使解決方案符合用途 (Makes the solution usable)， 2. 達到目標使用者的期望(Fullfills the expectations of the target audience) 。3.不易出錯(Isn’t error-prone)。作為商業觀點，他們又給出了兩條，4.提供利益 (Provides benefits). 5.有用(Is useful)。使解決方案符合用途，這是一個最基本的前提，如果解決方案旨在節省使用者管理日程的時間(如電子日曆系統)，則必須保證易用性。若解決方案使日程管理任務更難，或更慢(還不如普通紙張日曆來得快)，則說明滿足不了使用標準，不是一個“好”的設計。達到目標使用者的期望，這一點非常關鍵，也就你在設計軟體的時候要考慮到目標使用者教育背景，計算機技能以及年齡等問題，你總不能以英文介面給那些沒有受過教育或教育程比較低而母語不是英語的使用者群吧！軟體不易出錯也非常重要，如果使用者在使用你的軟體時老是出現一些讓他們摸不著頭腦的錯誤，那麼使用者在情感上就會拒絕使用的你的軟體，而你的信譽度必將及實際利益必然受損，再說，就如寫書的人最怕自己的書前腳擺上書店，後腳就被當廢紙拉回印刷廠，做軟體其實也一樣，如果用拒絕使用的軟體或者對你的軟體有較多的抱怨，對你來說也是一種自信心的打擊。

讓我們來分析一下，“壞”的軟體設計會給你帶來什麼不好之處。首先，影響士氣，事實上一個開發團隊就是一個戰鬥的隊伍，而一個系統架構師就是這場戰爭中將軍，一個將軍要是在戰鬥中使用某個錯誤的決策，勢必敗北。軟體開發與此類似，一個“壞”的設計將會延緩開發速度，導致開發最後超期，打擊士氣併產生惡性迴圈，讓你的軟體遭遇失敗。“夫戰，勇氣也，一鼓作氣，再而衰，三而竭(《左傳.曹劌輪戰》)”的道理在這裡同樣適用。其二、資金損失，如果不改正錯誤設計，而是按時交付產品，則不可避免地損失資金。如果開發的方案供內部使用，則公司無法使用該方案，得不到投資回報，從而蒙受損失。如果解決方案供外部使用，則銷售情況一定難盡如人意，使用者也會要求更正錯誤，當然也會帶來成本的攀升。第三、時間，錯誤設計還會引發時間成本。在需要改正錯誤或撤消設計和開發時，時間成本將凸現出來。另外，專案團隊士氣受到打擊也會減緩開發速度，造成時間延遲。第四、名聲，技術軟體開發人員可逐漸習慣於不完美和失敗，而業務客戶卻不是總能忍耐。如果不更正錯誤設計，則公司的名譽必定受到影響，專案團隊也可能被牽連。如果明知設計有誤，卻堅持交付解決方案，則一定將背上質量低劣的名聲。壞名聲很難去除，會影響未來銷售和內部士氣。

是的，所有的這一切表明一個“壞”的軟體設計是多麼的可怕的事，然而事實上，在真正的設計開發中不可能沒有設計上的錯誤，除非正如Steve McConnell在的《Code Complete》中所指出的那樣——有著“穩定的需求”，軟體開發工作可能從結構設計，到詳細設計，到編碼，都平穩、順利的進行。這簡直是造就了軟體開發的天堂，你可以預測開支，不必擔心最終會冒出一個讓你多花 100 倍錢的錯誤來，然而那不過是一個神話。現在，問題的關鍵是我們怎麼樣去儘量避免和修正這些設計錯誤。首先，充分的理解和把握你的需求，原因很簡單，因為實踐證明，良好的需求是正確軟體設計的前提，換句話說，如果你連需求都不理解，那你設計軟體的依據是什麼？是你頭腦中從教科書上看來的幾個概念？還是想當然、憑感覺？據IBM、GTE、TRW 的一個調查顯示修正在總體結構階段發現的需求錯誤，將比當時就發現並 修正的成本要高出 5 倍，如果是在編碼階段，要高出 10 倍，在單元或系統測試階段，高 20 倍， 在驗收測試階段，高 50 倍，而在維護階段，竟要比原來高出多達 100 倍！在較小規模的計劃中，在維護階段修正錯誤的放大因子可能是 20 而不是 100，因為這時管理費用較低。但無論如何，沒有人願意從自己的收益中拿出這筆錢來。其次，建立一套更改控制過程來應對使用者的典型的變動(還是和需求有關，根據 IBM 的調查，對於一個典型的有一百萬字的需求分析，大約 25%的內容在開發過程中要進行變動)，也就是說建立一個使用者變更審查委員會，使用者變更需求，意識到自己的需要功能更加強大、更加全面的軟體是一種正常的行為，但是過於頻繁的變更而導致開發跟不上他們的進度，則有點不正常了，這時，你可以讓使用者將變更提交給委員會，然後讓委員會去決定是否接受變更並和使用者去溝通和交流，這樣將使大家都會感到寬慰。顧客感到寬慰是因為有專門機構處理他們的意見，會使他們感到自己倍受重視，你感到寬慰是因為現在你只在特定的時候處理變動問題並修正你的設計。第三，合理劃分自己的系統，合理劃分就是指將自己的系統分為多個模組，比如在當前C/S應用開發中比較流行的3 層結構在大模組劃分就比較清晰(見圖1)，這樣你在資料層就專注於資料操作，也便於對外部提供統一的介面，功能層就專注於業務邏輯，而表示層就專層相當於應用的本體,它是將具體

(圖1)

注於與使用者的介面。當然，模組下面又分子模組，也就是說模組得到合理的劃分以後，儘量產用元件開發，這樣你的系統設計就有了一個可容錯能力，在應對變更的時候就不至於那麼“茫然”，那麼“不知所措”或者“牽一髮而動全域性”了。第四，設計者自身的素質以及設計經驗，這一點非常關鍵，優秀的設計者不僅能精確的把握需求，而豐富的設計經驗能讓設計者在初期就考慮到諸多不利的因素，為後期設計變更提供良好的應變對策。第五，理想與現實的平衡，我認為一個具有高度理想主義者是不太適合做軟體設計(當然天才除外)，因為大部分應用軟體的設計是基於“平臺”之上，而任何一個平臺本身均存在一定先天不足，只有瞭解和承認了這些不足，我們才能在此之上設計出效能較為良好的產品。我一個做軟體的朋友給我說了一個他的切身體會——有一次他為一家大型電力公司設計系統，由於他自己過分專注於系統的完美架構，而他未能在系統和效能之間取得一個良好的權衡和折衷，結果，交付使用者以後大資料量的查詢時系統直接把服務當掉，最後，客戶忍受不了，他也忍受不了，不得不重新修改自己的設計，不必說付出那令人吐血的成本，而且還身背惡名，讓公司蒙受潛在的市場損失。

     今天，軟體市場瞬息萬變，市場在擴大的以及生存環境的更加縮小讓每一個軟體設計者不得不認真的思考怎樣才能應對使用者有時近乎無理的要求，這時，一個“足夠好”的軟體設計會讓我們能比競爭對手更快速、更低成本地提供給使用者功能更全、效能更好、更加穩定和易用的產品，幫助公司開拓鞏固和擴充現有業務範圍，挖掘更具潛力的市場。

 

參考資料：《Enterprise Development with Visual Studio .NET, UML, and MSF》，

John Erik Hansen and Carsten Thomsen

         《Code Complete》，Steve McConnell

         《程式設計師》雜誌

 

2005 年12 月 30 日