輕鬆談軟工

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

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