怎樣成為優秀的軟件模型設計者

2019-11-18 12:19:45

字體：大中小

來源：轉載

供稿：網友

　　1. 人遠比技術重要
　　
　　你開發軟件是為了供別人使用，沒有人使用的軟件只是沒有意義的數據的集合而已。許多在軟件方面很有成就的行家在他們事業的初期卻表現平平，因為他們那時侯將主要精力都集中在技術上。顯然，構件（components），EJB（EnterPRise java Beans）和代理（agent）是很有趣的東西。但是對于用戶來說，假如你設計的軟件很難使用或者不能滿足他們的需求，后臺用再好的技術也于事無補。多花點時間到軟件需求和設計一個使用戶能很輕易理解的界面上。
　　
　　2. 理解你要實現的東西
　　
　　好的軟件設計人員把大多數時間花費在建立系統模型上，偶然寫一些源代碼，但那只不過是為了驗證設計過程中所碰到的問題。這將使他們的設計方案更加可行。
　　
　　3. 謙虛是必須的品格
　　
　　你不可能知道一切，你甚至要很努力才能獲得足夠用的知識。軟件開發是一項復雜而艱巨的工作，因為軟件開發所用到的工具和技術是在不斷更新的。而且，一個人也不可能了解軟件開發的所有過程。在日常生活中你天天接觸到的新鮮事物可能不會太多。但是對于從事軟件開發的人來說，天天可以學習很多新東西（假如愿意的話）。
　　
　　4. 需求就是需求
　　
　　假如你沒有任何需求，你就不要動手開發任何軟件。成功的軟件取決于時間（在用戶要求的時間內完成）、預算和是否滿足用戶的需求。假如你不能確切知道用戶需要的是什么，或者軟件的需求定義，那么你的工程注定會失敗。
　　
　　5. 需求其實很少改變，改變的是你對需求的理解
　　
　　Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜歡說：“分析是一門科學，設計是一門藝術”。他的意思是說在眾多的“正確”分析模型中只存在一個最“正確”分析模型可以完全滿足解決某個具體問題的需要（我理解的意思是需求分析需要一絲不茍、精確的完成,而設計的時候反而可以發揮創造力和想象力 - 譯者注）。
　　
　　假如需求經常改動，很可能是你沒有作好需求分析，并不是需求真的改變了。
　　
　　你可以抱怨用戶不能告訴你他們想得到什么，但是不要忘記，收集需求信息是你工作。
　　
　　你可以說是新來的開發人員把事情搞得一團糟，但是，你應該確定在工程的第一天就告訴他們應該做什么和怎樣去做。
　　
　　假如你覺得公司不讓你與用戶充分接觸，那只能說明公司的治理層并不是真正支持你的項目。
　　
　　你可以抱怨公司有關軟件工程的治理制度不合理，但你必須了解大多同行公司是怎么做的。
　　
　　你可以借口說你們的競爭對手的成功是因為他們有了一個新的理念，但是為什么你沒先想到呢？
　　
　　需求真正改變的情況很少，但是沒有做好需求分析工作的理由卻很多。
　　
　　6. 經常閱讀
　　
　　在這個每日都在發生變化的產業中，你不可能在已取得的成就上沉醉太久。
　　
　　每個月至少讀2、3本專業雜志或者1本專業書籍。保持不落伍需要付出很多的時間和金錢，但會使你成為一個很有實力的競爭者。
　　
　　7. 降低軟件模塊間的耦合度
　　
　　高耦合度的系統是很難維護的。一處的修改引起另一處甚至更多處的變動。
　　
　　你可以通過以下方法降低程序的耦合度：隱藏實現細節，強制構件接口定義，不使用公用數據結構，不讓應用程序直接操作數據庫（我的經驗法則是：當應用程序員在寫SQL代碼的時候，你的程序的耦合度就已經很高了）。
　　
　　耦合度低的軟件可以很輕易被重用、維護和擴充。
　　
　　8. 提高軟件的內聚性
　　
　　假如一個軟件的模塊只實現一個功能，那么該模塊具有高內聚性。高內聚性的軟件更輕易維護和改進。
　　
　　判定一個模塊是否有高的內聚性，看一看你是否能夠用一個簡單的句子描述它的功能就行了。假如你用了一段話或者你需要使用類似“和”、“或”等連詞，則說明你需要將該模塊細化。
　　
　　只有高內聚性的模塊才可能被重用。
　　
　　9. 考慮軟件的移植性
　　
　　移植是軟件開發中一項具體而又實際的工作，不要相信某些軟件工具的廣告宣傳（比如java 的宣傳口號write once run many ? 譯者注）。
　　
　　即使僅僅對軟件進行常規升級，也要把這看得和向另一個操作系統或數據庫移植一樣重要。
　　
　　記得從16位Windows移植到32位windows的“樂趣”嗎？當你使用了某個操作系統的特性，如它的進程間通信(ipC)策略，或用某數據庫專有語言寫了存儲過程。你的軟件和那個特定的產品結合度就已經很高了。
　　
　　好的軟件設計者把那些特有的實現細節打包隱藏起來，所以，當那些特性該變的時候，你的僅僅需要更新那個包就可以了。
　　
　　10. 接受變化
　　
　　這是一句老話了：唯一不變的只有變化。
　　
　　你應該將所有系統將可能發生的變化以及潛在需求記錄下來,以便將來能夠實現（參見“Architecting for Change”，Thinking Objectively, May 1999）
　　
　　通過在建模期間考慮這些假設的情況，你就有可能開發出足夠強壯且輕易維護的軟件。設計強壯的軟件是你最基本的目標。
　　
　　11. 不要低估對軟件規模的需求
　　
　　Internet 帶給我們的最大的教訓是你必須在軟件開發的最初階段就考慮軟件規模的可擴充性。
　　
　　今天只有100人的部門使用的應用程序，明天可能會被有好幾萬人的組織使用，下月，通過因特網可能會有幾百萬人使用它。
　　
　　在軟件設計的初期，根據在用例模型中定義的必須支持的基本事務處理，確定軟件的基本功能。然后，在建造系統的時候再逐步加入比較常用的功能。
　　
　　在設計的開始考慮軟件的規模需求，避免在用戶群忽然增大的情況下，重寫軟件。
　　
　　12. 性能僅僅是很多設計因素之一
　　
　　關注軟件設計中的一個重要因素--性能，這好象也是用戶最關心的事情。一個性能不佳的軟件將不可避免被重寫。
　　
　　但是你的設計還必須具有可靠性，可用性，便攜性和可擴展性。你應該在工程開始就應該定義并區分好這些因素，以便在工作中恰當使用。性能可以是，也可以不是優先級最高的因素，我的觀點是，給每個設計因素應有的考慮。
　　
　　13. 治理接口
　　
　　“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你應該在開發階段的早期就定義軟件模塊之間的接口。
　　
　　這有助于你的開發人員全面理解軟件的設計結構并取得一致意見，讓各模塊開發小組相對獨立的工作。一旦模塊的接口確定之后，模塊怎樣實現就不是很重要了。
　　
　　從根本上說，假如你不能夠定義你的模塊“從外部看上去會是什么樣子”，你肯定也不清楚模塊內要實現什么。
　　
　　14. 走近路需要更長的時間
　　
　　在軟件開發中沒有捷徑可以走。
　　
　　縮短你的在需求分析上花的時間，結果只能是開發出來的軟件不能滿足用戶的需求，必須被重寫。
　　
　　在軟件建模上每節省一周，在將來的編碼階段可能會多花幾周時間，因為你在全面思考之前就動手寫程序。
　　
　　你為了節省一天的測試時間而漏掉了一個bug，在將來的維護階段，可能需要花幾周甚至幾個月的時間去修復。與其如此，還不如重新安排一下項目計劃。
　　
　　避免走捷徑，只做一次但要做對（do it once by doing it right）。
　　
　　15. 別信賴任何人
　　
　　產品和服務銷售公司不是你的朋友，你的大部分員工和高層治理人員也不是。
　　
　　大部分產品供給商希望把你牢牢綁在他們的產品上，可能是操作系統，數據庫或者某個開發工具。
　　
　　大部分的顧問和承包商只關心你的錢并不是你的工程（停止向他們付款，看一看他們會在四周呆多長時間）。
　　
　　大部分程序員認為他們自己比其他人更優秀，他們可能拋棄你設計的模型而用自己認為更好的。
　　
　　只有良好的溝通才能解決這些問題。
　　
　　要明確的是，不要只依靠一家產品或服務提供商，即使你的公司（或組織）已經在建模、文檔和過程等方面向那個公司投入了很多錢。
　　
　　16. 證實你的設計在實踐中可行
　　
　　在設計的時候應當先建立一個技術原型，或者稱為“端到端”原型。以證實你的設計是能夠工作的。
　　
　　你應該在開發工作的早期做這些事情，因為，假如軟件的設計方案是不可行的，在編碼實現階段無論采取什么措施都于事無補。技術原型將證實你的設計的可行性，從而，你的設計將更輕易獲得支持。
　　
　　17. 應用已知的模式
　　
　　目前，我們有大量現成的分析和設計模式以及問題的解決方案可以使用。
　　
　　一般來說，好的模型設計和開發人員，都會避免重新設計已經成熟的并被廣泛應用的東西。
　　http://www.ambysoft.com/processPatternsPage.Html 收藏了許多開發模式的信息。
　　
　　18. 研究每個模型的優點和弱點
　　
　　目前有很多種類的模型可以使用,如下圖所示。用例捕捉的是系統行為需求，數據模型則描述支持一個系統運行所需要的數據構成。你可能會試圖在用例中加入實際數據描述，但是，這對開發者不是非常有用。同樣，數據模型對描述軟件需求來說是無用的。每個模型在你建模過程中有其相應的位置，但是，你需要明白在什么地方，什么時候使用它們。
　　
　　19. 在現有任務中應用多個模型
　　
　　當你收集需求的時候，考慮使用用例模型，用戶界面模型和領域級的類模型。
　　
　　當你設計軟件的時候，應該考慮制作類模型，順序圖、狀態圖、協作圖和最終

上一篇：使用UML編寫Java應用程序 (2)實現

下一篇：工作流模型分析---聚合模型