將下列原則應(yīng)用到你的軟件工程中，你會獲得立桿見影的成果。

1. 人遠(yuǎn)比技術(shù)重要

你開發(fā)軟件是為了供別人使用，沒有人使用的軟件只是沒有意義的數(shù)據(jù)的集合而已。許多在軟件方面很有成就的行家在他們事業(yè)的初期卻表現(xiàn)平平，因為他們那時侯將主要精力都集中在技術(shù)上。顯然，構(gòu)件（ components ）， EJB （ Enterprise Java Beans ）和代理（ agent ）是很有趣的東西。但是對于用戶來說，如果你設(shè)計的軟件很難使用或者不能滿足他們的需求，后臺用再好的技術(shù)也于事無補。多花點時間到軟件需求和設(shè)計一個使用戶能很容易理解的界面上。

2. 理解你要實現(xiàn)的東西

好的軟件設(shè)計人員把大多數(shù)時間花費在建立系統(tǒng)模型上，偶爾寫一些源代碼，但那只不過是為了驗證設(shè)計過程中所遇到的問題。這將使他們的設(shè)計方案更加可行。

3. 謙虛是必須的品格

你不可能知道一切，你甚至要很努力才能獲得足夠用的知識。軟件開發(fā)是一項復(fù)雜而艱巨的工作，因為軟件開發(fā)所用到的工具和技術(shù)是在不斷更新的。而且，一個人也不可能了解軟件開發(fā)的所有過程。在日常生活中你每天接觸到的新鮮事物可能不會太多。但是對于從事軟件開發(fā)的人來說，每天可以學(xué)習(xí)很多新東西（如果愿意的話）。

4. 需求就是需求

如果你沒有任何需求，你就不要動手開發(fā)任何軟件。成功的軟件取決于時間（在用戶要求的時間內(nèi)完成）、預(yù)算和是否滿足用戶的需求。如果你不能確切知道用戶需要的是什么，或者軟件的需求定義，那么你的工程注定會失敗。

5. 需求其實很少改變，改變的是你對需求的理解

Object ToolSmiths 公司（ www.objecttoolsmiths.com ）的 Doug Smith 常喜歡說： “ 分析是一門科學(xué)，設(shè)計是一門藝術(shù) ” 。他的意思是說在眾多的 “ 正確 ” 分析模型中只存在一個最 “ 正確 ” 分析模型可以完全滿足解決某個具體問題的需要（我理解的意思是需求分析需要一絲不茍、精確的完成 , 而設(shè)計的時候反而可以發(fā)揮創(chuàng)造力和想象力 - 譯者注）。

如果需求經(jīng)常改動，很可能是你沒有作好需求分析，并不是需求真的改變了。

你可以抱怨用戶不能告訴你他們想得到什么，但是不要忘記，收集需求信息是你工作。

你可以說是新來的開發(fā)人員把事情搞得一團糟，但是，你應(yīng)該確定在工程的第一天就告訴他們應(yīng)該做什么和怎樣去做。

如果你覺得公司不讓你與用戶充分接觸，那只能說明公司的管理層并不是真正支持你的項目。

你可以抱怨公司有關(guān)軟件工程的管理制度不合理，但你必須了解大多同行公司是怎么做的。

你可以借口說你們的競爭對手的成功是因為他們有了一個新的理念，但是為什么你沒先想到呢？

需求真正改變的情況很少，但是沒有做好需求分析工作的理由卻很多。

6. 經(jīng)常閱讀

在這個每日都在發(fā)生變化的產(chǎn)業(yè)中，你不可能在已取得的成就上陶醉太久。

每個月至少讀 2 、 3 本專業(yè)雜志或者 1 本專業(yè)書籍。保持不落伍需要付出很多的時間和金錢，但會使你成為一個很有實力的競爭者。

7. 降低軟件模塊間的耦合度

高耦合度的系統(tǒng)是很難維護的。一處的修改引起另一處甚至更多處的變動。

你可以通過以下方法降低程序的耦合度：隱藏實現(xiàn)細(xì)節(jié)，強制構(gòu)件接口定義，不使用公用數(shù)據(jù)結(jié)構(gòu)，不讓應(yīng)用程序直接操作數(shù)據(jù)庫（我的經(jīng)驗法則是：當(dāng)應(yīng)用程序員在寫 SQL 代碼的時候，你的程序的耦合度就已經(jīng)很高了）。

耦合度低的軟件可以很容易被重用、維護和擴充。

8. 提高軟件的內(nèi)聚性

如果一個軟件的模塊只實現(xiàn)一個功能，那么該模塊具有高內(nèi)聚性。高內(nèi)聚性的軟件更容易維護和改進。

判斷一個模塊是否有高的內(nèi)聚性，看一看你是否能夠用一個簡單的句子描述它的功能就行了。如果你用了一段話或者你需要使用類似 “ 和 ” 、 “ 或 ” 等連詞，則說明你需要將該模塊細(xì)化。

只有高內(nèi)聚性的模塊才可能被重用。

9. 考慮軟件的移植性

移植是軟件開發(fā)中一項具體而又實際的工作，不要相信某些軟件工具的廣告宣傳（比如 java 的宣傳口號 write once run many ? 譯者注）。

即使僅僅對軟件進行常規(guī)升級，也要把這看得和向另一個操作系統(tǒng)或數(shù)據(jù)庫移植一樣重要。

記得從 16 位 Windows 移植到 32 位 windows 的 “ 樂趣 ” 嗎 ？當(dāng)你使用了某個操作系統(tǒng)的特性，如它的進程間通信 (IPC) 策略，或用某數(shù)據(jù)庫專有語言寫了存儲過程。你的軟件和那個特定的產(chǎn)品結(jié)合度就已經(jīng)很高了。

好的軟件設(shè)計者把那些特有的實現(xiàn)細(xì)節(jié)打包隱藏起來，所以，當(dāng)那些特性該變的時候，你的僅僅需要更新那個包就可以了。

10. 接受變化

這是一句老話了：唯一不變的只有變化。

你應(yīng)該將所有系統(tǒng)將可能發(fā)生的變化以及潛在需求記錄下來 , 以便將來能夠?qū)崿F(xiàn)（參見 “Architecting for Change” ， Thinking Objectively, May 1999 ）

通過在建模期間考慮這些假設(shè)的情況，你就有可能開發(fā)出足夠強壯且容易維護的軟件。設(shè)計強壯的軟件是你最基本的目標(biāo)。

11. 不要低估對軟件規(guī)模的需求

Internet 帶給我們的最大的教訓(xùn)是你必須在軟件開發(fā)的最初階段就考慮軟件規(guī)模的可擴充性。

今天只有 100 人的部門使用的應(yīng)用程序，明天可能會被有好幾萬人的組織使用，下月，通過因特網(wǎng)可能會有幾百萬人使用它。

在軟件設(shè)計的初期，根據(jù)在用例模型中定義的必須支持的基本事務(wù)處理，確定軟件的基本功能。然后，在建造系統(tǒng)的時候再逐步加入比較常用的功能。

在設(shè)計的開始考慮軟件的規(guī)模需求，避免在用戶群突然增大的情況下，重寫軟件。

12. 性能僅僅是很多設(shè)計因素之一

關(guān)注軟件設(shè)計中的一個重要因素 -- 性能，這好象也是用戶最關(guān)心的事情。一個性能不佳的軟件將不可避免被重寫。

但是你的設(shè)計還必須具有可靠性，可用性，便攜性和可擴展性。你應(yīng)該在工程開始就應(yīng)該定義并區(qū)分好這些因素，以便在工作中恰當(dāng)使用。性能可以是，也可以不是優(yōu)先級最高的因素，我的觀點是，給每個設(shè)計因素應(yīng)有的考慮。

13. 管理接口

“UML User Guide” （ Grady Booch ， Ivar Jacobson 和 Jim Rumbaugh ,Addison Wesley, 1999 ）中指出，你應(yīng)該在開發(fā)階段的早期就定義軟件模塊之間的接口。

這有助于你的開發(fā)人員全面理解軟件的設(shè)計結(jié)構(gòu)并取得一致意見，讓各模塊開發(fā)小組相對獨立的工作。一旦模塊的接口確定之后，模塊怎樣實現(xiàn)就不是很重要了。

從根本上說，如果你不能夠定義你的模塊 “ 從外部看上去會是什么樣子 ” ，你肯定也不清楚模塊內(nèi)要實現(xiàn)什么。

14. 走近路需要更長的時間

在軟件開發(fā)中沒有捷徑可以走。

縮短你的在需求分析上花的時間，結(jié)果只能是開發(fā)出來的軟件不能滿足用戶的需求，必須被重寫。

在軟件建模上每節(jié)省一周，在將來的編碼階段可能會多花幾周時間，因為你在全面思考之前就動手寫程序。

你為了節(jié)省一天的測試時間而漏掉了一個 bug ，在將來的維護階段，可能需要花幾周甚至幾個月的時間去修復(fù)。與其如此，還不如重新安排一下項目計劃。

避免走捷徑，只做一次但要做對（ do it once by doing it right ）。

15. 別信賴任何人

產(chǎn)品和服務(wù)銷售公司不是你的朋友，你的大部分員工和高層管理人員也不是。

大部分產(chǎn)品供應(yīng)商希望把你牢牢綁在他們的產(chǎn)品上，可能是操作系統(tǒng)，數(shù)據(jù)庫或者某個開發(fā)工具。

大部分的顧問和承包商只關(guān)心你的錢并不是你的工程（停止向他們付款，看一看他們會在周圍呆多長時間）。

大部分程序員認(rèn)為他們自己比其他人更優(yōu)秀，他們可能拋棄你設(shè)計的模型而用自己認(rèn)為更好的。

只有良好的溝通才能解決這些問題。

要明確的是，不要只依靠一家產(chǎn)品或服務(wù)提供商，即使你的公司（或組織）已經(jīng)在建模、文檔和過程等方面向那個公司投入了很多錢。

16. 證明你的設(shè)計在實踐中可行

在設(shè)計的時候應(yīng)當(dāng)先建立一個技術(shù)原型， 或者稱為 “ 端到端 ” 原型。以證明你的設(shè)計是能夠工作的。

你應(yīng)該在開發(fā)工作的早期做這些事情，因為，如果軟件的設(shè)計方案是不可行的，在編碼實現(xiàn)階段無論采取什么措施都于事無補。技術(shù)原型將證明你的設(shè)計的可行性，從而，你的設(shè)計將更容易獲得支持。

17. 應(yīng)用已知的模式

目前，我們有大量現(xiàn)成的分析和設(shè)計模式以及問題的解決方案可以使用。

一般來說，好的模型設(shè)計和開發(fā)人員，都會避免重新設(shè)計已經(jīng)成熟的并被廣泛應(yīng)用的東西。
http://www.ambysoft.com/processPatternsPage.html 收藏了許多開發(fā)模式的信息。

18. 研究每個模型的長處和弱點

目前有很多種類的模型可以使用 , 如下圖所示。用例捕獲的是系統(tǒng)行為需求，數(shù)據(jù)模型則描述支持一個系統(tǒng)運行所需要的數(shù)據(jù)構(gòu)成。你可能會試圖在用例中加入實際數(shù)據(jù)描述，但是，這對開發(fā)者不是非常有用。同樣，數(shù)據(jù)模型對描述軟件需求來說是無用的。每個模型在你建模過程中有其相應(yīng)的位置，但是，你需要明白在什么地方，什么時候使用它們。

19. 在現(xiàn)有任務(wù)中應(yīng)用多個模型

當(dāng)你收集需求的時候，考慮使用用例模型，用戶界面模型和領(lǐng)域級的類模型。

當(dāng)你設(shè)計軟件的時候，應(yīng)該考慮制作類模型，順序圖、狀態(tài)圖、協(xié)作圖和最終的軟件實際物理模型。

程序設(shè)計人員應(yīng)該慢慢意識到，僅僅使用一個模型而實現(xiàn)的軟件要么不能夠很好地滿足用戶的需求，要么很難擴展。

20. 教育你的聽眾

你花了很大力氣建立一個很成熟的系統(tǒng)模型，而你的聽眾卻不能理解它們，甚至更糟－連為什么要先建立模型都不知道。那么你的工作是毫無意義的。

教給你開發(fā)人員基本的建模知識；否則，他們會只看看你畫的漂亮圖表，然后繼續(xù)編寫不規(guī)范的程序。

另外， 你還需要告訴你的用戶一些需求建模的基礎(chǔ)知識。給他們解釋你的用例 (uses case) 和用戶界面模型，以使他們能夠明白你要表達地東西。當(dāng)每個人都能使用一個通用的設(shè)計語言的時候（比如 UML- 譯者注），你的團隊才能實現(xiàn)真正的合作。

21. 帶工具的傻瓜還是傻瓜

你給我 CAD/CAM 工具，請我設(shè)計一座橋。但是，如果那座橋建成的話，我肯定不想當(dāng)?shù)谝粋€從橋上過的人，因為我對建筑一竅不通。

使用一個很優(yōu)秀的 CASE 工具并不能使你成為一個建模專家，只能使你成為一個優(yōu)秀 CASE 工具的使用者。成為一個優(yōu)秀的建模專家需要多年的積累，不會是一周針對某個價值幾千美元工具的培訓(xùn)。一個優(yōu)秀的 CASE 工具是很重要，但你必須學(xué)習(xí)使用它，并能夠使用它設(shè)計它支持的模型。

22. 理解完整的過程

好的設(shè)計人員應(yīng)該理解整個軟件過程，盡管他們可能不是精通全部實現(xiàn)細(xì)節(jié)。

軟件開發(fā)是一個很復(fù)雜的過程，還記得《 object-oriented software process 》第 36 頁的內(nèi)容嗎？除了編程、建模、測試等你擅長工作外，還有很多工作要做。

好的設(shè)計者需要考慮全局。必須從長遠(yuǎn)考慮如何使軟件滿足用戶需要，如何提供維護和技術(shù)支持等。

23. 常做測試，早做測試

如果測試對你的軟件來說是無所謂的，那么你的軟件多半也沒什么必要被開發(fā)出來。

建立一個技術(shù)原型供技術(shù)評審使用，以檢驗?zāi)愕能浖Ｐ汀?/font>

在軟件生命周期中，越晚發(fā)現(xiàn)的錯誤越難修改，修改成本越昂貴。盡可能早的做測試是很值得的。

24. 把你的工作歸檔

不值得歸檔的工作往往也不值得做。歸檔你的設(shè)想，以及根據(jù)設(shè)想做出的決定；歸檔軟件模型中很重要但不很明顯的部分。 給每個模型一些概要描述以使別人很快明白模型所表達的內(nèi)容。

25. 技術(shù)會變，基本原理不會

如果有人說 “ 使用某種開發(fā)語言、某個工具或某某技術(shù)，我們就不需要再做需求分析，建模，編碼或測試 ” 。不要相信，這只說明他還缺乏經(jīng)驗。拋開技術(shù)和人的因素，實際上軟件開發(fā)的基本原理自 20 世紀(jì) 70 年代以來就沒有改變過。你必須還定義需求，建模，編碼，測試，配置，面對風(fēng)險，發(fā)布產(chǎn)品，管理工作人員等等。

軟件建模技術(shù)是需要多年的實際工作才能完全掌握的。好在你可以從我的建議開始，完善你們自己的軟件開發(fā)經(jīng)驗。

以雞湯開始，加入自己的蔬菜。然后，開始享受你自己的豐盛晚餐吧。