發表文章

目前顯示的是 九月, 2009的文章

大長多多

學生們還是問,為什麼需要軟體工程?和程式設計有什麼不同?為什麼需要作專案管理、監控、控管等等?寫得出程式不是比較實在嗎?

這是因為學生寫的程式太小、參與開發的人太少、專案關係人太少、而維護的時間太短,以致於他們無法想像軟體工程的必要性。
真的軟體專案是『大長多多』的。
到了業界,一個專案要破萬行很容易的,程式一旦,相互關係就會變複雜,動一行指令可能會牽涉到好多地方。所以需要學軟體工程,學如何切模組、作架構設計。學設計概念,知道如何才容易維護、好擴充功能。程式一旦變大,它的成本也會指數性的上升,你需要學習成本估算的方法。
專案的時間通常很,不是一個星期能完成的家庭作業。所以你需要專案文件(幫助你記憶),專案管理(來掌握時間與分配人力)。維護當然把整個時程拉的更長,所以設計的時候要考慮彈性、成本要把維護算進去。在組織人力調配上,你需要考慮開發與維護是否是同一組人。在這麼長的時間裡,各種不同的版本會產生,你需要版本控管的機制,也需要需求管理來控管變更。
學生的作業多是老師給好的題目,於是很難體會為什麼需要系統分析。業界的專案牽涉的人,光是『安排』訪談可能就需要一個月。每個人的意見都不一樣,你必須學習一些系統分析的方法來收集、挖掘、歸納、整理、協調、妥協這些需求,再讓這些需求一個個的被所有人確認。除了清楚的腦袋、好的溝通能力、專業技術的判斷,你也需要一些系統分析的方法論。
一個真正系統的完成,需要的專業知識太多,決不是一個人能夠完成的,我們需要很人一起來開發。如何組織這些人?如何分工?是依照<專案管理師、系統分析師、系統設計師、系統工程師、系統測試人員>來切割?還是依據領域來切割?這麼多人合作,版本管理更重要了。組織也需要定一套一致的 coding standard 及 SOP來提升整體的效率。
學校的『小短少少』的環境有時候很難體會軟體工程的重要性。透過專題的製作與建教合作或許有些幫助。

談談設計原則DIP

圖片
3/21本人寫了一篇文章介紹OCP設計原則 (意即:要延伸一個類別時不能要求修改該類別) ,多少引起一些反應,現在我們利用這篇短文來輕鬆談談,另外一項重要的軟體設計原則:「依存反向原則」(Dependency Inversion Principle - DIP)。

首先我們談談何謂軟體「設計原則」,在軟體發展的領域中,所謂設計原則是:「在發展軟體系統的動作中,一種可接受的規則或方法,也就是說可使用的工作原則」(http://dictionary.reference.com/),好的設計原則必須是能夠協助發展者產生設計主意(idea),而且可以讓設計者能夠透過設計意涵來思考其實際的設計(Rebecca J. Wirfs-Brock 2009),依據這樣的定義,我們所要談的設計原則是可實地應用的,不過原則並非嚴格的設計規則,有如設計樣式(design patterns)一樣,僅在某種環境中使用,過份使用設計原則,可能會增加程式的負擔與工作量,因此,如果你確定類別的功能將來不致改變,則不一定要去使用設計原則,不過大部分的設計原則,都是將實作(implementation)引藏起來,以保持設計的彈性,如OCP或本文即將介紹的DIP。

DIP的定義可見諸於各類設計樣式的書本或網頁,簡言之就是:『抽象不能依存於細節,而細節必須依存於抽象』(Abstraction shouldn't depend on details. Details should depend on abstraction - Rebecca J. Wirfs-Brock 2009),這是何意?我們舉一個簡單的例子:一家公司顧有許多員工,也就是說公司就必須直接依存於這些員工,以軟體結構語言來說,公司是屬於「高階模組」(high-level module),就是上述DIP定義所謂的「抽象」,而員工則屬於「低階模組」(low-level modeule),也就是定義所說的「細節」,如果公司因業務需要必須增聘具有高強能力或專長的員工(也許稱之為super employee),而沒想到使用DIP,則必須修改複雜的公司模組內容,這種修改將影響公司模組的結構,這樣就違反DIP,如果希望增加任何員工而不想影響到公司模組,DIP告訴我們,可以在公司模組與員工模組之間介入一種「抽象層」(abstract layer),公…