編譯自Embedded.com  作者 Jack Ganssle

　　就在不久以前，我房地產(chǎn)界的好朋友Kirk閱讀了Tracy Kidder的《新機器的靈魂》。這本書講述了Data General公司的工程師們?nèi)绾卧趧?chuàng)紀錄的時間里生產(chǎn)出Eclipse計算機。Kirk認為這是一本有趣的書，寫得很好；但是對其中高壓力的生產(chǎn)計劃和精疲力竭的人們感到難過。他說了一句讓我十分意外的話：“我無法相信Kidder所描述的這種高強度的日程安排是真的，沒有人能長久地像那樣工作?！?

　　我該怎樣向一個與高科技領(lǐng)域沒有任何聯(lián)系的人解釋，日程安排一直都是我們最頭痛的事；在我的以及幾乎所有我認識的工程師的職業(yè)生涯中，我們做的每一個項目的最后期限都是反復無常并且不可能完成的？最近幾年，時間線收縮得更多，以今天的標準來看，Kidder的敘述甚至可以說是過于溫和的。

　　我由此想到，不是身在技術(shù)行業(yè)的人對于我們?nèi)绾伪徊豢赡芡瓿傻淖詈笃谙薇频冒l(fā)瘋也許真的一無所知。我們的行業(yè)很獨特嗎？還有多少其他行業(yè)也有這樣長期、無情的壓力以使事情做得更快？經(jīng)常性的、沒有報酬的加班是否也是其他經(jīng)濟部門的主題？

　　較完善的項目管理軟件于20世紀80年代出現(xiàn)。任何人都可以輸入復雜的PERT（計劃評審法）和甘特（Gantt）圖。誰能成功地運用這些？我見過無數(shù)的開發(fā)人員試圖圍繞由市場設(shè)定的最后期限去建立時間表，他們希望這個時間安排具有可信度，但心里完全清楚是不可能的。我上中學的時候，耶穌會的教士們總在周五下午寄來成績單，我們會從郵箱抽出成績單，等到周一再重新塞回去，這樣周末就不會被毀掉。這只是個孩子氣的小花招，來推遲不可避免的事情；而這正是工程師們所做的。

　　項目進度規(guī)劃軟件被宣傳為原始手工工具的進步?，F(xiàn)在，我們能更快速地制造錯誤數(shù)據(jù)。這就是計算機的美妙之處：以前需要幾秒鐘，甚至幾分鐘去犯一個錯誤，現(xiàn)在一秒鐘內(nèi)就可以產(chǎn)生幾千個錯誤。

　　人們寫軟件已超過50年之久，開發(fā)嵌入式系統(tǒng)也有30年了。這段時間里不變的是：日程計劃緊縮下的性能提升。

　　我們嘗試處理3件相互沖突的事：不可能完成的日程、過多的預期功能、質(zhì)量。如果去掉3條腿中的1條，這個項目就會失去價值。我們能夠在出貨時還存留很多bug嗎？如果答案是“是”，那么按時交付將會非常容易。我們能忽視出貨時間嗎？如果擁有無限的時間，我們就能完善每項功能。

　　這糾結(jié)的3者從一開始就成為隱患，而開發(fā)人員和管理人員卻無法認識到矛盾所掩蓋的事實。老板無一例外地想要所有的3條腿：按時交付、完美的質(zhì)量、無窮的功能。但他不可能得到所有。

　　合乎邏輯的想法是，我們必須強調(diào)功能，因為日程計劃和質(zhì)量問題總是沒有商量余地的。利用需求淘汰法來識別并去除那些實際上并不需要的功能。用條理化的方式建立系統(tǒng)，這樣即使落后于計劃，仍然可以拿出能良好完成大多數(shù)重要功能的產(chǎn)品。

　　當然，還有其他因素影響開發(fā)環(huán)境：資源。合用的工具、足夠多的優(yōu)秀開發(fā)人員、開明的管理團隊，這些構(gòu)成了我們要完成項目所需的基礎(chǔ)架構(gòu)。

　　20世紀里我們學習如何建立嵌入式系統(tǒng)，但管理上卻一直沒有搞清楚資源在所開發(fā)項目中的恰當位置。工程項目通常被看作如同是在生產(chǎn)線上制造小玩意。需要更多產(chǎn)品嗎？那就加入更多的人和更多的機器。但是這在軟件工程領(lǐng)域根本行不通。

　　Fred Books在他的《人月神化》（注：“人月”指一月人工）一書中展示了一個現(xiàn)象：給一個已經(jīng)滯后的軟件項目增加人員，這總會致使其更加滯后。兩個開發(fā)人員之間只有單一的通信渠道，但當增加工程師時，備忘/會議/電子郵件的鏈接數(shù)量將隨人數(shù)的平方增長。

　　IBM發(fā)現(xiàn)，當項目的規(guī)模擴大，軟件生產(chǎn)率由于同樣的原因會明顯下降。他們的調(diào)查顯示代碼產(chǎn)量（行/天）隨著項目的擴大以數(shù)量級降低。

　　Barry Boehm的建設(shè)性成本模型是最著名的軟件規(guī)劃預測模型，它也顯示時間線比固件大小增長得快得多。將代碼行數(shù)乘以2，則交付時間的增加將遠遠超過一倍。有時會更多。

　　然而，當一個項目出現(xiàn)麻煩時，“再雇些人回來”似乎是普遍應用的管理格言。但就是不起作用。

　　難道沒有希望了么？我們的項目注定要失??？這種在《新機器的靈魂》中貼切描述的壓力是否就是我們的命運？

　　隨著項目復雜度迅速增長，很明顯，除非我們投身一種全新的開發(fā)模式，否則在過去的半個世紀里學到的關(guān)于軟件工程的一切會讓我們停滯不前、退化并最終失敗。接受新思維模式（以及已被驗證的舊模式）的那些公司將會獲得成功。特別有兩方面對新的理解十分關(guān)鍵，就是本文將要談到的重用和工具。

工具

　　20世紀40年代，所有的軟件用機器碼寫成。50年代見證了首個編譯語言：Fortran，幾乎是在一夜之間提高了編程效率。使用Fortran的代價是更大、更慢的代碼，這在當時被過多的工程師認為是不可接受的。但是那些接受了Fortran的人則證明是未來的先驅(qū)。

　　今天，關(guān)于建模、C++和Java，我們聽到了類似的爭論。太慢、太大。但很明顯，繼續(xù)制造出幾百萬行的C程序不能解決任何問題；要趕上日益增長的產(chǎn)品需求必須提高生產(chǎn)率，而手工編寫代碼不再提供這樣的提升。

　　高級語言給予我們抽象以及在更高層次做項目的能力。抽象是未來的基礎(chǔ)。我們再也不能去為比特和字節(jié)煩惱，因為這樣的代價太高。不管你喜歡與否，Windows API的確給臺式機開發(fā)者提供了大量豐富的資源。

　　各種風格的工具能夠使我們從較底層的細節(jié)抽象出來。第一個Fortran編譯器，按今天的標準來看簡單得可笑，給予了50年代的工程師們強大的武器?，F(xiàn)在我們有了更多的選擇。

　　我們基本上接受編譯器帶來的額外開銷。其他抽象能力更強的工具會帶來更大的開銷，但也帶來了更快、更好的交付能力。建模工具，如UML，在一些領(lǐng)域以獲得成功。太少的開發(fā)人員充分了解LabView和MATLAB，而它們是嵌入式領(lǐng)域很重要的角色。

　　能夠自動搜尋bug的工具將會進一步提高程序員的生產(chǎn)率。Coverity、Klocwork、Polyspace、Green Hills以及GrammaTech公司都在推動其尋找運行時問題的靜態(tài)分析器。這些工具當然無法找到所有的bug，但它們提供了一項對付日程計劃的武器，雖然到目前為止的市場滲透率還很低。

重用

　　能讓我們更快地寫出更多代碼的工具只是解決方法的一部分。顯然，迫切需要一種新的重用模型。由百萬行代碼構(gòu)成的產(chǎn)品，如果一行一行編譯鏈接的話，那就太慢了。

　　把軟件工程中某些出色的新發(fā)展擋在門外，那么未來肯定只能屬于重用。除非我們能討來、借來、偷來或者買來大量的代碼庫，否則永遠都得靠自己去寫每一行。這是難以忍受的。

　　重用不僅僅是把以前項目中的一些代碼保存起來，而是要回收利用超過20%的固件。百萬行以上規(guī)模的系統(tǒng)需要最大限度的重用。

　　讓我們定義幾個專門用語來說明什么是重用，什么不是。軟件回收是指利用并非為重用而設(shè)計的代碼。即在舊資源中取出一部分并放入新的應用中。

　　代碼沿用是將固件從以前的項目移植到新項目中。和回收利用一樣，這通常是一種有些魯莽的源碼使用。

　　真正的重用是在建造系統(tǒng)的時候，一次建立一個組件，而不只是一行。這些塊已明確定義，這樣就不需要深入到內(nèi)部來進行調(diào)整、調(diào)試或優(yōu)化。Richard Selby發(fā)現(xiàn)，當移植舊代碼到新項目時，如果超過25%被修改，就不能有效縮短項目時間。重用只有在大塊作用時才最有效。

　　一個程序包必須至少重用3次，才可看作是真正可重用。換句話說，域分析會比較難。我們還沒有聰明到能真正理解應用程序的范疇。每個域要有自己獨特的功能和特點；當我們在實際中，將代碼在足夠廣范圍的應用上使用過多次以后，才能將其通用化到真正可重用的程度。

　　從這可以看出，重用是很昂貴的。我們花費了大量金錢來生產(chǎn)非常好的代碼，但只有重用3次時才有所回報。我們中有多少人有足夠的耐心和紀律性——以及時間——去寫為了以后使用的代碼？重用就像存折，如果你不向賬戶里存入足夠多的錢，它就沒有價值。你投資得越多，回報增長得越多。

　　何時我們能夠用購買的方式得到應用程序的大部分，而不是從零開始去寫？軟件IC是否真的可能？

　　未來屬于那些足夠勇敢和聰明的人們，他們丟棄舊的思維模式，創(chuàng)造新的想法。我們將會找到利用以前寫就的代碼來設(shè)計產(chǎn)品的方法。這樣做的好處顯而易見，一行一行搭建系統(tǒng)的做法應該停止了。這也許意味著在低端應用中增加資源、存儲和高端CPU；也許意味著新的工具。我們當然會用不同的方式設(shè)計系統(tǒng)。雖然一些實施細節(jié)目前還不明朗，但結(jié)果是非常清楚的。

　　最大的改變將是我們的態(tài)度，以及我們開發(fā)產(chǎn)品的方式?？傆幸惶?，在管理部門的支持下，我們都會認識到2件重要的事：固件是最昂貴的東西、傻瓜都可以寫代碼。未來屬于那些尋找產(chǎn)品開發(fā)更好方式的開發(fā)者，而不是編程高手。

　　因此，我要對我的朋友Kirk和所有不是工程師的人說，我們的確在巨大的日程計劃壓力下工作。是你們的需求所致。你擁有的數(shù)字防抖雙目望遠鏡、價值100美元的GPS、數(shù)字照相機，以及構(gòu)成你的世界的所有其他電子產(chǎn)品，都來自這些在最后期限面前掙扎并開發(fā)出驚人廉價、可靠系統(tǒng)的工程師們。

　　當你使用這些系統(tǒng)之一的時候，偶爾也想想我們吧！我們正坐在實驗室里，在為下一個版本而工作。

　　作者介紹：Jack Ganssle是嵌入式系統(tǒng)開發(fā)方面的授課者和顧問，在embedded.com的一次問卷調(diào)查中，被評選為嵌入式領(lǐng)域20年中最重要的人物之一；其他當選者包括Linux的創(chuàng)造者Linus Torvalds、Wind River公司的創(chuàng)始人Jerry Fiddler，以及Steve Jobs、Gordon Moore和GNU計劃的發(fā)起人Richard Stallman。