軟體開發與反饋控制系統 (轉)

軟體開發與反饋控制系統 (轉)[@more@]

開發與反饋控制？這是哪兒跟哪兒呀？你也許會問。我卻發現二者之間有很多相似之處。

 :namespace prefix = o ns = "urn:schemas--com::office" />

反饋控制系統是一種最常見的控制系統。在反饋控制系統中，輸出訊號被檢測出，經控制器處理形成反饋訊號，與輸入訊號相減，從而調節被控制系統的輸入訊號，使輸出訊號趨於穩定。如果反饋控制器失靈，系統輸出值就很容易偏離設定值。

 

我覺得軟體開發實際上是一個複雜的控制系統。需求和開發人員的勞動等是輸入，程式碼及各種文件等是輸出。軟體開發的目標是儘量使開發出的軟體符合使用者需求。而使用者需求也會不斷變化，是一個移動的靶子。這也是軟體開發難的原因之一。怎樣使軟體開發在控制之下（under control）呢？

 

若干年前，我曾參與一個圖形編輯軟體的開發。開發工具是MS1.0。當時我們對已相當瞭解，對面向的程式設計技術也已有所掌握。同事們的幹勁也很高。幾個月後，老闆已能在展覽會上做演示。潛在客戶的正面反應使老闆很興奮。他要求我們不斷實現新功能，以參加一個接一個的展覽。而對發現的錯誤視若無睹，只要不當機就成。表面看來，軟體的開發進展良好。但實際上已問題成堆。功能都實現後，開始修改錯誤。但修改一個錯誤往往會引起其它錯誤。最後我們發現有些關鍵的錯誤簡直就沒辦法，除非做很大的改動。掙扎一段時間後，該專案不得不被放棄。想來真是心痛。

 

究其原因是我們沒有及時查錯，更沒有及時改錯。我們沒有及時得到反饋，即使有反饋，我們也沒有用它來調節我們的行動。有些錯誤在開發階段看起來可能並不嚴重，既沒有造成當機，也沒有造成資料丟失。但它們有可能是軟體結構不合理造成的。這種錯誤如不盡早解決，將後患無窮。即使軟體結構合理並且沒有嚴重錯誤，就能保證軟體是使用者所要的嗎？未必。

 

那麼在開發過程中能得到哪些反饋呢？怎樣才能儘快得到更多的反饋呢？

 

結構化設計建議採用自頂向下、瀑布式的開發方式。這種方法把軟體開發分解成分析、設計、程式設計、測試、釋出等幾個階段。結構化程式設計最大的問題在於：它要求你在開始程式設計前對該軟體有全面、正確的理解。但這樣的機會究竟有多少呢？所以採用結構化程式設計的軟體開發就像一個開環系統，很容易偏離預設的目標。

 

現在漸進迭代式開發(incremental iterative development)日見普及。方法是在軟體開發過程中設定幾個里程碑（mile stone），通常是三、四個左右。每到達一個里程碑時，都要交付使用者或潛在使用者一個可用的初級產品。它可能功能不全，但一定要透過質量控制。這時要聽取使用者的意見。使用者的意見是極重要的反饋，它能保證系統的功能是正確的。每兩個里程碑之間，又劃分成若干迴圈。每個迴圈又由分析、設計、程式設計、測試等步驟組成。通常開發每個功能（feature）的開發都要經過一個迴圈。一個迴圈大約為兩個星期。這時的反饋主要來自開發小組和測試小組。反饋的形式包括設計複查(design review)、程式碼複查(code review)、單元測試(unit test)、功能測試（functional test）等。發現問題及時解決，決不姑息。這些反饋能保證系統結構是正確的。

 

只有結構和功能都正確，你的軟體才能成功。相信大家都學過結構與功能之間的關係。結構決定功能，功能對結構有反作用。通常開發人員更注重結構，而使用者則只關心軟體的功能。忽視了功能，使用者可能不買你的軟體。忽視了結構，軟體將難於維護與擴充套件。漸進迭代式開發有助於你兼顧這兩方面，因為你能及時得到兩方面的反饋。

 

其實，小到做人，大到治理國家，都需要反饋。沒有反饋，就可能走偏、失控。軟體開發又豈能例外？