我們期待自己成為一個(gè)優(yōu)秀的軟件模型設(shè)計(jì)者，但是，要怎樣做，又從哪里開(kāi)始呢？ 將下列原則應(yīng)用到你的軟件工程中，你會(huì)獲得立桿見(jiàn)影的成果。
1. 人遠(yuǎn)比技術(shù)重要
你開(kāi)發(fā)軟件是為了供別人使用，沒(méi)有人使用的軟件只是沒(méi)有意義的數(shù)據(jù)的集合而已。許多在軟件方面很有成就的行家在他們事業(yè)的初期卻表現(xiàn)平平，因?yàn)樗麄兡菚r(shí)侯將主要精力都集中在技術(shù)上。顯然，構(gòu)件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的東西。但是對(duì)于用戶來(lái)說(shuō)，如果你設(shè)計(jì)的軟件很難使用或者不能滿足他們的需求，后臺(tái)用再好的技術(shù)也于事無(wú)補(bǔ)。多花點(diǎn)時(shí)間到軟件需求和設(shè)計(jì)一個(gè)使用戶能很容易理解的界面上。
2. 理解你要實(shí)現(xiàn)的東西
好的軟件設(shè)計(jì)人員把大多數(shù)時(shí)間花費(fèi)在建立系統(tǒng)模型上，偶爾寫(xiě)一些源代碼，但那只不過(guò)是為了驗(yàn)證設(shè)計(jì)過(guò)程中所遇到的問(wèn)題。這將使他們的設(shè)計(jì)方案更加可行。
3. 謙虛是必須的品格
你不可能知道一切，你甚至要很努力才能獲得足夠用的知識(shí)。軟件開(kāi)發(fā)是一項(xiàng)復(fù)雜而艱巨的工作，因?yàn)檐浖_(kāi)發(fā)所用到的工具和技術(shù)是在不斷更新的。而且，一個(gè)人也不可能了解軟件開(kāi)發(fā)的所有過(guò)程。在日常生活中你每天接觸到的新鮮事物可能不會(huì)太多。但是對(duì)于從事軟件開(kāi)發(fā)的人來(lái)說(shuō)，每天可以學(xué)習(xí)很多新東西（如果愿意的話）。 4. 需求就是需求
如果你沒(méi)有任何需求，你就不要?jiǎng)邮珠_(kāi)發(fā)任何軟件。成功的軟件取決于時(shí)間（在用戶要求的時(shí)間內(nèi)完成）、預(yù)算和是否滿足用戶的需求。如果你不能確切知道用戶需要的是什么，或者軟件的需求定義，那么你的工程注定會(huì)失敗。
5. 需求其實(shí)很少改變，改變的是你對(duì)需求的理解
Object ToolSmiths公司的Doug Smith常喜歡說(shuō)：“分析是一門(mén)科學(xué)，設(shè)計(jì)是一門(mén)藝術(shù)”。他的意思是說(shuō)在眾多的“正確”分析模型中只存在一個(gè)最“正確”分析模型可以完全滿足解決某個(gè)具體問(wèn)題的需要（我理解的意思是需求分析需要一絲不茍、精確的完成,而設(shè)計(jì)的時(shí)候反而可以發(fā)揮創(chuàng)造力和想象力 - 譯者注）。 如果需求經(jīng)常改動(dòng)，很可能是你沒(méi)有作好需求分析，并不是需求真的改變了。 你可以抱怨用戶不能告訴你他們想得到什么，但是不要忘記，收集需求信息是你工作。 你可以說(shuō)是新來(lái)的開(kāi)發(fā)人員把事情搞得一團(tuán)糟，但是，你應(yīng)該確定在工程的第一天就告訴他們應(yīng)該做什么和怎樣去做。 如果你覺(jué)得公司不讓你與用戶充分接觸，那只能說(shuō)明公司的管理層并不是真正支持你的項(xiàng)目。 你可以抱怨公司有關(guān)軟件工程的管理制度不合理，但你必須了解大多同行公司是怎么做的。 你可以借口說(shuō)你們的競(jìng)爭(zhēng)對(duì)手的成功是因?yàn)樗麄冇辛艘粋€(gè)新的理念，但是為什么你沒(méi)先想到呢？ 需求真正改變的情況很少，但是沒(méi)有做好需求分析工作的理由卻很多。
6. 經(jīng)常閱讀
在這個(gè)每日都在發(fā)生變化的產(chǎn)業(yè)中，你不可能在已取得的成就上陶醉太久。 每個(gè)月至少讀2、3本專(zhuān)業(yè)雜志或者1本專(zhuān)業(yè)書(shū)籍。保持不落伍需要付出很多的時(shí)間和金錢(qián)，但會(huì)使你成為一個(gè)很有實(shí)力的競(jìng)爭(zhēng)者。
7. 降低軟件模塊間的耦合度 高耦合度的系統(tǒng)是很難維護(hù)的
。一處的修改引起另一處甚至更多處的變動(dòng)。 你可以通過(guò)以下方法降低程序的耦合度：隱藏實(shí)現(xiàn)細(xì)節(jié)，強(qiáng)制構(gòu)件接口定義，不使用公用數(shù)據(jù)結(jié)構(gòu)，不讓?xiě)?yīng)用程序直接操作數(shù)據(jù)庫(kù)（我的經(jīng)驗(yàn)法則是：當(dāng)應(yīng)用程序員在寫(xiě)SQL代碼的時(shí)候，你的程序的耦合度就已經(jīng)很高了）。 耦合度低的軟件可以很容易被重用、維護(hù)和擴(kuò)充。
8. 提高軟件的內(nèi)聚性
如果一個(gè)軟件的模塊只實(shí)現(xiàn)一個(gè)功能，那么該模塊具有高內(nèi)聚性。高內(nèi)聚性的軟件更容易維護(hù)和改進(jìn)。 判斷一個(gè)模塊是否有高的內(nèi)聚性，看一看你是否能夠用一個(gè)簡(jiǎn)單的句子描述它的功能就行了。如果你用了一段話或者你需要使用類(lèi)似“和”、“或”等連詞，則說(shuō)明你需要將該模塊細(xì)化。 只有高內(nèi)聚性的模塊才可能被重用。
9. 考慮軟件的移植性
移植是軟件開(kāi)發(fā)中一項(xiàng)具體而又實(shí)際的工作，不要相信某些軟件工具的廣告宣傳（比如java 的宣傳口號(hào)write once run many ? 譯者注）。 即使僅僅對(duì)軟件進(jìn)行常規(guī)升級(jí)，也要把這看得和向另一個(gè)操作系統(tǒng)或數(shù)據(jù)庫(kù)移植一樣重要。 記得從16位Windows移植到32位windows的“樂(lè)趣”嗎 ？當(dāng)你使用了某個(gè)操作系統(tǒng)的特性，如它的進(jìn)程間通信(IPC)策略，或用某數(shù)據(jù)庫(kù)專(zhuān)有語(yǔ)言寫(xiě)了存儲(chǔ)過(guò)程。你的軟件和那個(gè)特定的產(chǎn)品結(jié)合度就已經(jīng)很高了。 好的軟件設(shè)計(jì)者把那些特有的實(shí)現(xiàn)細(xì)節(jié)打包隱藏起來(lái)，所以，當(dāng)那些特性該變的時(shí)候，你的僅僅需要更新那個(gè)包就可以了。
10. 接受變化
這是一句老話了：不變的只有變化。 你應(yīng)該將所有系統(tǒng)將可能發(fā)生的變化以及潛在需求記錄下來(lái),以便將來(lái)能夠?qū)崿F(xiàn)（參見(jiàn)“Architecting for Change”，Thinking Objectively, May 1999） 通過(guò)在建模期間考慮這些假設(shè)的情況，你就有可能開(kāi)發(fā)出足夠強(qiáng)壯且容易維護(hù)的軟件。設(shè)計(jì)強(qiáng)壯的軟件是你最基本的目標(biāo)。
11. 不要低估對(duì)軟件規(guī)模的需求
Internet 帶給我們的的教訓(xùn)是你必須在軟件開(kāi)發(fā)的最初階段就考慮軟件規(guī)模的可擴(kuò)充性。 今天只有100人的部門(mén)使用的應(yīng)用程序，明天可能會(huì)被有好幾萬(wàn)人的組織使用，下月，通過(guò)因特網(wǎng)可能會(huì)有幾百萬(wàn)人使用它。 在軟件設(shè)計(jì)的初期，根據(jù)在用例模型中定義的必須支持的基本事務(wù)處理，確定軟件的基本功能。然后，在建造系統(tǒng)的時(shí)候再逐步加入比較常用的功能。 在設(shè)計(jì)的開(kāi)始考慮軟件的規(guī)模需求，避免在用戶群突然增大的情況下，重寫(xiě)軟件。
1. 人遠(yuǎn)比技術(shù)重要
你開(kāi)發(fā)軟件是為了供別人使用，沒(méi)有人使用的軟件只是沒(méi)有意義的數(shù)據(jù)的集合而已。許多在軟件方面很有成就的行家在他們事業(yè)的初期卻表現(xiàn)平平，因?yàn)樗麄兡菚r(shí)侯將主要精力都集中在技術(shù)上。顯然，構(gòu)件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的東西。但是對(duì)于用戶來(lái)說(shuō)，如果你設(shè)計(jì)的軟件很難使用或者不能滿足他們的需求，后臺(tái)用再好的技術(shù)也于事無(wú)補(bǔ)。多花點(diǎn)時(shí)間到軟件需求和設(shè)計(jì)一個(gè)使用戶能很容易理解的界面上。
2. 理解你要實(shí)現(xiàn)的東西
好的軟件設(shè)計(jì)人員把大多數(shù)時(shí)間花費(fèi)在建立系統(tǒng)模型上，偶爾寫(xiě)一些源代碼，但那只不過(guò)是為了驗(yàn)證設(shè)計(jì)過(guò)程中所遇到的問(wèn)題。這將使他們的設(shè)計(jì)方案更加可行。
3. 謙虛是必須的品格
你不可能知道一切，你甚至要很努力才能獲得足夠用的知識(shí)。軟件開(kāi)發(fā)是一項(xiàng)復(fù)雜而艱巨的工作，因?yàn)檐浖_(kāi)發(fā)所用到的工具和技術(shù)是在不斷更新的。而且，一個(gè)人也不可能了解軟件開(kāi)發(fā)的所有過(guò)程。在日常生活中你每天接觸到的新鮮事物可能不會(huì)太多。但是對(duì)于從事軟件開(kāi)發(fā)的人來(lái)說(shuō)，每天可以學(xué)習(xí)很多新東西（如果愿意的話）。 4. 需求就是需求
如果你沒(méi)有任何需求，你就不要?jiǎng)邮珠_(kāi)發(fā)任何軟件。成功的軟件取決于時(shí)間（在用戶要求的時(shí)間內(nèi)完成）、預(yù)算和是否滿足用戶的需求。如果你不能確切知道用戶需要的是什么，或者軟件的需求定義，那么你的工程注定會(huì)失敗。
5. 需求其實(shí)很少改變，改變的是你對(duì)需求的理解
Object ToolSmiths公司的Doug Smith常喜歡說(shuō)：“分析是一門(mén)科學(xué)，設(shè)計(jì)是一門(mén)藝術(shù)”。他的意思是說(shuō)在眾多的“正確”分析模型中只存在一個(gè)最“正確”分析模型可以完全滿足解決某個(gè)具體問(wèn)題的需要（我理解的意思是需求分析需要一絲不茍、精確的完成,而設(shè)計(jì)的時(shí)候反而可以發(fā)揮創(chuàng)造力和想象力 - 譯者注）。 如果需求經(jīng)常改動(dòng)，很可能是你沒(méi)有作好需求分析，并不是需求真的改變了。 你可以抱怨用戶不能告訴你他們想得到什么，但是不要忘記，收集需求信息是你工作。 你可以說(shuō)是新來(lái)的開(kāi)發(fā)人員把事情搞得一團(tuán)糟，但是，你應(yīng)該確定在工程的第一天就告訴他們應(yīng)該做什么和怎樣去做。 如果你覺(jué)得公司不讓你與用戶充分接觸，那只能說(shuō)明公司的管理層并不是真正支持你的項(xiàng)目。 你可以抱怨公司有關(guān)軟件工程的管理制度不合理，但你必須了解大多同行公司是怎么做的。 你可以借口說(shuō)你們的競(jìng)爭(zhēng)對(duì)手的成功是因?yàn)樗麄冇辛艘粋€(gè)新的理念，但是為什么你沒(méi)先想到呢？ 需求真正改變的情況很少，但是沒(méi)有做好需求分析工作的理由卻很多。
6. 經(jīng)常閱讀
在這個(gè)每日都在發(fā)生變化的產(chǎn)業(yè)中，你不可能在已取得的成就上陶醉太久。 每個(gè)月至少讀2、3本專(zhuān)業(yè)雜志或者1本專(zhuān)業(yè)書(shū)籍。保持不落伍需要付出很多的時(shí)間和金錢(qián)，但會(huì)使你成為一個(gè)很有實(shí)力的競(jìng)爭(zhēng)者。
7. 降低軟件模塊間的耦合度 高耦合度的系統(tǒng)是很難維護(hù)的
。一處的修改引起另一處甚至更多處的變動(dòng)。 你可以通過(guò)以下方法降低程序的耦合度：隱藏實(shí)現(xiàn)細(xì)節(jié)，強(qiáng)制構(gòu)件接口定義，不使用公用數(shù)據(jù)結(jié)構(gòu)，不讓?xiě)?yīng)用程序直接操作數(shù)據(jù)庫(kù)（我的經(jīng)驗(yàn)法則是：當(dāng)應(yīng)用程序員在寫(xiě)SQL代碼的時(shí)候，你的程序的耦合度就已經(jīng)很高了）。 耦合度低的軟件可以很容易被重用、維護(hù)和擴(kuò)充。
8. 提高軟件的內(nèi)聚性
如果一個(gè)軟件的模塊只實(shí)現(xiàn)一個(gè)功能，那么該模塊具有高內(nèi)聚性。高內(nèi)聚性的軟件更容易維護(hù)和改進(jìn)。 判斷一個(gè)模塊是否有高的內(nèi)聚性，看一看你是否能夠用一個(gè)簡(jiǎn)單的句子描述它的功能就行了。如果你用了一段話或者你需要使用類(lèi)似“和”、“或”等連詞，則說(shuō)明你需要將該模塊細(xì)化。 只有高內(nèi)聚性的模塊才可能被重用。
9. 考慮軟件的移植性
移植是軟件開(kāi)發(fā)中一項(xiàng)具體而又實(shí)際的工作，不要相信某些軟件工具的廣告宣傳（比如java 的宣傳口號(hào)write once run many ? 譯者注）。 即使僅僅對(duì)軟件進(jìn)行常規(guī)升級(jí)，也要把這看得和向另一個(gè)操作系統(tǒng)或數(shù)據(jù)庫(kù)移植一樣重要。 記得從16位Windows移植到32位windows的“樂(lè)趣”嗎 ？當(dāng)你使用了某個(gè)操作系統(tǒng)的特性，如它的進(jìn)程間通信(IPC)策略，或用某數(shù)據(jù)庫(kù)專(zhuān)有語(yǔ)言寫(xiě)了存儲(chǔ)過(guò)程。你的軟件和那個(gè)特定的產(chǎn)品結(jié)合度就已經(jīng)很高了。 好的軟件設(shè)計(jì)者把那些特有的實(shí)現(xiàn)細(xì)節(jié)打包隱藏起來(lái)，所以，當(dāng)那些特性該變的時(shí)候，你的僅僅需要更新那個(gè)包就可以了。
10. 接受變化
這是一句老話了：不變的只有變化。 你應(yīng)該將所有系統(tǒng)將可能發(fā)生的變化以及潛在需求記錄下來(lái),以便將來(lái)能夠?qū)崿F(xiàn)（參見(jiàn)“Architecting for Change”，Thinking Objectively, May 1999） 通過(guò)在建模期間考慮這些假設(shè)的情況，你就有可能開(kāi)發(fā)出足夠強(qiáng)壯且容易維護(hù)的軟件。設(shè)計(jì)強(qiáng)壯的軟件是你最基本的目標(biāo)。
11. 不要低估對(duì)軟件規(guī)模的需求
Internet 帶給我們的的教訓(xùn)是你必須在軟件開(kāi)發(fā)的最初階段就考慮軟件規(guī)模的可擴(kuò)充性。 今天只有100人的部門(mén)使用的應(yīng)用程序，明天可能會(huì)被有好幾萬(wàn)人的組織使用，下月，通過(guò)因特網(wǎng)可能會(huì)有幾百萬(wàn)人使用它。 在軟件設(shè)計(jì)的初期，根據(jù)在用例模型中定義的必須支持的基本事務(wù)處理，確定軟件的基本功能。然后，在建造系統(tǒng)的時(shí)候再逐步加入比較常用的功能。 在設(shè)計(jì)的開(kāi)始考慮軟件的規(guī)模需求，避免在用戶群突然增大的情況下，重寫(xiě)軟件。