嵌入式系統(tǒng)工程師必須更聰明地工作

    編譯自Embedded.com  作者 Jack Ganssle

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　難道沒有希望了么？我們的項(xiàng)目注定要失?。窟@種在《新機(jī)器的靈魂》中貼切描述的壓力是否就是我們的命運(yùn)？

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

工具

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

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

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

　　各種風(fēng)格的工具能夠使我們從較底層的細(xì)節(jié)抽象出來。第一個(gè)Fortran編譯器，按今天的標(biāo)準(zhǔn)來看簡單得可笑，給予了50年代的工程師們強(qiáng)大的武器。現(xiàn)在我們有了更多的選擇。

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

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

重用

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

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

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

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

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

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

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

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

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

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

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

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

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

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