高質(zhì)量軟件開發(fā)

第1章高質(zhì)量軟件開發(fā)之道1.1軟件質(zhì)量基本概念 錯誤！未定義書簽。1.1.1如何理解軟件的質(zhì)量 錯誤！未定義書簽。1.2.2提高軟件質(zhì)量的基本方法 錯誤！未定義書簽。1.2.3“零缺陷”理念 11.2細(xì)說軟件質(zhì)量屬性 錯誤！未定義書簽。1.2.1正確性 錯誤！未定義書簽。1.2.2健壯性 錯誤！未定義書簽。1.2.3可靠性 錯誤！未定義書簽。1.2.4性能 錯誤！未定義書簽。1.2.5易用性 錯誤！未定義書簽。1.2.6清晰性 錯誤！未定義書簽。1.2.7安全性 錯誤！未定義書簽。1.2.8可擴(kuò)展性 錯誤！未定義書簽。1.2.9兼容性 錯誤！未定義書簽。1.2.10可移植性 錯誤！未定義書簽。TOC\o"1-5"\h\z\o"CurrentDocument"1.3人們關(guān)注的不僅是質(zhì)量 1\o"CurrentDocument"1.3.1質(zhì)量、生產(chǎn)率和成本之間的關(guān)系 21.3.2軟件過程改進(jìn)基本概念 錯誤！未定義書簽。\o"CurrentDocument"1.4高質(zhì)量軟件開發(fā)的基本方法 3\o"CurrentDocument"1.4.1建立軟件過程規(guī)范 3\o"CurrentDocument"1.4.2復(fù)用 6\o"CurrentDocument"1.4.3分而治之 71.4.4優(yōu)化與折衷 錯誤！未定義書簽。1.4.5技術(shù)評審 錯誤！未定義書簽。1.4.6測試 錯誤！未定義書簽。\o"CurrentDocument"1.4.7質(zhì)量保證 8\o"CurrentDocument"1.4.8改錯 9\o"CurrentDocument"1.6關(guān)于軟件開發(fā)的一些常識和思考 11\o"CurrentDocument"1.6.1有最好的編程語言嗎 11\o"CurrentDocument"1.6.2編程是一門藝術(shù)嗎 11\o"CurrentDocument"1.6.3編程時應(yīng)該多使用技巧嗎 11\o"CurrentDocument"1.6.4換更快的計算機(jī)還是換更快的算法 12\o"CurrentDocument"1.6.5錯誤是否應(yīng)該分等級 12\o"CurrentDocument"1.6.6一些錯誤的觀念 12第1章高質(zhì)量軟件開發(fā)之道本章講述高質(zhì)量軟件開發(fā)的道理。為了深入理解軟件質(zhì)量的概念，本章闡述了十個重要的軟件質(zhì)量因素，即正確性、健壯性、可靠性、性能、易用性、清晰性、安全性、可擴(kuò)展性、兼容性和可移植性。并介紹了消除軟件缺陷的基本方法。人們開發(fā)軟件產(chǎn)品的目的是賺錢。為了獲得更多的利潤，人們希望軟件開發(fā)工作“做得好、做得快并且少花錢”，所以軟件質(zhì)量并不是人們唯一關(guān)心的東西。本章論述了“質(zhì)量、生產(chǎn)率、成本”之間的關(guān)系，并給出了能夠“提高質(zhì)量、提高生產(chǎn)率并且降低成本”的軟件開發(fā)方法。1.2.3“零缺陷”理念質(zhì)量的最高境界是什么？是盡善盡美，即“零缺陷”?！傲闳毕荨崩砟顏碓从趪H上一些著名的硬件廠商。盡管軟件的開發(fā)與硬件生產(chǎn)有很大的區(qū)別，但我們?nèi)钥梢越梃b，從中得到啟迪。人在做一件事情時，由于存在很多不確定的因素，一般不可能100%地達(dá)到目標(biāo)。假設(shè)平常人做事能完成目標(biāo)的80%。如果某個人的目標(biāo)是100分，那么他最終成績可達(dá)80分；如果某個人的目標(biāo)只是60分，那么他最終成績只有48分。我們在考場上身經(jīng)百戰(zhàn)，很清楚那些只想混及格的學(xué)生通常都不會及格。即使學(xué)習(xí)好的學(xué)生也常有失誤，因而捶胸頓足。做一個項目通常需要多個人的協(xié)作。假設(shè)某系統(tǒng)的總質(zhì)量是十個開發(fā)人員的工作質(zhì)量之積，記最高值為1.0，最低值為0。如果每個人的質(zhì)量目標(biāo)是0.95，那么十個人的累積質(zhì)量不會超過0.598。如果每個人的質(zhì)量目標(biāo)是0.9，那么十個人的累積質(zhì)量不會超過0.35。只有每個人都做到1.0，系統(tǒng)總質(zhì)量才會是1.0。只要其中一人的工作質(zhì)量是0，那么系統(tǒng)總質(zhì)量也成了0。因系統(tǒng)之中的一個缺陷而導(dǎo)致機(jī)毀人亡的事件已不罕見。上述比喻雖然嚴(yán)厲了一些，但從嚴(yán)要求只有好處沒有壞處。如果不嚴(yán)以律已，人的墮落就很快。如果沒有“零缺陷”的質(zhì)量理念，也許缺陷就會成堆。從理念到行動還是有一定距離的，企業(yè)在開發(fā)產(chǎn)品時應(yīng)當(dāng)根據(jù)自身實力和用戶的期望值來設(shè)定可以實現(xiàn)的質(zhì)量目標(biāo)。過低的質(zhì)量目標(biāo)會毀壞企業(yè)的聲譽(yù)，而過高的質(zhì)量目標(biāo)也有可能導(dǎo)致成本過高而拖累企業(yè)（請參見本章1.3節(jié)）。1.3人們關(guān)注的不僅是質(zhì)量企業(yè)開發(fā)產(chǎn)品的目的是賺錢，為了使利潤極大化，人們希望軟件開發(fā)工作“做得好、做得快并且少花錢”。用軟件工程的術(shù)語來講，即“提高質(zhì)量、提高生產(chǎn)率并且降低成本”。古代哲學(xué)家曾為“魚和熊掌不可得兼”的問題費(fèi)盡心思，我們現(xiàn)在卻夢想魚、熊掌、美酒三者兼得，現(xiàn)代人的欲望真是無止境啊。讓我們先談?wù)勝|(zhì)量、生產(chǎn)率和成本之間的關(guān)系。1.3.1質(zhì)量、生產(chǎn)率和成本之間的關(guān)系質(zhì)量無疑是客戶最關(guān)心的問題?？蛻艏词共粓D物美價廉，也要求貨真價實。軟件開發(fā)商必須滿足客戶對質(zhì)量的要求（不論是寫在合同上的還是約定俗成的），否則做不成買賣?，F(xiàn)在就連做盜版光盤生意的人也講究質(zhì)量，如果盤片不好，是可以退貨的。高質(zhì)量既是軟件開發(fā)人員的技術(shù)追求，又是職業(yè)道德的要求。在關(guān)注質(zhì)量的同時，軟件開發(fā)商又期望生產(chǎn)率能高些并且成本能低些。老板和員工們誰不想用更少的時間賺更多的錢！質(zhì)量與生產(chǎn)率之間存在相輔相成的關(guān)系。高生產(chǎn)率必須以質(zhì)量合格為前提。如果質(zhì)量不合格，軟件產(chǎn)品要么賣不出去，要么賣出去了再賠償客戶的損失。這種情況下“高生產(chǎn)率”變得毫無意義。別看開發(fā)商和客戶雙方的代表能在餐桌上談笑風(fēng)生，一旦出了質(zhì)量問題，那就不會很親熱了。從短期效益看，追求高質(zhì)量可能會延長軟件開發(fā)時間，一定程度上降低了生產(chǎn)率。從長期效益看，追求高質(zhì)量將使軟件開發(fā)過程更加成熟和規(guī)范化。日積月累，當(dāng)開發(fā)過程成熟到一定地步后，必將大大降低軟件的測試和改錯的代價，縮短產(chǎn)品的開發(fā)周期，實質(zhì)上是提高了生產(chǎn)率，同時又獲得了很好的信譽(yù)。所以質(zhì)量與生產(chǎn)率之間不存在根本的對立。提高質(zhì)量與生產(chǎn)率需要一個過程，企業(yè)不可操之過切。一般地，軟件過程能力比較低的企業(yè)（例如低于CMM2級），應(yīng)該將質(zhì)量放在第一位，生產(chǎn)率放在第二位。只有這樣才可能持久地提高質(zhì)量與生產(chǎn)率。（“能力成熟度模型CMM”將在后面解釋）如果一個企業(yè)的軟件過程能力低于CMM2級，表明其開發(fā)能力與管理能力還很薄弱。就其目前的實力而言，無論下多大的決心去做，都不可能一開始就把質(zhì)量與生產(chǎn)率改善得一樣好。并不是我們刻意貶低生產(chǎn)率的“地位”，是公司的現(xiàn)實情況要求在質(zhì)量與生產(chǎn)率之間分個“輕重緩急”。由于人們天生就有“急功近利”的傾向，如果公司領(lǐng)導(dǎo)人認(rèn)可“生產(chǎn)率第一、質(zhì)量第二”，那么員工們做著做著必定會回到混亂的局面。這樣的教訓(xùn)實在是太多了！老話說得好：磨刀不誤砍柴功。用它類比上述理念最合適不過了。俗話說“一分價錢一分貨”，人們買東西的時候大多認(rèn)可“質(zhì)量越好價格就越高”。除了壟斷性的產(chǎn)品外，一般來說成本是影響價格的主要因素。對于軟件開發(fā)而言，質(zhì)量與成本之間有什么關(guān)系？高質(zhì)量必然會導(dǎo)致高成本嗎？經(jīng)驗表明，如果軟件的“高質(zhì)量”是“修補(bǔ)”出來的，毫無疑問會導(dǎo)致低生產(chǎn)率和高成本。如果能研制出某些好方法，將高質(zhì)量與高生產(chǎn)率內(nèi)建于開發(fā)過程之中，那么就能自然地能降低開發(fā)成本，這是軟件過程改進(jìn)的目標(biāo)。要提醒大家的是，大公司與小公司對成本的關(guān)注程度是不盡相似的。首先談一下“市場價”（MarketingPrice）與“成本價”（CostPrice）的概念。在某個領(lǐng)域，當(dāng)市場上只出現(xiàn)尚未形成競爭格局的一個或幾個產(chǎn)品時，產(chǎn)品價格基本上是由廠商自己制定，稱為“市場價”。由于缺乏競爭，無論成本多高，總能獲得高額利潤。電影《大腕》里那個搞房地產(chǎn)的精神病人說“不求最好，但求最貴”，真是實話實說。當(dāng)產(chǎn)品之間形成競爭時，就會出現(xiàn)“殺價”現(xiàn)象。由于各家產(chǎn)品的功能、質(zhì)量旗鼓相當(dāng)，競爭實質(zhì)上是在拼成本。誰的成本低，誰就有利可圖。這時的產(chǎn)品價格叫做“成本價”。中國的彩電業(yè)是一個活生生的例子。若干年前彩電價格極高，彩電遠(yuǎn)離百姓人家，一部分人即使買得起也買不到。如今連超市里都充斥著各種品牌的彩電，價格戰(zhàn)打得嗚呼哀哉，把廠商逼到“微利”的地步。現(xiàn)在工薪階層人士很少有買不起彩電的。商場里TOTO品牌的馬桶價格為2000?3000元，比同體積的國產(chǎn)純平彩電還貴，并且利潤高得多。唉，我們坐在這樣的馬桶上真的要為民族工業(yè)憂心忡忡哪。由于“市場價”與“成本價”的差價十分懸殊，IT行業(yè)的大公司都想吃“市場價”這塊肥肉。大公司的資金雄厚，銷售力量強(qiáng)，只要能搶先推出產(chǎn)品，就不愁賣不出去。怎樣才能達(dá)到目的呢？通常有兩種方式。一種方式是從別處購買快要成形的產(chǎn)品，改頭換面，貼上大公司的標(biāo)簽就可以上市銷售。所以IT行業(yè)的“公司收購”特別盛行。如果Cisco公司的網(wǎng)絡(luò)產(chǎn)品全部讓原班人馬來開發(fā)，它很難能夠那么快就發(fā)展成為網(wǎng)絡(luò)業(yè)的霸主！另一種方式是自行開發(fā)新產(chǎn)品，讓公司的研發(fā)隊伍加班加點地干活。這么辛苦是值得的，產(chǎn)品成功會讓員工們有很大的成就感。無論通過哪種方式搶先推出產(chǎn)品，前提條件都要求產(chǎn)品的質(zhì)量合格。如果產(chǎn)品因質(zhì)量不合格而被市場拒絕，那么損失的不僅僅是成本，更慘重的是失去機(jī)會和信譽(yù)。象Intel這樣了不起的公司也會吃敗仗。每當(dāng)Intel公司的CPU芯片出現(xiàn)缺陷時，就會罵聲一片。Intel公司不得不大量回收芯片并向用戶道歉，此時競爭對手如AMD公司就會乘虛而入，搶走象IBM、Compaq這些大客戶的部分定單。在信息高度發(fā)達(dá)的社會里，你能想得到的產(chǎn)品別人也能想得到。只有少數(shù)大公司能夠享受到“市場價”的利益，但是好景不會太長。大多數(shù)公司在大部分時間里開發(fā)的是“成本價”的產(chǎn)品。所以樹立“降低開發(fā)成本”的理念仍然十分重要。1.4高質(zhì)量軟件開發(fā)的基本方法1.4.1建立軟件過程規(guī)范人們意識到，若想順利開發(fā)出高質(zhì)量的軟件產(chǎn)品，必須有條理地組織技術(shù)開發(fā)活動和項目管理活動。我們把這些活動的組織形式稱為過程模型。軟件企業(yè)應(yīng)當(dāng)根據(jù)產(chǎn)品的特征，建立一整套在企業(yè)范圍內(nèi)通用的軟件過程模型及規(guī)范，并形成制度。這樣開發(fā)人員與管理人員就可以依照過程規(guī)范有條不紊地開展工作。我們曾與國內(nèi)很多研發(fā)人員和各級經(jīng)理交流過，大家都對軟件開發(fā)的混亂局面表示了不滿和無奈。盡管“土匪游擊隊”的開發(fā)模式到處可見，但是沒有人真的喜歡混亂?！耙?guī)范化”是區(qū)別“正規(guī)軍”和“土匪游擊隊”的根本標(biāo)志。大家無不渴望以規(guī)范化的方式開發(fā)產(chǎn)品。這是現(xiàn)狀、是需求、也是希望。對軟件開發(fā)模型的研究興起于60年代末70年代初，典型成果是1970年提出的瀑布模型。人們研制了很多的軟件開發(fā)模型，常見的有“瀑布模型”、“噴泉模型”、“增量模型”，“快速原型模型”、“螺旋模型”、“迭代模型”等。這么多軟件開發(fā)模型，企業(yè)應(yīng)該如何選擇并應(yīng)用呢？企業(yè)在選擇軟件開發(fā)模型時，不要太在乎學(xué)術(shù)上的“先進(jìn)”與“落后”，正如有才華的人并不一定要出自名牌大學(xué)或擁有高學(xué)歷那樣。關(guān)鍵是看該模型能否有效地幫助企業(yè)順利地開發(fā)出軟件產(chǎn)品，并且要考慮員工們使用起來是否方便。簡而言之，就是考察模型是否“實用、好用”。最早出現(xiàn)的軟件開發(fā)模型是瀑布模型。它太理想化、太單純，看起來已經(jīng)落后于現(xiàn)代的軟件開發(fā)模式。如今瀑布模型幾乎被學(xué)術(shù)界拋棄，偶而被人提起，都屬于被貶對象，未被留一絲惋惜。說它如何如何地差，為的是說明新模型是怎樣怎樣地好。然而企業(yè)界不同于學(xué)術(shù)界，我認(rèn)為瀑布模型對企業(yè)太有價值了，我要為它聲辯，恢復(fù)它應(yīng)有的名譽(yù)。瀑布模型的精髓是“線性順序”地開發(fā)軟件。我們應(yīng)該認(rèn)識到“線性化”是人們最容易掌握并能熟練應(yīng)用的思想方法。當(dāng)人們碰到一個復(fù)雜的“非線性”問題時，總是千方百計地將其分解或轉(zhuǎn)化為一系列簡單的線性問題，然后逐個解決。一個軟件系統(tǒng)的整體可能是復(fù)雜的，而細(xì)分后的子程序總是簡單的，可以用“線性化”的方式來實現(xiàn)，否則干活就太累了。讓我們引用AlbertEinstein的話作為信條——“任何事物都應(yīng)該盡可能地簡潔”?！熬€性”是一種簡潔，簡潔就是美。當(dāng)我們領(lǐng)會了“線性”的精神，就不要再呆板地套用“線性”的外表，而應(yīng)該用活它。例如增量模型實質(zhì)就是分段的線性模型。螺旋模型則是迭代的彎曲了的線性模型。在其它模型中大都能夠找到“線性”的影子。瀑布模型是如此的簡潔，所有的軟件開發(fā)人員天生就能學(xué)會（如果學(xué)不會，那他就別干軟件這一行了）。所以瀑布模型特別適合于企業(yè)，請大家別輕易貶低它。軟件開發(fā)模型只關(guān)注技術(shù)開發(fā)活動，并不考慮項目管理，這對開發(fā)產(chǎn)品而言是不夠的，所以開發(fā)模型只是軟件過程模型的一部分。奇怪的是，我迄今為止尚未找到論述軟件過程模型的軟件工程書籍。我就自己創(chuàng)作了一個基于CMMI3級的軟件過程模型，稱為“精簡并行過程”（SimplifiedParallelProcess,SPP）。SPP模型如圖1-2所示?！熬啿⑿羞^程”的含義是：（1）對CMMI3級以內(nèi)的關(guān)鍵過程域以及關(guān)鍵實踐作了“精簡”處理；（2）項目管理過程、技術(shù)開發(fā)過程和支撐過程“并行”開展。

PH0: PH1產(chǎn)品概念：產(chǎn)品定義PH2產(chǎn)品開發(fā)產(chǎn)品驗證PH3產(chǎn)品生命周期PH4: PH5用戶驗收：產(chǎn)品維護(hù)：i h: !項目管理過程立項管理、::管理所有的技術(shù)，:PH0: PH1產(chǎn)品概念：產(chǎn)品定義PH2產(chǎn)品開發(fā)產(chǎn)品驗證PH3產(chǎn)品生命周期PH4: PH5用戶驗收：產(chǎn)品維護(hù)：i h: !項目管理過程立項管理、::管理所有的技術(shù)，:開發(fā)活動 11:rt結(jié)項管理需求開發(fā)項目計劃項目監(jiān)控 風(fēng)險管理 需求管理 外包管理技術(shù)預(yù)研、迭代系統(tǒng)設(shè)計術(shù)評審實現(xiàn)與測試根據(jù)產(chǎn)品特征確定最合適的開發(fā)模型,系統(tǒng)測試用戶驗收如瀑布模型、迭代模型等。系統(tǒng)測試用戶驗收軟件維護(hù)支撐所有的技術(shù)開發(fā)活動］支撐過程 配置F ?&管理 質(zhì)量保證 采購管理 培訓(xùn)管理圖1-2精簡并行過程(SPP)模型SPP模型把產(chǎn)品生命周期劃分為6個階段?產(chǎn)品概念階段，記為PH0。?產(chǎn)品定義階段，記為PH1。產(chǎn)品開發(fā)階段，記為PH2。產(chǎn)品驗證階段，記為PH3。用戶驗收階段，記為PH4。產(chǎn)品維護(hù)階段，記為PH5。在SPP模型中，一個項目從PH0到PH5共經(jīng)歷19個關(guān)鍵過程域(KeyProcessArea,KPA),它們被劃分為三大類過程，如表1-2所示。其中項目管理過程含7個關(guān)鍵過程域,技術(shù)開發(fā)過程含8個過程域，支撐過程含4個過程域。過程類別? 項目管理過程? 技術(shù)開發(fā)過程? 支撐過程? 立項管理?需求開發(fā)? 配置管理?結(jié)項管理?技術(shù)預(yù)研? 質(zhì)量保證關(guān)鍵過程域?項目計劃?系統(tǒng)設(shè)計?采購管理?項目監(jiān)控? 實現(xiàn)與測試?培訓(xùn)管理? 風(fēng)險管理?系統(tǒng)測試? 外包管理?用戶驗收? 需求管理?軟件維護(hù)?技術(shù)評審表1-2SPP過程域分類SPP模型的主要優(yōu)點有：（1）模型直觀。SPP模型是三層結(jié)構(gòu)，上層是項目管理過程的集合，中層是技術(shù)開發(fā)過程的集合，下層是支撐過程的集合。這種模型很直觀，高級經(jīng)理、項目經(jīng)理、開發(fā)人員、質(zhì)量保證員等人根據(jù)SPP模型很容易知道自己“應(yīng)該在什么時候做什么事情，以及按照什么規(guī)范去做事情”。SPP模型有助于使各個過程的活動有條不紊地開展。（2）方便于用戶裁剪SPP模型。項目管理過程和支撐過程對絕大多數(shù)軟件產(chǎn)品開發(fā)而言都是適用的。需求開發(fā)、技術(shù)預(yù)研、系統(tǒng)設(shè)計、編程、測試、技術(shù)評審、維護(hù)都是技術(shù)開發(fā)過程中必不可少的環(huán)節(jié)，用戶可以根據(jù)產(chǎn)品的特征確定最合適的開發(fā)模型（例如瀑布模型、快速原型模型、迭代模型等）。（3）方便于用戶擴(kuò)充SPP模型。如果產(chǎn)品同時涉及軟件硬件開發(fā)的話，可將產(chǎn)品生命周期、軟件開發(fā)過程和硬件開發(fā)過程集成一起。1.4.2復(fù)用復(fù)用就是指“利用現(xiàn)成的東西”，文人稱之為“拿來主義”。被復(fù)用的對象可以是有形的物體，也可以是無形的知識成果。復(fù)用不是人類懶惰的表現(xiàn)而是智慧的表現(xiàn)。因為人類總是在繼承了前人的成果，不斷加以利用、改進(jìn)或創(chuàng)新后才會進(jìn)步。所以每當(dāng)我們歡度國慶時，要清楚祖國遠(yuǎn)不止50來歲，我們今天享用到的財富還有歷史上幾千年中國人民的貢獻(xiàn)。進(jìn)步只是應(yīng)該的，沒有進(jìn)步則就可恥了。復(fù)用的有利于提高質(zhì)量、提高生產(chǎn)率和降低成本。由經(jīng)驗可知，通常在一個新系統(tǒng)中，大部分的內(nèi)容是成熟的，只有小部分內(nèi)容是創(chuàng)新的。一般地可以相信成熟的東西總是比較可靠的（即具有高質(zhì)量），而大量成熟的工作可以通過復(fù)用來快速實現(xiàn)（即具有高生產(chǎn)率）。勤勞并且聰明的人們應(yīng)該把大部分的時間用在小比例的創(chuàng)新工作上，而把小部分的時間用在大比例的成熟工作中，這樣才能把工作做得又快又好。把復(fù)用的思想用于軟件開發(fā)，稱為軟件復(fù)用。技術(shù)開發(fā)活動與管理活動中的任何成果都可以被復(fù)用，如思想方法、經(jīng)驗、程序、文檔等等。據(jù)統(tǒng)計，世上已有1000億多行程序，無數(shù)功能被重寫了成千上萬次，真是浪費(fèi)哪。面向?qū)ο螅∣bjectOriented）學(xué)者的口頭禪就是“請不要再發(fā)明相同的車輪子了”。將具有一定集成度并可以重復(fù)使用的軟件組成單元稱為軟構(gòu)件（SoftwareComponent）。軟件復(fù)用可以表述為：構(gòu)造新的軟件系統(tǒng)可以不必每次從零做起，直接使用已有的軟構(gòu)件，即可組裝或加以合理修改后成為新的系統(tǒng)。復(fù)用方法合理化并簡化了軟件開發(fā)過程，減少了總的開發(fā)工作量與維護(hù)代價，既降低了軟件的成本又提高了生產(chǎn)率。另一方面，由于軟構(gòu)件是經(jīng)過反復(fù)使用驗證的，自身具有較高的質(zhì)量。因此由軟構(gòu)件組成的新系統(tǒng)也具有較高的質(zhì)量。軟件復(fù)用不僅要使自己拿來方便，還要讓別人拿去方便，是“拿來拿去主義”。這想法挺好，但現(xiàn)實中執(zhí)行得并不如意。企業(yè)的業(yè)務(wù)各色各樣，誰也不能坐等著天上掉下可以被大規(guī)模復(fù)用的東西，一般要靠“日積月累”才能建設(shè)可以被復(fù)用的軟件庫。從理論上講這項工作沒有不可逾越的技術(shù)障礙。真正的障礙是它“耗時費(fèi)錢”，前期投入較多，缺乏近期效益。大部分的公司都注重近期效益，不是它天生目光短淺，而是為了生存必須這么做。有些處境艱難的公司下一頓飯還不知道在何處著落，更別提軟件復(fù)用這樣的“長久之計”了。所以軟件復(fù)用對大多數(shù)公司來說不是“最高優(yōu)先級”。我到公司工作的最初安排是從事電信領(lǐng)域“可復(fù)用軟件工廠”的開發(fā)。領(lǐng)導(dǎo)在招聘時跟我講，這個想法已經(jīng)有數(shù)年了，一直沒有落實，希望我能做好。待我正式上班時，馬上就改成做其它短期的研發(fā)項目了。要知道我所在的公司人力與財力相當(dāng)充足，非國內(nèi)普通中小型IT企業(yè)所能比。即便我們有如此好的條件，軟件復(fù)用也只是掛在嘴上，沒有實際行動。所以我建議：隨時隨地盡可能地復(fù)用你所能復(fù)用的東西，不要等待公司下達(dá)復(fù)用的行政命令，因為你很難等到那一天，即使等到了也沒有多少意義。1.4.3分而治之分而治之是指把一個復(fù)雜的問題分解成若干個簡單的問題，然后逐個解決。這種樸素的思想來源于人們生活與工作的經(jīng)驗，完全適合于技術(shù)領(lǐng)域。分而治之說起來容易，做好卻難，最糟糕的現(xiàn)象是“分是分了”卻“治不了”。軟件的分而治之不可以“硬分硬治”。不像為了吃一個西瓜或是一只雞，揮刀斬成n塊，再把每塊塞進(jìn)嘴里粉碎攪拌，然后交由胃腸來消化吸收，象征復(fù)雜問題的西瓜或是雞也就此消失了。軟件的“分而治之”應(yīng)該著重考慮：復(fù)雜問題分解后，每個問題能否用程序?qū)崿F(xiàn)？所有程序最終能否集成為一個軟件系統(tǒng)并有效解決原始的復(fù)雜問題？圖1-3表示了軟件的“分而治之”策略。軟件的模塊化設(shè)計就是分而治之的具體表現(xiàn)。1.4.7質(zhì)量保證質(zhì)量保證(QualityAssurance,QA)的目的是提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量”，從而實現(xiàn)持續(xù)地改進(jìn)質(zhì)量。質(zhì)量保證是一種有計劃的、貫穿于整個產(chǎn)品生命周期的質(zhì)量管理方法。過程質(zhì)量與產(chǎn)品質(zhì)量存在某種因果關(guān)系，通?！昂玫倪^程”產(chǎn)生“好的產(chǎn)品”而“差的過程”將產(chǎn)生“差的產(chǎn)品”。人們銷售的是產(chǎn)品而不是過程，用戶關(guān)心的是最終產(chǎn)品的質(zhì)量，而軟件開發(fā)團(tuán)隊既要關(guān)心過程質(zhì)量又要關(guān)心產(chǎn)品質(zhì)量。質(zhì)量保證的基本方法是通過有計劃地檢查“工作過程以及工作成果”是否符合既定的規(guī)范，來監(jiān)控和改進(jìn)“過程質(zhì)量”與“產(chǎn)品質(zhì)量”。如果“工作過程以及工作成果”不符合既定的規(guī)范，那么產(chǎn)品的質(zhì)量肯定有問題?；谶@樣的推理，質(zhì)量保證人員即使不是技術(shù)專家，他也能夠客觀地檢查和監(jiān)控產(chǎn)品的質(zhì)量。這是質(zhì)量保證方法富有成效的一面。但是“工作過程以及工作成果”符合既定的規(guī)范卻并不意味著產(chǎn)品的質(zhì)量一定合格，因為僅靠規(guī)范無法識別出產(chǎn)品中可能存在的大量缺陷。這是質(zhì)量保證方法的不足之處。所以單獨(dú)的“質(zhì)量保證”其實并不能“保證質(zhì)量”。技術(shù)評審與測試關(guān)注的是產(chǎn)品質(zhì)量而不是過程質(zhì)量，兩者的技術(shù)強(qiáng)度比質(zhì)量保證要高得多。技術(shù)評審和測試能彌補(bǔ)質(zhì)量保證的不足，三者是相輔相成的質(zhì)量管理方法。我們在實踐中不能將質(zhì)量保證、技術(shù)評審和測試混為一談，也不能把三者孤立起來執(zhí)行。建議讓質(zhì)量保證人員參加并監(jiān)督重要的技術(shù)評審和測試工作，把三者有機(jī)地結(jié)合起來，可提高工作效率，降低成本。質(zhì)量保證小組(QualityAssuranceGroup,QAG)有如下特點：質(zhì)量保證小組在行政上獨(dú)立于任何項目。這種獨(dú)立性有助于質(zhì)量保證小組客觀地檢查和監(jiān)控產(chǎn)品的質(zhì)量。質(zhì)量保證小組有一定的權(quán)利，可以對質(zhì)量不合格的工作成果做出處理。這種權(quán)利使得質(zhì)量保證小組的工作不會被輕視，并有助于加強(qiáng)全員的質(zhì)量意識。需要強(qiáng)調(diào)的是，提高產(chǎn)品質(zhì)量是全員的職責(zé)，并非只是質(zhì)量保證小組的職責(zé)。質(zhì)量保證過程域的主要活動如圖1-5所示。圖1質(zhì)量保證過程域示意圖1.4.8改錯改錯是個大悲大喜的過程，一天之內(nèi)可以讓人在悲傷的低谷和喜悅的顛峰之間跌蕩起伏。如果改過了成千上萬個程序錯誤，那么少男少女們不必經(jīng)歷失戀的挫折也能變得成熟起來。我從大三開始真正接受改錯的磨練，已記不清楚多少次汗流浹背、濕透板凳。改不了錯誤時，恨不得撞墻。改了錯誤時，比女孩子朝我笑笑還開心。在做本科畢業(yè)設(shè)計時，一天夜里，一哥們流竄到我的實驗室，哈不攏嘴地對我嚷嚷：“你知道什么叫茅塞頓開嗎？”我象文盲似地?fù)u搖頭。他說：“今天我化了十幾個小時沒能干掉一個錯誤，剛才我去了廁所五分鐘，一切都解決了?！彼€用那沒洗過的手拉我，一定要請我吃“肉夾饃”。那得意勁兒仿佛同時談了兩個女朋友。軟件中的錯誤通常只有開發(fā)者自己才能找出并改掉。如果因畏懼而拖延，會讓你終日心情不定，食無味，睡不香。所以長痛不如短痛，要集中精力對付錯誤。東北有個林場工人，工作勤奮，一人能干幾個人的活。前三十年是伐樹勞模，受到周總理的接見。忽有一天醒悟過來，覺得自己太對不起森林，決心補(bǔ)救錯誤。后三十年成了植樹勞模，受到朱總理的接見。若能以此大勇來改錯，正是無往而不勝也。我們軟件開發(fā)人員應(yīng)當(dāng)向這位可敬的林場工人學(xué)習(xí)。改錯過程很像偵破案件，有些壞事發(fā)生了，而僅有的信息就是它的確發(fā)生了。我們必須從結(jié)果出發(fā)，逆向思考。改錯的第一步是找出錯誤的根源，如同醫(yī)生治病，必須先找出病因才能“對癥下藥”。有人問阿凡提：“我肚子痛，應(yīng)該用什么藥？”阿凡提說：“應(yīng)該用眼藥水，因為你眼睛不好，吃了臟東西才肚子痛?！备鶕?jù)軟件錯誤的癥狀推斷出根源并不是件容易的事，因為：（1）癥狀和根源可能相隔很遠(yuǎn)。也就是說，癥狀可能在某一個程序單元中出現(xiàn)，而根源實際上在很遠(yuǎn)的另一個地方。高度耦合的程序結(jié)構(gòu)加劇了這種情況。（2）癥狀可能在另一個錯誤被糾正后暫時性消失。（3）癥狀可能并不是由某個程序錯誤直接引發(fā)的，如誤差累積。（4）癥狀可能是由不太容易跟蹤的人工錯誤引起的。（5）癥狀可能時隱時現(xiàn)，如內(nèi)存泄漏。（6）很難重新產(chǎn)生完全一樣的輸入條件，難以恢復(fù)“錯誤的現(xiàn)場”。（7）癥狀可能分布在許多不同的任務(wù)中，難以跟蹤。改錯的最大忌諱是“急躁蠻干”。人們常說“急中生智”，我不信。我認(rèn)為大多數(shù)人著急了就會蠻干，早把“智”丟到腦后。不僅人如此，動物也如此。我們經(jīng)?？吹?，蜜蜂或者蒼蠅想從玻璃窗中飛出，它們會頂著玻璃折騰幾個小時，卻不曉得從旁邊輕輕松松地飛走。我原以為蜜蜂和蒼蠅長得太小，視野有限，以致看不見近在咫尺的逃生之窗，所以只好蠻干。可是有一天夜里，有只麻雀飛進(jìn)我的房間，它的逃生方式竟然與蜜蜂一模一樣。我用燈光照著那扇打開的窗戶為其引路，并向它打手勢，對它說話，均無濟(jì)于事。它是到天亮后才飛走的，這一宿我和它都沒有休息好。我們把尋找錯誤根源的過程稱為調(diào)試（Debugging）。調(diào)試的基本方法是“粗分細(xì)找”對于隱藏得很深的Bug，我們應(yīng)該運(yùn)用歸納、推理、“二分”等方法先“快速、粗略”地確定錯誤根源的范圍，然后再用調(diào)試工具仔細(xì)地跟蹤此范圍的源代碼。如果沒有調(diào)試工具，那么只好用“土辦法”：在程序中插入打印語句如printf（…）觀看屏幕的輸出。有些時候，世界上最好的調(diào)試工具恐怕是那些有經(jīng)驗的人。我們經(jīng)常會長時間地追蹤某個Bug，苦惱萬分。恰好有高手路過，被他一語“道破天機(jī)”。頓時沮喪的陰云就被驅(qū)散，你不得不說“I服了You”。修改代碼錯誤時的注意事項：找到錯誤時，不要急于修改，先思考一下：修改此代碼會不會引發(fā)其它問題？如果沒有問題，則可以放心修改。如果有問題，那么可能要改動程序結(jié)構(gòu)，而不止一行代碼。有些時候，軟件中可能潛伏同一類型的許多錯誤（例如由不良的編程習(xí)慣引起的）。好不容易逮住一個，應(yīng)當(dāng)乘勝追擊，全部殲滅。在改錯之后一定要馬上進(jìn)行回歸測試，以免引入新的錯誤。有人在馬路上撿到錢包后得意忘形，不料自己卻被汽車撞倒。改了一個程序錯誤固然是喜事，但要防止樂極生悲。更加嚴(yán)格的要求是：不論原有程序是否絕對正確，只要對此程序作過改動（哪怕是微不足道的），都要進(jìn)行回歸測試。上述事情做完后，應(yīng)當(dāng)好好反思：我為什么會犯這樣的錯誤？怎么能夠防止下次不犯相似的錯誤？最好能寫下心得體會，與他人共享經(jīng)驗教訓(xùn)。1.6關(guān)于軟件開發(fā)的一些常識和思考1.6.1有最好的編程語言嗎作者的觀點：程序員在最初學(xué)習(xí)Basic、Fortran、Pascal、C、C++等語言時會感覺一個比一個好，不免有喜新厭舊之舉。而如今的VisualBasic、Delphi、VisualC++、Java等語言各有所長，真的難分優(yōu)劣。能很好地解決問題的編程語言就是好語言。開發(fā)人員應(yīng)該根據(jù)實際情況，選擇業(yè)界推薦的并且是自己擅長的編程語言來開發(fā)軟件，才能保證有較好的質(zhì)量與生產(chǎn)率。編程是件自由與快樂的事情，不要發(fā)誓忠于某某語言而自尋煩惱。編程是一門藝術(shù)嗎作者的觀點：水平高到一定程度后，干啥事都能感受到“藝術(shù)”，編程也不例外。但在技術(shù)行業(yè)，人們通常認(rèn)為“藝術(shù)”是隨心所欲、不可把握的東西。如果程序員都把編程當(dāng)成“藝術(shù)”來看待，準(zhǔn)會把公司老板嚇昏過去。大部分人開發(fā)軟件是為了滿足客戶的需求，而不是為了自己享受。本書提倡規(guī)范化編程。規(guī)范化能夠提高質(zhì)量與生產(chǎn)率，最具實用價值，盡管它在一定程度上壓抑了“藝術(shù)”。編程藝術(shù)是人們對高水平程序創(chuàng)作的一種感受，但只可意會，不可言傳，不能成為軟件公司的一個指導(dǎo)方針。編程時應(yīng)該多使用技巧嗎作者的觀點：就軟件開發(fā)而言，技巧的優(yōu)點在于能另辟蹊徑地解決一些問題，缺點是技巧并不為人熟知。若在程序中使用太多的技巧，可能會留下錯誤隱患，別人也難以理解程序。鑒于一個局部的優(yōu)點對整個系統(tǒng)而言是微小的，而一個錯誤則可能對整個系統(tǒng)是致命的。我建議用自然的方式編程，不要濫用技巧。我們有時的確不知道自己的得意之舉究竟是錦上添花，還是畫蛇添足。就象蒸出一籠饅頭，在上面插一朵鮮花，本想弄點詩情畫意，卻讓人誤以為那是一堆熱氣騰騰的牛糞。小時候讀的《狼三則》故事啟示我們，失敗的技巧被諷刺為“技倆”。當(dāng)我們在編程時無法判斷是用了技巧還是用了技倆，那就少用?！顿u油翁》的故事又告訴我們“熟能生巧”，表明技巧是自然而然產(chǎn)生的，而不是賣弄出來的。賣油翁的絕技是可到中央電視臺表演的，而他老人家卻謙虛地說：“沒啥沒啥，用熟了而已”。1.6.4換更快的計算機(jī)還是換更快的算法如果軟件運(yùn)行較慢，是換一臺更快的計算機(jī)，還是設(shè)計一種更快的算法？作者的觀點：如果開發(fā)軟件的目的是為了學(xué)習(xí)或是研究，