軟件工程成功與否的決定因素的一些認(rèn)識(shí)

軟件工程成功與否的決定因素的一些認(rèn)識(shí)

以下工程開發(fā)指導(dǎo)是我對(duì)決定一項(xiàng)使用任何語言的軟件工程成功與否的決定因素的一些認(rèn)識(shí)。

1．記住往往事與愿違

純粹的“軼事工程”（原文為：anecdotalproject，其含義不好理解，暫譯為"軼事工程"，盼指正--譯者）的失敗幾率總是存在，一些低至百分之五十而另一些高達(dá)百分之八十，但是所有的這些都表明：你失敗的機(jī)會(huì)大于你成功的機(jī)會(huì)。為什么我要從這個(gè)令人喪氣的預(yù)測開始我的話題呢？因?yàn)槊恳惶扉_始時(shí)，我都想“今天將會(huì)不同，我今天能夠完成四倍數(shù)量的事情”，盡管（在此之前）有過一系列不間斷的例外。對(duì)于軟件工程來說，過度的狂熱往往被那些（只）關(guān)心結(jié)果人所夸大——“這一次，我們將解決以前從來沒有人解決過的問題，只需付出更少的時(shí)間和更小的代價(jià)”，盡管他們知道，真正的規(guī)則是：“你只能從此三者中選擇一個(gè)”。

記住你身后高高堆積的紙牌[i]非常重要。你手中有一根包含時(shí)代力量的魔術(shù)手杖或者是掛在懸崖上，會(huì)讓你做出完全不同的兩個(gè)決定。如果你懂得你的處境屬于后者，你將會(huì)說：“是的，這很好。但首先讓我們看看我們是否能夠在現(xiàn)有的進(jìn)度和預(yù)算情況下完成這一切?！?/p>

一個(gè)將不穩(wěn)定形勢(shì)和對(duì)失敗的認(rèn)識(shí)放到顯著位置的方法是研究過去的失敗。一份很好的資料是RobertsGlass（一位愛好研究崩潰的專家）的著作：《軟件失控》(SoftwareRunaways,出版信息：PrenticeHall1998)，以及他其它的著作。此外可以閱讀TomDemarco和TimLister的經(jīng)典之作《人件——生產(chǎn)性工程和團(tuán)隊(duì)》(Peopleware:ProductiveProjectsandTeam,出版信息：第二版，DorsetHouse,1999)。

2．切合實(shí)際地安排時(shí)間

時(shí)間安排的“魔法”經(jīng)常受到非開發(fā)人員為滿足軟件開發(fā)實(shí)踐之外的愿望和期待而產(chǎn)生的想法所驅(qū)使。最近我校正了自己的時(shí)間安排策略。我先將整個(gè)工程顯示腦海中，然后閉上眼睛，清理自己的大腦并讓它判斷這個(gè)工程大概需要多少時(shí)間。如果不考慮奇怪的技術(shù)問題、各種會(huì)議和其他分心的事物的影響，得出的這個(gè)時(shí)間居然非常合理。但我建議將這個(gè)合理的時(shí)間乘以3，或許可能是4，并且加上百分之十。如果這個(gè)估計(jì)出來的時(shí)間將讓你失去市場機(jī)遇，那么考慮不要進(jìn)行這個(gè)工程。如果你認(rèn)為像這樣計(jì)劃時(shí)間不合理，那么首先請(qǐng)注意，大多數(shù)工程將遵循這個(gè)規(guī)律。其次，試想一下，如果你所在公司的所有工程都很成功進(jìn)行會(huì)帶來局面：你將擁有更多的收入；更少的程序員會(huì)因?yàn)橛廾恋墓こ虝r(shí)間安排筋疲力盡而退出。

你也許還會(huì)爭論說這個(gè)時(shí)間評(píng)估技術(shù)非常沒有科學(xué)性，這一點(diǎn)我同意。然而，所有的軟件評(píng)估技術(shù)都含有臆測和直覺的成分在內(nèi)，甚至連功能點(diǎn)（原文為：functionpoint，若有其他正規(guī)譯法，請(qǐng)指正）分析都需要對(duì)功能點(diǎn)進(jìn)行猜測。我的“信封背面”技術(shù)將所有臆測結(jié)合到了一起，而不試圖假裝沒有猜測。用更少的時(shí)間，也許產(chǎn)生更好的結(jié)果。但是，我的猜測是建立在我自己的經(jīng)驗(yàn)之上的。

3．首先讓它運(yùn)作起來

當(dāng)我試圖進(jìn)行一些無意義的事情時(shí)，我最大的創(chuàng)造性成功來臨了。銘記最重要技巧——當(dāng)你開始一個(gè)工程時(shí)，你好比已經(jīng)用手指將自己掛在一個(gè)懸崖之上；然后你考慮一下能夠做什么瘋狂的事情簡單地讓你的工程運(yùn)作起來。這并不意味著你需要馬上投入進(jìn)去并用通常的方式開始撰寫代碼，你只需要盡早盡快找到一個(gè)轉(zhuǎn)換周期非常短的工具，用來判斷你是否可以做該項(xiàng)工作以及你的工程可行性如何。我在后面將要提到的Python語言就是這樣一種工具。

將你的計(jì)劃運(yùn)作起來有很多好處。憑你的經(jīng)驗(yàn)，你應(yīng)該知道，用戶只有能夠開始使用你開發(fā)的東西的時(shí)候才能理解你開發(fā)的是什么，然后他們會(huì)突然產(chǎn)生各種念頭并對(duì)該軟件應(yīng)該做些什么真正提出要求。一份系統(tǒng)說明書往往只是一份文檔，人們往往不會(huì)認(rèn)真地閱讀，但是如果你讓他們體驗(yàn)一個(gè)可運(yùn)行的程序之后，他們就會(huì)確切地明白你的意思。更早地了解用戶們真正想要什么豈不是更好？

事情往往會(huì)比你想象出來的要復(fù)雜四倍以上，所以對(duì)你能夠完成的東西要盡可能地保守一些。無論何時(shí)，一些不可知的因素都在伴隨著你的工作（這一點(diǎn)你可以從產(chǎn)品描述中一些“最”中察覺到：“最快”、“最大”、“最新”），原型的價(jià)值不能進(jìn)行夸大。如果在此之前你沒有做過類似的工程，那么最重要的事情是盡快地判明該工程是否可以實(shí)現(xiàn)，開發(fā)一個(gè)根本不能發(fā)揮作用的程序?qū)?huì)以浪費(fèi)你的大量金錢而收?qǐng)觥?/p>

最后一點(diǎn)，優(yōu)化。要能夠在這個(gè)階段抵抗得了誘惑。牢記DonaldKnuth說過的話（其中略有一點(diǎn)開玩笑的意思）：“不成熟的優(yōu)化是所有麻煩的根源”。雖然優(yōu)化是一些工程的關(guān)鍵因素，但是在確認(rèn)程序切實(shí)可行之前一切優(yōu)化都是盲目的。在最后建造系統(tǒng)之前瀏覽一遍所有的問題。每個(gè)工程都有一些你沒有接觸過的東西，你應(yīng)該首先將注意力放到這個(gè)領(lǐng)域，創(chuàng)建一個(gè)測試程序或者原型來尋找解決問題的方法。在你知道你是否可以做到并且知道做到的難度有多大之前，你沒有其他辦法能夠得知工程是否能夠成功、如何為它安排時(shí)間以及它需要多少付出等等。

4．使用恰當(dāng)?shù)墓ぞ?/p>

一個(gè)工程的早期部分應(yīng)該是高度探索性和實(shí)驗(yàn)性的，因?yàn)槟莻€(gè)階段是發(fā)現(xiàn)自己不會(huì)做什么以及如何去建造程序的階段。尋找最適合工具的最好方法是去體驗(yàn)一下他們，然后擯棄其中工作效率低下的那些。例如，你可能開始的時(shí)候用的是RationalRose，后來決定使用VisioProfessional來創(chuàng)建視圖，因?yàn)槟阈枰猇isio（或者通過Versa）提供的一些特性。

用來做工程的恰當(dāng)工具并不一定就必須是你已經(jīng)了解的編程語言。當(dāng)使用一種語言時(shí)，你就被局限在該語言所能表示的范圍之中了。如果你是一個(gè)C++程序員，你很自然可能想用C++創(chuàng)建所有的工程管理和工具。但當(dāng)你需要更加靈活的工具時(shí)，Perl是一種更快速的選擇（甚至將考慮學(xué)習(xí)需要的時(shí)間在內(nèi)）。在你的實(shí)際工程開發(fā)中，使用Python來快速造型或者甚至交付一個(gè)內(nèi)嵌Python語言的應(yīng)用程序?qū)⒔o你帶來更好的局面。首先，它是免費(fèi)的，所以不需要支付任何許可授權(quán)費(fèi)用；同時(shí)它對(duì)C和Java有完全兼容的接口，你可以使用Python解決所有Perl能夠解決的問題，所以它是C++和Java的一種完美的輔助語言。

5．接口的設(shè)計(jì)

在C++中，接口是一個(gè)包含所有虛函數(shù)的類；而在Java中接口技術(shù)被直接支持；在COM和COBRA中，你沒有其他選擇，你和所有的抽象打交道——所有的都是接口，沒有實(shí)現(xiàn)。接口提供了一個(gè)更加整潔的設(shè)計(jì)方式。要想讓程序員們確信這一點(diǎn)有些困難，但是它對(duì)將COM或者COBRA指定為構(gòu)件模型非常有幫助的（COBRA技術(shù)也是與操作系統(tǒng)無關(guān)的技術(shù)）。它不僅僅提供了工程實(shí)現(xiàn)語言的靈活性，并讓你能夠完全地將工程切割開來。如果你打算在你的開發(fā)組或者公司之外實(shí)現(xiàn)你的工程的一部分，整潔的接口可以阻止任何與工程其它部分不適當(dāng)?shù)倪B接，同時(shí)你可以用任何語言來進(jìn)行開發(fā)。你可以采取快速造型來實(shí)現(xiàn)所有的接口，稍后才對(duì)其中比較特別的部分進(jìn)行優(yōu)化。

6．設(shè)計(jì)時(shí)充分考慮異常情況

在C++中，異常控制并不像在Java中那樣得到有力支持——這是Java在工程管理方面成功之處。在設(shè)計(jì)、代碼編寫和模塊使用的時(shí)候往往會(huì)有一些錯(cuò)誤，除非軟件自身能夠通過拋出一個(gè)異常來聲明這些錯(cuò)誤，否則你將會(huì)花費(fèi)許多小時(shí)或月的時(shí)間來捕獲這些問題。只有通過嚴(yán)謹(jǐn)?shù)漠惓Ｊ褂茫悴拍鼙ＷC這些問題不會(huì)出其不意地讓你的工程陷入困境。

7．簡潔往往付出代價(jià)

雖然很難說服管理部門，但是“簡潔”這個(gè)詞是可維護(hù)性和復(fù)用性的同義詞。不僅如此，一個(gè)簡潔的程序讓人感覺很好。但是因?yàn)槲覀兇_信軟件工程是一種商業(yè)行為，目的是為了賺錢，而不是為了感覺，因此很難說簡潔的程序比其他非簡潔的程序更加有靈氣地結(jié)合在一起。但是由于軟件是一種能夠賺錢的藝術(shù)實(shí)體，在美學(xué)和實(shí)用性之間必然會(huì)一場爭論。

8．人與人之間的交流是一個(gè)瓶頸

這就是為什么小型的組隊(duì)往往更加有生產(chǎn)力的原因。當(dāng)一個(gè)工程像火焰一樣失去控制的時(shí)候，將更多的程序員扔進(jìn)火焰將使情況變得更糟。這也是為什么簡短的小會(huì)議往往可以發(fā)揮作用而冗長的大型會(huì)議卻做不到，還有為什么太深的管理機(jī)制會(huì)導(dǎo)致生疏的原因。參閱《人件》（早些時(shí)候提及過）一書了解更多的細(xì)節(jié)。

解決交流問題的最好辦法是免費(fèi)的：在一臺(tái)廢棄的計(jì)算機(jī)上安裝一個(gè)Linux服務(wù)器，你可以在幾分鐘內(nèi)完成這項(xiàng)工作，自動(dòng)安裝將包括一個(gè)Apache網(wǎng)頁服務(wù)器。然后將你們所有的文檔，從測試分析到用戶文檔，拷貝到服務(wù)器上，以便每個(gè)人都能夠訪問到最新的信息。你可以輕松地加入JavaServlets或者Perl腳本（/）或者Python(/)來收集每一頁的內(nèi)容，然后用一個(gè)List服務(wù)器來向所有的成員發(fā)送公告。如果你想用camera-ready格式來提供文檔，你可以用AdobeAcrobat格式來代替HTML格式。如果你的工程足夠大的話，指定一名成員專門負(fù)責(zé)維護(hù)服務(wù)器是值得的。

9．制定一份計(jì)劃（可以是任何類型的）

我曾經(jīng)見過許多工程在沒有簽訂任何合同（更別說一份計(jì)劃）時(shí)已經(jīng)有大量資金流動(dòng)。哪怕是對(duì)于一個(gè)很小的工程，你也需要某種計(jì)劃，甚至它可能只是被寫在