讀完《軟件工程》和一些有關(guān)資料后，感覺一些東西都曾經(jīng)接觸過，但在實(shí)際工作中有些理論要完全遵循可能還有些障礙，軟件工程只是提供了理論上的一些結(jié)論，但對(duì)項(xiàng)目的具體可操作性的規(guī)范的制定方面卻做的很少，《軟件工程》發(fā)展了幾十年，光是開發(fā)模型就達(dá)到了10多種，對(duì)不同的項(xiàng)目采用合適的開發(fā)模式，有些項(xiàng)目在不同的開發(fā)階段可能還要轉(zhuǎn)換開發(fā)模式，把它們靈活的應(yīng)用到實(shí)際中還是很困難的?，F(xiàn)在國(guó)內(nèi)外都重視《軟件工程》是因?yàn)椋藗兌颊J(rèn)識(shí)到了如果能夠適當(dāng)合理的利用軟件工程的理論可以減小開發(fā)成本和風(fēng)險(xiǎn)，風(fēng)險(xiǎn)降低了，成本就減少了，利潤(rùn)就提高了，所以有一種說法就是“軟件工程就是提高軟件項(xiàng)目利潤(rùn)的理論”。但人們也都意識(shí)到《軟件工程》的確更接近于理論，它所提供的可操作性太差，于是就有了現(xiàn)在流行的RUP和XP開發(fā)理論，這兩種理論就是根據(jù)《軟件工程》的理論經(jīng)過大量的試驗(yàn)總結(jié)出的比較成功的開發(fā)模式，但RUP對(duì)于大項(xiàng)目還適合，對(duì)于小項(xiàng)目則不利于降低開發(fā)成本，所以現(xiàn)在國(guó)外最受歡迎的是XP?，F(xiàn)在國(guó)內(nèi)也開始使用這種方法，這種方法與其他開發(fā)方法最大的不同是將測(cè)試提到了一個(gè)幾乎是最重要的位置，先寫測(cè)試用例，然后編碼，而且在測(cè)試過程中提倡使用一些自動(dòng)化的測(cè)試工具，如對(duì)Java測(cè)試的Junit和對(duì)Delphi測(cè)試的Dunit。如今的軟件工程已經(jīng)改變了很多，提倡能夠快速適應(yīng)客戶需求變化并能夠根據(jù)變化快速轉(zhuǎn)變開發(fā)方向的開發(fā)方法，國(guó)內(nèi)外充斥著大量的討論能夠提高開發(fā)速度、減少需求變更的開發(fā)模式的書籍，如一些認(rèn)證，如ISO9000，CMM，CMMI等，還有開發(fā)模式，如敏捷開發(fā)，RUP，XP，PSP，TSPi等。在一定情況下，XP是很出眾的，XP對(duì)國(guó)情是否適合可能尚難以下結(jié)論，但XP對(duì)于測(cè)試的重視和對(duì)使用自動(dòng)化測(cè)試工具的推崇則是我們可以借鑒的。

無論是在上個(gè)世紀(jì)還是在現(xiàn)在，軟件開發(fā)所涉及的工作基本上都沒有變化，它們都起始于一個(gè)實(shí)際需要或某個(gè)靈感，然后就是分析，設(shè)計(jì)，編碼，調(diào)試，維護(hù)。這些任務(wù)以某種方式動(dòng)態(tài)地結(jié)合起來就構(gòu)成了軟件開發(fā)的整個(gè)過程，這就是所謂的“軟件開發(fā)周期”。 但對(duì)于這些工作，具體怎樣做，什么時(shí)候做，每個(gè)人都有自己的一套方式，甚至有的人有幾套方式。這樣，當(dāng)幾個(gè)人合在一起干活的時(shí)候，最終的結(jié)果就只能是一片混亂。所以就需要一套規(guī)則，大家都按規(guī)則來辦事，問題就會(huì)少得多。好的規(guī)則就叫做規(guī)范，規(guī)范都是由一些有經(jīng)驗(yàn)的前輩根據(jù)經(jīng)驗(yàn)總結(jié)的，又經(jīng)過長(zhǎng)時(shí)間的歷練，不斷地被補(bǔ)充修正，可以說都是精華，按照規(guī)范來干活，對(duì)于提高軟件質(zhì)量和工作效率自然大有幫助。而軟件工程，用通俗的話講就是，一套用于軟件的團(tuán)隊(duì)開發(fā)，以提高軟件質(zhì)量和程序員工作效率為目的的規(guī)范。其核心就是，對(duì)于軟件開發(fā)的5個(gè)重要組成部分：需求分析，設(shè)計(jì)，編碼，調(diào)試，維護(hù)，如何組織這5個(gè)部分的工作，以及如何完成每一個(gè)工作。簡(jiǎn)單來說，就是對(duì)于總體的組織和對(duì)于局部的實(shí)現(xiàn)。

規(guī)范只是提供一個(gè)好的例子，以描述一種思想，具體到每一個(gè)環(huán)節(jié)怎樣實(shí)現(xiàn)，對(duì)于不同的公司或團(tuán)體則是各有千秋，因?yàn)楦揪筒豢赡艽嬖谝惶追胖煜陆钥尚械臉?biāo)準(zhǔn)。就像C++，也只是提供了一套標(biāo)準(zhǔn)，不同的編譯器都有各自的實(shí)現(xiàn)，對(duì)標(biāo)準(zhǔn)的支持程度也互不相同。所以，在不同的公司或團(tuán)體中，盡管核心思想都是大同小異，但具體到每一個(gè)步驟，往往都是不相同的。  

   我個(gè)人認(rèn)為軟件工程很重要，但更重要的是要能夠根據(jù)不同的項(xiàng)目在不同階段選擇合適的開發(fā)模式，規(guī)避風(fēng)險(xiǎn)，適應(yīng)客戶靈活多變的需求變更。所以對(duì)需求調(diào)研和需求分析提出了更高的要求。我看過了一些討論軟件工程的文章，幾乎一致認(rèn)為“客戶直接參與的項(xiàng)目成功的可能性非常高”，傳統(tǒng)的軟件工程中提出的不論是“瀑布”還是“螺旋”模型都是進(jìn)行階段性的客戶確認(rèn)再開發(fā)，等開發(fā)完或者客戶的需求變了，或者需求分析有錯(cuò)誤，完全符合客戶要求的幾乎沒有。所以我們是否考慮一下能否在條件允許的情況下，在以后的項(xiàng)目的開發(fā)中多征求客戶意見，而不是在一階段完成后再請(qǐng)客戶看，這有利于我們降低開發(fā)大規(guī)模修改的風(fēng)險(xiǎn)。這也是“極限開發(fā)”模式中很重要的一點(diǎn)。當(dāng)然這也不是絕對(duì)的，但這是經(jīng)過證實(shí)的成功率比較高的一種方式。

 在前期需求調(diào)研和需求分析都做好了之后，就可以做概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)了，我認(rèn)為這部分很關(guān)鍵的一點(diǎn)是確定界面風(fēng)格和關(guān)于代碼復(fù)用的考慮。一個(gè)符合客戶習(xí)慣的界面是最保險(xiǎn)的方案，這里面包括客戶的操作習(xí)慣和審美習(xí)慣。但對(duì)開發(fā)人員更需要注意的是代碼復(fù)用，一個(gè)好的代碼應(yīng)該是注釋詳細(xì)、代碼可讀性強(qiáng)、代碼復(fù)用率高的集合。而要做到代碼的高復(fù)用率需要高度的抽象能力和對(duì)類的粒度的劃分，對(duì)于粒度的劃分應(yīng)該遵循很多教材上多次提到的“高內(nèi)聚，低耦合”，也就是說一個(gè)函數(shù)或方法的功能越單一越容易被組合起來復(fù)用，和其他的方法或函數(shù)或其他類的關(guān)聯(lián)越少越好，這樣在與之關(guān)聯(lián)的對(duì)象或方法改變后不需要改動(dòng)或很少改動(dòng)就可以被復(fù)用。

另外“設(shè)計(jì)模式”也是很重要的，“設(shè)計(jì)模式”為開發(fā)人員提供了一系列其他人經(jīng)過多次試驗(yàn)證實(shí)成功的可以放心使用的解決套路，能夠按照“設(shè)計(jì)模式”的思路開發(fā)系統(tǒng)可以獲得很好的擴(kuò)展性和強(qiáng)壯性，這也是經(jīng)過無數(shù)案例證明過的。舉個(gè)簡(jiǎn)單的例子，如果將獲得數(shù)據(jù)的部分和顯示數(shù)據(jù)的代碼混在一起，如果將來在改動(dòng)顯示部分或改動(dòng)獲得數(shù)據(jù)部分則要到混在一起的代碼中去挑自己要改動(dòng)的部分，這可能造成不該動(dòng)的代碼被改動(dòng)了，或者因?yàn)橐徊糠指膭?dòng)了，另一部分必須被改動(dòng)，這樣也帶入了被迫改動(dòng)代碼的正確性的問題。對(duì)于這樣的改動(dòng)需要在測(cè)試時(shí)增大測(cè)試力度，才能保證代碼是正確的，當(dāng)然這是以增大測(cè)試成本為代價(jià)的。用另一種方式，使用設(shè)計(jì)模式，遵循MVC模式，將獲得數(shù)據(jù)部分作為C（控制部分）封裝在一個(gè)函數(shù)里，將顯示部分作為V（視圖）封裝在另一個(gè)部分，他們之間的數(shù)據(jù)傳遞用函數(shù)的參數(shù)或其他數(shù)據(jù)結(jié)構(gòu)（如記錄、集合等），這樣就可以保證改動(dòng)一部分不會(huì)影響另一部分的正確性，測(cè)試時(shí)只要針對(duì)改動(dòng)的部分測(cè)試就可以了，不會(huì)因?yàn)椴恢朗悄遣糠殖霈F(xiàn)的錯(cuò)誤而做更多的測(cè)試用例來確定錯(cuò)誤來源。

軟件維護(hù)也是個(gè)重要的階段，軟件在運(yùn)行一階段后，可能會(huì)發(fā)現(xiàn)一些測(cè)試時(shí)沒測(cè)出的錯(cuò)誤，也可能客戶覺得有些地方改變一下會(huì)為他們的工作提供更多的方便，這是就需要軟件維護(hù)。這時(shí)需要的開發(fā)人員不會(huì)很多，但這時(shí)維護(hù)人員可能不是原來的開發(fā)人員，這是就設(shè)計(jì)到了代碼的可讀性和可維護(hù)性。良好的代碼應(yīng)該有詳盡的注釋，當(dāng)然最好還要有簡(jiǎn)單明了的文檔。維護(hù)后應(yīng)該有維護(hù)記錄，要說明維護(hù)原因，變更部分的說明。如果在維護(hù)階段不知道原來的代碼的意義，則維護(hù)工作根本無處著手。我在維護(hù)南昌市民卡項(xiàng)目過程中遇到這樣一件事，因?yàn)槟喜矫婕敝僮鲉T卡，而這邊制卡程序需要改動(dòng)，但這邊什么文檔都沒有，程序沒有業(yè)務(wù)方面的注釋，根本看不出什么意思，只好重做。如果當(dāng)時(shí)有一份良好的注釋，可能重新開工的可能就機(jī)會(huì)沒有了。

另外功能齊全的公用單元有利于減少開發(fā)重新編寫的代碼量，可以節(jié)省開發(fā)時(shí)間，增強(qiáng)代碼的復(fù)用性。這在多個(gè)項(xiàng)目中可以看到好處，能夠非常迅速的就搭建起了系統(tǒng)框架，對(duì)于一些功能需要的技術(shù)實(shí)現(xiàn)已經(jīng)在公用單元提供了，所以可以拿過來直接使用。

如何組織軟件開發(fā)過程中的每一個(gè)步驟，就是軟件開發(fā)周期模型要解決的問題。我認(rèn)為開發(fā)軟件，其實(shí)就像是解決一個(gè)邏輯問題。想想自己平時(shí)是怎樣寫程序的。首先是要有一個(gè)想法，即我寫的這個(gè)程序是要干什么的；然后就是對(duì)要實(shí)現(xiàn)的核心功能大概構(gòu)思一種或多種實(shí)現(xiàn)方法，并從中選出一種自認(rèn)為是較好的；接下來就是將涉及的各種主要或次要功能分成各個(gè)模塊；最后就是分模塊來編碼和差錯(cuò)。在我看來，除了第一步外，其余的步驟應(yīng)該是一個(gè)循環(huán)的過程。在編碼的過程中，你總是需要不斷地回過頭來修改原先的模塊設(shè)計(jì)，甚至最初選定的實(shí)現(xiàn)算法。除非你是先知，否則，對(duì)于一個(gè)具有一定規(guī)模和復(fù)雜度的軟件來說，在“設(shè)計(jì)—編碼”這個(gè)過程中，實(shí)在有太多的不可預(yù)知性和變化性，你根本不可能全盤地把握住每一個(gè)細(xì)節(jié)。那么，對(duì)其每一個(gè)步驟的組織，即周期模型，就必須包容它的這種性質(zhì)?，F(xiàn)在來看一下瀑布模型。瀑布模型是一種線性模型，其最大的特點(diǎn)就是簡(jiǎn)單直觀。它將軟件開發(fā)過程規(guī)劃為“分析—設(shè)計(jì)—編碼—測(cè)試—維護(hù)”的線性過程，也就是說，你必須首先把你的軟件要干的每一件工作都分析得徹徹底底，再對(duì)每一個(gè)模塊，每一個(gè)接口，事無巨細(xì)，都設(shè)計(jì)得非常完美，然后才開始編碼的工作，并且在編碼的時(shí)候就像在對(duì)著圖紙砌模型，根本不用再回頭作任何修改，當(dāng)然，是在把所有的代碼都寫完以后才開始測(cè)試的。  

軟件開發(fā)過程的實(shí)現(xiàn)具體到每一步的工作要怎樣完成，我前面已提到過，是非常靈活的，只要把握住大體的方向就行。在進(jìn)行分析，設(shè)計(jì)，編碼，調(diào)試，維護(hù)這幾部分的工作的時(shí)候，最核心的就是文檔的編寫。文檔的作用在于以下3個(gè)方面：一是可以幫助整理思路。把要完成的目標(biāo)，系統(tǒng)的結(jié)構(gòu)，每一個(gè)模塊的功能等整理一下，然后分門別類地寫下來，這樣在開發(fā)的過程中，就有據(jù)可依，在需要回過頭來修改設(shè)計(jì)的時(shí)候，也有證可考。二是便于交流。在腦子里的東西一多，就會(huì)散而且亂，用語(yǔ)言表達(dá)的時(shí)候，很容易會(huì)丟三落四，別人也很難把握住你的思想。但經(jīng)過整理寫在紙上以后，則會(huì)清晰得多，無論是別人還是自己，看起來都可以一目了然。三是可以作為以后維護(hù)時(shí)的參考資料。有一句名言：“筆和紙永遠(yuǎn)都比大腦可靠”，意思就是說，放在大腦里的東西說不準(zhǔn)哪天就忘了，但寫在紙上的東西，只要不發(fā)生什么意外，一般是丟不了的。當(dāng)過了一段時(shí)間，你需要再回過頭來修改你的程序的時(shí)候，你就會(huì)發(fā)現(xiàn)，你以前寫下的文檔實(shí)在太有價(jià)值了。別指望你的源代碼，對(duì)于復(fù)雜一點(diǎn)的程序來說，單純的源代碼幾乎會(huì)扼殺掉你所有的時(shí)間?？尚行苑治鼍褪顷P(guān)于當(dāng)前項(xiàng)目能不能干的分析結(jié)果。主要考慮的方面包括：是否能把這個(gè)項(xiàng)目開發(fā)出來；假如可以的話，預(yù)計(jì)需要多少時(shí)間，能否滿足客人的時(shí)間要求；需要多少人力和資金的投入；最重要的是，這個(gè)項(xiàng)目能否賺錢，能賺多少。還要對(duì)可能存在的風(fēng)險(xiǎn)進(jìn)行評(píng)估。項(xiàng)目描述這是在決定立項(xiàng)以后，對(duì)當(dāng)前項(xiàng)目的一份扼要說明。必須包括以下幾個(gè)方面：（1）項(xiàng)目的名稱或編號(hào)；（2）對(duì)客戶方的描述；（3）對(duì)開發(fā)人員的描述；（4）工程任務(wù)的描述；（5）工程的輸入和輸出；（6）開發(fā)環(huán)境；（7）其他的附加條件。

通過對(duì)《實(shí)用軟件工程》和一些資料的學(xué)習(xí)，受益匪淺，對(duì)軟件開發(fā)有了一個(gè)系統(tǒng)的了解，對(duì)一些概念有了一定了解，雖都這些是些理論，可能在實(shí)際工作中很少用到，理論知識(shí)用于指導(dǎo)實(shí)踐，親身體驗(yàn)才能領(lǐng)悟軟件工程的妙用。我感覺到學(xué)習(xí)這門課需花費(fèi)大量的時(shí)間思考，從而換取了寶貴的經(jīng)驗(yàn)。學(xué)習(xí)軟件工程的過程是枯燥的，但我認(rèn)為若把這些枯燥的理論學(xué)好，在將來的學(xué)習(xí)和工作中一定會(huì)有益。