嵌入式系統(tǒng)工程師必須更聰明地工作
就在不久以前,我房地產(chǎn)界的好朋友Kirk閱讀了Tracy Kidder的《新機器的靈魂》。這本書講述了Data General公司的工程師們?nèi)绾卧趧?chuàng)紀(jì)錄的時間里生產(chǎn)出Eclipse計算機。Kirk認(rèn)為這是一本有趣的書,寫得很好;但是對其中高壓力的生產(chǎn)計劃和精疲力竭的人們感到難過。他說了一句讓我十分意外的話:“我無法相信Kidder所描述的這種高強度的日程安排是真的,沒有人能長久地像那樣工作。”
我該怎樣向一個與高科技領(lǐng)域沒有任何聯(lián)系的人解釋,日程安排一直都是我們最頭痛的事;在我的以及幾乎所有我認(rèn)識的工程師的職業(yè)生涯中,我們做的每一個項目的最后期限都是反復(fù)無常并且不可能完成的?最近幾年,時間線收縮得更多,以今天的標(biāo)準(zhǔn)來看,Kidder的敘述甚至可以說是過于溫和的。
我由此想到,不是身在技術(shù)行業(yè)的人對于我們?nèi)绾伪徊豢赡芡瓿傻淖詈笃谙薇频冒l(fā)瘋也許真的一無所知。我們的行業(yè)很獨特嗎?還有多少其他行業(yè)也有這樣長期、無情的壓力以使事情做得更快?經(jīng)常性的、沒有報酬的加班是否也是其他經(jīng)濟部門的主題?
較完善的項目管理軟件于20世紀(jì)80年代出現(xiàn)。任何人都可以輸入復(fù)雜的PERT(計劃評審法)和甘特(Gantt)圖。誰能成功地運用這些?我見過無數(shù)的開發(fā)人員試圖圍繞由市場設(shè)定的最后期限去建立時間表,他們希望這個時間安排具有可信度,但心里完全清楚是不可能的。我上中學(xué)的時候,耶穌會的教士們總在周五下午寄來成績單,我們會從郵箱抽出成績單,等到周一再重新塞回去,這樣周末就不會被毀掉。這只是個孩子氣的小花招,來推遲不可避免的事情;而這正是工程師們所做的。
項目進(jìn)度規(guī)劃軟件被宣傳為原始手工工具的進(jìn)步。現(xiàn)在,我們能更快速地制造錯誤數(shù)據(jù)。這就是計算機的美妙之處:以前需要幾秒鐘,甚至幾分鐘去犯一個錯誤,現(xiàn)在一秒鐘內(nèi)就可以產(chǎn)生幾千個錯誤。
人們寫軟件已超過50年之久,開發(fā)嵌入式系統(tǒng)也有30年了。這段時間里不變的是:日程計劃緊縮下的性能提升。
我們嘗試處理3件相互沖突的事:不可能完成的日程、過多的預(yù)期功能、質(zhì)量。如果去掉3條腿中的1條,這個項目就會失去價值。我們能夠在出貨時還存留很多bug嗎?如果答案是“是”,那么按時交付將會非常容易。我們能忽視出貨時間嗎?如果擁有無限的時間,我們就能完善每項功能。
這糾結(jié)的3者從一開始就成為隱患,而開發(fā)人員和管理人員卻無法認(rèn)識到矛盾所掩蓋的事實。老板無一例外地想要所有的3條腿:按時交付、完美的質(zhì)量、無窮的功能。但他不可能得到所有。
合乎邏輯的想法是,我們必須強調(diào)功能,因為日程計劃和質(zhì)量問題總是沒有商量余地的。利用需求淘汰法來識別并去除那些實際上并不需要的功能。用條理化的方式建立系統(tǒng),這樣即使落后于計劃,仍然可以拿出能良好完成大多數(shù)重要功能的產(chǎn)品。
當(dāng)然,還有其他因素影響開發(fā)環(huán)境:資源。合用的工具、足夠多的優(yōu)秀開發(fā)人員、開明的管理團(tuán)隊,這些構(gòu)成了我們要完成項目所需的基礎(chǔ)架構(gòu)。
20世紀(jì)里我們學(xué)習(xí)如何建立嵌入式系統(tǒng),但管理上卻一直沒有搞清楚資源在所開發(fā)項目中的恰當(dāng)位置。工程項目通常被看作如同是在生產(chǎn)線上制造小玩意。需要更多產(chǎn)品嗎?那就加入更多的人和更多的機器。但是這在軟件工程領(lǐng)域根本行不通。
Fred Books在他的《人月神化》(注:“人月”指一月人工)一書中展示了一個現(xiàn)象:給一個已經(jīng)滯后的軟件項目增加人員,這總會致使其更加滯后。兩個開發(fā)人員之間只有單一的通信渠道,但當(dāng)增加工程師時,備忘/會議/電子郵件的鏈接數(shù)量將隨人數(shù)的平方增長。
IBM發(fā)現(xiàn),當(dāng)項目的規(guī)模擴大,軟件生產(chǎn)率由于同樣的原因會明顯下降。他們的調(diào)查顯示代碼產(chǎn)量(行/天)隨著項目的擴大以數(shù)量級降低。
Barry Boehm的建設(shè)性成本模型是最著名的軟件規(guī)劃預(yù)測模型,它也顯示時間線比固件大小增長得快得多。將代碼行數(shù)乘以2,則交付時間的增加將遠(yuǎn)遠(yuǎn)超過一倍。有時會更多。
然而,當(dāng)一個項目出現(xiàn)麻煩時,“再雇些人回來”似乎是普遍應(yīng)用的管理格言。但就是不起作用。
難道沒有希望了么?我們的項目注定要失?。窟@種在《新機器的靈魂》中貼切描述的壓力是否就是我們的命運?
隨著項目復(fù)雜度迅速增長,很明顯,除非我們投身一種全新的開發(fā)模式,否則在過去的半個世紀(jì)里學(xué)到的關(guān)于軟件工程的一切會讓我們停滯不前、退化并最終失敗。接受新思維模式(以及已被驗證的舊模式)的那些公司將會獲得成功。特別有兩方面對新的理解十分關(guān)鍵,就是本文將要談到的重用和工具。
工具
20世紀(jì)40年代,所有的軟件用機器碼寫成。50年代見證了首個編譯語言:Fortran,幾乎是在一夜之間提高了編程效率。使用Fortran的代價是更大、更慢的代碼,這在當(dāng)時被過多的工程師認(rèn)為是不可接受的。但是那些接受了Fortran的人則證明是未來的先驅(qū)。
今天,關(guān)于建模、C++和Java,我們聽到了類似的爭論。太慢、太大。但很明顯,繼續(xù)制造出幾百萬行的C程序不能解決任何問題;要趕上日益增長的產(chǎn)品需求必須提高生產(chǎn)率,而手工編寫代碼不再提供這樣的提升。
高級語言給予我們抽象以及在更高層次做項目的能力。抽象是未來的基礎(chǔ)。我們再也不能去為比特和字節(jié)煩惱,因為這樣的代價太高。不管你喜歡與否,Windows API的確給臺式機開發(fā)者提供了大量豐富的資源。
各種風(fēng)格的工具能夠使我們從較底層的細(xì)節(jié)抽象出來。第一個Fortran編譯器,按今天的標(biāo)準(zhǔn)來看簡單得可笑,給予了50年代的工程師們強大的武器?,F(xiàn)在我們有了更多的選擇。
我們基本上接受編譯器帶來的額外開銷。其他抽象能力更強的工具會帶來更大的開銷,但也帶來了更快、更好的交付能力。建模工具,如UML,在一些領(lǐng)域以獲得成功。太少的開發(fā)人員充分了解LabView和MATLAB,而它們是嵌入式領(lǐng)域很重要的角色。
能夠自動搜尋bug的工具將會進(jìn)一步提高程序員的生產(chǎn)率。Coverity、Klocwork、Polyspace、Green Hills以及GrammaTech公司都在推動其尋找運行時問題的靜態(tài)分析器。這些工具當(dāng)然無法找到所有的bug,但它們提供了一項對付日程計劃的武器,雖然到目前為止的市場滲透率還很低。
重用
能讓我們更快地寫出更多代碼的工具只是解決方法的一部分。顯然,迫切需要一種新的重用模型。由百萬行代碼構(gòu)成的產(chǎn)品,如果一行一行編譯鏈接的話,那就太慢了。
把軟件工程中某些出色的新發(fā)展擋在門外,那么未來肯定只能屬于重用。除非我們能討來、借來、偷來或者買來大量的代碼庫,否則永遠(yuǎn)都得靠自己去寫每一行。這是難以忍受的。
重用不僅僅是把以前項目中的一些代碼保存起來,而是要回收利用超過20%的固件。百萬行以上規(guī)模的系統(tǒng)需要最大限度的重用。
讓我們定義幾個專門用語來說明什么是重用,什么不是。軟件回收是指利用并非為重用而設(shè)計的代碼。即在舊資源中取出一部分并放入新的應(yīng)用中。
代碼沿用是將固件從以前的項目移植到新項目中。和回收利用一樣,這通常是一種有些魯莽的源碼使用。
真正的重用是在建造系統(tǒng)的時候,一次建立一個組件,而不只是一行。這些塊已明確定義,這樣就不需要深入到內(nèi)部來進(jìn)行調(diào)整、調(diào)試或優(yōu)化。Richard Selby發(fā)現(xiàn),當(dāng)移植舊代碼到新項目時,如果超過25%被修改,就不能有效縮短項目時間。重用只有在大塊作用時才最有效。
一個程序包必須至少重用3次,才可看作是真正可重用。換句話說,域分析會比較難。我們還沒有聰明到能真正理解應(yīng)用程序的范疇。每個域要有自己獨特的功能和特點;當(dāng)我們在實際中,將代碼在足夠廣范圍的應(yīng)用上使用過多次以后,才能將其通用化到真正可重用的程度。
從這可以看出,重用是很昂貴的。我們花費了大量金錢來生產(chǎn)非常好的代碼,但只有重用3次時才有所回報。我們中有多少人有足夠的耐心和紀(jì)律性——以及時間——去寫為了以后使用的代碼?重用就像存折,如果你不向賬戶里存入足夠多的錢,它就沒有價值。你投資得越多,回報增長得越多。
何時我們能夠用購買的方式得到應(yīng)用程序的大部分,而不是從零開始去寫?軟件IC是否真的可能?
未來屬于那些足夠勇敢和聰明的人們,他們丟棄舊的思維模式,創(chuàng)造新的想法。我們將會找到利用以前寫就的代碼來設(shè)計產(chǎn)品的方法。這樣做的好處顯而易見,一行一行搭建系統(tǒng)的做法應(yīng)該停止了。這也許意味著在低端應(yīng)用中增加資源、存儲和高端CPU;也許意味著新的工具。我們當(dāng)然會用不同的方式設(shè)計系統(tǒng)。雖然一些實施細(xì)節(jié)目前還不明朗,但結(jié)果是非常清楚的。
最大的改變將是我們的態(tài)度,以及我們開發(fā)產(chǎn)品的方式??傆幸惶欤诠芾聿块T的支持下,我們都會認(rèn)識到2件重要的事:固件是最昂貴的東西、傻瓜都可以寫代碼。未來屬于那些尋找產(chǎn)品開發(fā)更好方式的開發(fā)者,而不是編程高手。
因此,我要對我的朋友Kirk和所有不是工程師的人說,我們的確在巨大的日程計劃壓力下工作。是你們的需求所致。你擁有的數(shù)字防抖雙目望遠(yuǎn)鏡、價值100美元的GPS、數(shù)字照相機,以及構(gòu)成你的世界的所有其他電子產(chǎn)品,都來自這些在最后期限面前掙扎并開發(fā)出驚人廉價、可靠系統(tǒng)的工程師們。
當(dāng)你使用這些系統(tǒng)之一的時候,偶爾也想想我們吧!我們正坐在實驗室里,在為下一個版本而工作。