大道至簡軟件工程實踐者的思想

序2004年11月初愛民(Aimingoo)第一次把他的書稿給我，我翻看了一下，第一反應講的是感想。這不錯，在技術(shù)界就是需要有真正實踐經(jīng)驗的專家把他的思考和心得與我們。Aimingoo在Delphi領(lǐng)域頗有名氣，其技術(shù)鉆研的深度直達系統(tǒng)層，從其著作《Delphi源代碼分析》可見一斑。不過接下來第二反應就是太薄了，能不能加厚啊。比如說這些感悟都是有其來源的，可以把實際案例啊，背景故事啊都加上。不然太薄了，沒有辦法啊?！獓覍τ诘臅柺怯袊栏窨刂频?，所以書號是有成本的。一本講技術(shù)高端的銷量肯定是有限的，以現(xiàn)實情況而言，如果很薄定價就只能比較低，成本無法回收。而且內(nèi)容只是心得，沒有案例，讀起來也很硬，對讀者的要求也很高，銷量可能就更少了。愛民聽完我的意見，還是堅持這本書就是這樣的風格。出厚書違背了他的本意，要不然怎么叫“大道至簡”。書稿在200537月開始在《程序員》上陸續(xù)選擇其中的三章，看看讀者的反饋。不過限于篇幅，刪掉了一些內(nèi)容，不能完整體現(xiàn)出作者系統(tǒng)思考的脈絡，也比較遺憾。2005年11月愛民跟我討論到即使沒有愿意出版印刷，也要把他的作品用問世，并邀我作序。我十現(xiàn)在，我又仔細從頭到尾讀了一遍。很多作者寫書是為厚而厚，大部分內(nèi)容都是水分，作者經(jīng)驗精華只有很少，甚至沒有。而這本書是作者從事十年開發(fā)工作的總結(jié)，雖然不厚，卻閃爍著獨立思考的光芒。一線浸近十年，回頭思考何為開發(fā)的本源？這些理論、方法的本質(zhì)為何？一看，這些道理稀松平常，專家教授無數(shù)著作早就談過，還用作者來寫嗎？其實不然，理論都是從實踐而來，但我們學習軟件開發(fā)的時候，是先掌握這些專家總結(jié)的果實，而不是探求本源，所謂“知其然而不知其所以然”。這些道理看似都知道，但卻沒有真正體會上身，在實踐中最重要的去應用這些道理，而不是方法。大多數(shù)人看書都希望學到一些招數(shù)、方法，能盡快在工作中用上，這是不錯。但要想真正達到更高境界，就必須明白背后的道理。真正的專家是從根上解決問題的，所以大物理學家楊振寧在針對本科生講物理學，講得深入淺出，大受歡迎，就是因為楊先生可以從歷史本源來剖析物理定律。只有招數(shù)，不理，碰到變化的情況，就束手無策了。而在軟件開發(fā)中，每個團隊、每個項目都不是盡然相同的。明白道理，才能知變通之道。這本小書不是一本教你項目管理，軟件工程或者編程技巧的書籍，他是一本閃爍思考光芒的技術(shù)散，我衷心祝愿這本書的讀者，能把這本書當作一位朋友的思考，一位朋友的總結(jié)，來參照自身，這樣就會有收獲，有想法了。我也和愛民建議，這本書的很多還可以展開，無論是批評，還是討論，只要有的朋友，可以給愛民，我或者《程序員》社寫信，我們誠懇邀請各位來共同思考，共同把實踐經(jīng)驗與大家，這樣意義也就更大了。期望大家的參與，謝謝。2005．11我終于決定發(fā)布這本書的了。完成這本書的時候，我已經(jīng)在這個行業(yè)里做了十年了。這十年來，我對自己的經(jīng)歷做過兩次回顧。第一次是關(guān)于技術(shù)的，這造就了那本《Delphi源代碼分析》，是討論開發(fā)的技術(shù)和方法細節(jié)的。第二次就催生了這本《大道至簡》，討論的則是工程、管理中的思想。我其實是很希望這本書能放在讀者的書架案頭，而不是放在電腦的某一個中。因為它應當是一本可以閱讀和品味的書，而不是在電腦中備查的技術(shù)資料。然而，我在決定擔任這家公司的軟件架構(gòu)師的同時，我就，我沒有足夠的精力來運作這本書?！业囊馑际侨绻阉龀杉堎|(zhì)的書的話，我沒有足夠的精力。商是要尋求利潤的。——于此我一早就知道。但我從來不知道：到底一本書簿一點或者厚一點，哪個會讓商更有利潤。我只想寫一本“闡明軟件工程的思想”的書。這本書要很容易就讀明白，還要很容易就想通，還要很容易就知道：工程其實很簡單，只是大家把它做復雜了。110我當然可以把一本書寫得很復雜，或者很厚。這很容易，就如做Coder一樣：把代碼寫爛或者寫亂都很容易，要想寫得簡潔卻遠非易事。代碼寫得太簡潔，會認為你在偷懶；書寫得太薄，就不愿意出。我看來是忘掉了先生的“買書如買紙”，以書的厚薄來論價值的故事。忘掉了就忘掉吧。好的一面是現(xiàn)在書變成了大家終于可以讀到它了。不好的呢？大概不要錢的東西很難得到珍視吧：如果這本書只是因為收集，而不是閱讀，那會是讓我感到比討論“買書如買紙”這樣的事更為難過的。好吧。希望你能象對待紙質(zhì)書籍那樣來閱讀這本《大補充補充：我保留在傳統(tǒng)(書籍、)上載、本書的權(quán)利。但允許任何人在網(wǎng)絡上非商業(yè)性地、自由地、不加修改地這本書的本。 編程的精義編程的精義 會或者不會寫程序 程序=算法+結(jié) 語言 在沒有工程的時代 是懶人造就了方法是懶人造就了方法 一百萬行代碼是可以寫在一個文件里的 你桌上的書是亂的 我的第一次思考：程序=算法+結(jié)構(gòu)+方法 團隊缺乏的不只是管理三個人的團隊做項目=游戲?ISO質(zhì)量體系的教訓誰動搖了你的制度？組織的學問：角色跟隨螞蟻。但不要栽進螞蟻洞里。 “什么 ？” 流于形式的溝通客戶不會用C，難道就會用UML嗎 項目文檔真的可以用甲骨文來寫 最簡溝通 為不存在的角色留下溝通的 流于形式的溝通 失敗的過程也是過程 做過程不是做工程 過程不是死模型 工程不是做的，是組織的從編程到工程 語言只是工具 BOSS 上帝之手 7.現(xiàn)實中的軟件工程 大公司手中的算盤 回到工程的關(guān)鍵點 思考項目成本的經(jīng)理 MDA8.是思考還是思想 軟件工程三個要素的價值 RUP是一個雜物箱 UML與甲骨文之間的異同 經(jīng)營者離開發(fā)者很遠，反之亦然 ：實現(xiàn)目標與保障質(zhì)量 枝節(jié)與細節(jié) 靈活的軟件工程第1章編程的精義“雖我之死，有子存焉；子又生孫，子；子又有子，子又有孫。子子孫孫，無窮匱也。而山不加增，何苦而不平？”——《愚公移山》，《列子·湯問篇》編程的精僅僅就編程序來說，實在是一件很簡單的事，甚至可以說是一件勞力活。兩千年前的寓言中，已經(jīng)成就了一位工程名家：愚公。在這位名家的身上，濃縮了項目組織者、團隊經(jīng)理、編程人員、技術(shù)分析師等眾多角色的優(yōu)秀素質(zhì)。他的出現(xiàn)，遠遠早于計算機發(fā)展的歷史，甚至早于一些西方國家的文明史。湯問篇中所述的愚公移山這一，我們看到了原始需求的產(chǎn)生：“懲山北之塞，出入之迂”我們也看到了項目溝通的基本方式：“聚室而謀曰”然后，我們看到愚公確定了一個項目的目標：1并通過研討，擇定了一個井然有序的、可以實現(xiàn)的技術(shù)方案：“扣石墾壤，箕畚運于渤海之尾”在這個項目中，動用了三名技術(shù)人員和一名工程管理人員：(愚公)率子孫荷擔者三夫”并獲得了一名力量較弱，但滿富工作的外協(xié)：“鄰人氏之孀妻，有遺男，始齔，跳往助之基本上，這已經(jīng)描述了“愚公移山”整個工程的概況。接下來，我們應該注意到愚公作為編程人員的基本素質(zhì)。在與“河曲智叟”的對答中，他敘述了整個工程的實現(xiàn)程序：雖我之死，有子存這里描述了可能存在的分支結(jié)構(gòu)，即“IF”條件判斷。“子又生孫，子；??子子孫孫，無窮匱也”，這里描述了完成這個工程所必須的循環(huán)結(jié)構(gòu)。作為優(yōu)秀的程序分析師，愚公論述了這個循環(huán)的可行性：由于“山不加增”，所以條件“山平”必將成立(“何苦而不平”)所以這不會是一個死循環(huán)。在愚公的論述中，我們看到了編程的根本：順序、分支和循環(huán)。龐大若“愚公移山”這樣的工程，都是可以通過這樣簡單的編程來實現(xiàn)的。這，就是編程的精義了。會或者不會寫程序的問題我經(jīng)常會問到“(我)能不能學會寫程序”這樣的這個問題由來以久。上溯七、八年，程序員還是少有人從事的職業(yè)。聽說的人少，真正了解的人也不多。而當一個程序軟件被裝在電腦里并開始運行時，人們便開始驚訝于程序員的厲害。所以“能不能學會寫程序”甚至成了一些人對自己的智力考評，所以便有人向我這樣發(fā)問。愚公都能明白的編程精義，那些向我發(fā)問的智叟們又怎么會不明白呢？1所以除了智障或后天懶惰者，都是可以學會寫程序的。如果你能確信，自己知道在早上起床后需要：如果天冷則先穿衣服后洗漱如果天熱則可反之日復一日直到那么你就可以開始編程了。甚至，如果你認為以下條件成立：如果有類似于生病、不能行動、以及意外的緊急，則當日可以略過那么你就可以開始向設(shè)計師發(fā)展。因為你已經(jīng)具備了一項常人不具備的基本素質(zhì)：折衷。程序=算法+結(jié)構(gòu)編程作為一種行為，只需要知道其邏輯方法就可以了。所謂編程實際上是把一件事情交給計算機去做，你認為這件事該如何做，就用“程序語言”的形式描述給計算機。如果你原本就不明白如何去做，那么你也不要期望計算機去理解你想要做什么。所以編程的第一要務是先把事情分析清楚，先后的邏輯關(guān)系和依賴關(guān)系搞清楚，然后再去代碼實現(xiàn)。一接到任務就開始Coding的程序員，通常就是加班最多的程記?。悍e極工作和勤于思考都要占時間。第一個完成關(guān)于編程本質(zhì)的思考的人，提出了一個公式“程序=算法+結(jié)構(gòu)”。這個的之處，在于它沒有任何的地方提及到Code。甚至可以說，在這個里，代碼是不存在的。存在的只是思想。算法是對一個程序的邏輯實現(xiàn)的描述，而結(jié)構(gòu)是邏輯實現(xiàn)所依附的數(shù)據(jù)實體。只要開發(fā)人員將這個程序的算法設(shè)計出來了，把結(jié)構(gòu)描述出來了，那么程序就已經(jīng)定型了。剩下的事，簡而言之，就是勞力活。在計算機專業(yè)所學的課程中，同時講述算法和結(jié)構(gòu)的，是“數(shù)據(jù)結(jié)構(gòu)。現(xiàn)在，你放下手邊這本書，再去讀讀被你扔到不知哪個角落的《數(shù)據(jù)結(jié)構(gòu)》，你仔細看看，在所有的算法描述中，有且僅有三種執(zhí)行邏輯：順序、分支和循環(huán)。簡單若順序表，復雜如樹、圖，它們的算法都是用上面這三種執(zhí)行邏輯來描述的。1語當你熟悉了一門語言之后，你會發(fā)現(xiàn)，編程語言只有喜歡與不喜歡的問題，沒有會不會的問題。任何的一門語言，你都可以在兩周內(nèi)掌握并開始熟練編程。因為任何的一門語言，他們的底層函數(shù)庫都是那么的相似，而他們API都是那樣的依賴于操作系統(tǒng)。A語言里有的，B語言里也基本都有。通常而言，語言的差別主要表現(xiàn)在適用范圍上。一些語言適合做數(shù)值處理，小數(shù)點后可以精確到原子級，而小數(shù)點前則可以表達到宇宙之無窮；另一些語言則適合做圖形處理，它的底層函數(shù)庫比其它語言可以快上十倍或數(shù)十倍；還有一些語言則適合于做網(wǎng)頁，要用它來做一個通訊薄軟件都將是史無前人的。成天討論這門語言好，或者那門語言壞的人，甚至是可悲的。不但是悲其一葉障目，更要悲嘆于那種大愚若智的自得心態(tài)。在沒有工程的時在沒有工程的時代，上面所說的就是一個程序員的全部。他們掌握了一門語言，懂得了一些生活中最常見的邏輯，他們用程序的方式思考和學習了一些算法，并根據(jù)前人的經(jīng)驗，把這些算法跑在了一些數(shù)據(jù)結(jié)構(gòu)之上，最后，我們就看到了他們寫的程序。在沒有工程的時代，出現(xiàn)了非常非常多的人物。其中算法大師，有游戲大師，有語言大師，有掙錢的大師??唯獨，沒有工程大師。嗯，可以理解嘛，那是沒有工程的時代。好蠻荒，第2章是懶人造就了方法僰道有蜀王兵蘭，亦有神作大灘江中。其崖嶄峻不可破，（冰）乃燒之?！薄度A陽國志》是懶人造就了方戰(zhàn)國時期的李冰鑿了一座山。史記中說是“蜀守冰鑿離堆”，是說李冰在的時候鑿出了離堆。一說是李冰將都江堰附近的玉壘山鑿了一個大口子，叫寶瓶口，而鑿的石頭就堆成了離堆。另一說，則是李的確是鑿了一座“溷)崖”，但是是在沫水，亦即是今天的大渡河。在哪里鑿的山，是史學家都說不清楚的事。但的確鑿了一座山，而且方法是“(因)其崖嶄峻不可破，(冰)乃積我們已經(jīng)看到事物的進化了。同是戰(zhàn)國時代，《列子·湯問篇》里的愚公就要“碎石擊壤”，而李冰就已經(jīng)懂得“燒之”了。會有人說愚公是“碎石”，并沒有說他“碎石”的方法究竟是“斧鉞以鑿之”，還是“以燒之”。但想想那個時代，如果有人懂得了燒石頭這個方法，哪能不立即載文志之，永世再說了，愚公嘛。愚者怎么會呢？這還需要分析嗎？所以愚公會鑿，而李冰會燒。那李冰又是為什么會用“燒”這種方法來碎石的呢？如果李冰也象愚公那樣日復一日地督促著他的團隊鑿石開山，那他一定沒有時間來學習、尋找或者觀察，當然也不會發(fā)現(xiàn)“燒”這種方法可以加快工程進度，使得一大座山短時間就被嘩啦嘩啦地給“碎”掉了。要知道李冰的團隊可是成百上，要修堰筑壩，還要“鑿離堆”，當然還要吃喝睡。所以李冰如果忙起來的話他必然是受命以來，夙夜憂嘆”，必然食難下咽，睡無安枕。反之，李冰一定是個閑人，可以閑到?jīng)]事去看火能不能把石頭燒爆。這么大個工程里，如果有一個人會閑到看火燒石頭，那他一定很懶。那么多事堆著不去做，去看燒石頭，你說他不是懶是什么。正是一個懶人造就了“燒石頭”這個“碎石”的方法。愚公太勤快了，勤快得今天可以比昨天多鑿一倍的石頭。或者在愚公的項目計劃案的首頁里就寫著朱筆大字：“吾今勝昨倍許，明勝今倍許，而山不加增，何苦而不快。”但是越發(fā)的勤快，愚公將越發(fā)沒有機會找到更快的方法，人的精力終歸是有極限的。提出新的“方法”，解決2的將是影響做事成效的根本問題。而愚公可以多吃點飯，多加點班，但突破不了人的精力的極限。記住，在兩千年前的某一天，閑極無聊的李冰下廚給夫人炒了一個小菜，他突然發(fā)現(xiàn)壘灶的鵝卵石被燒得爆裂開來，遇水尤甚。從此《史記》上記下了“蜀守冰鑿離堆”，而《華陽國志》上記下了他做這件事的方法“燒之”。一百萬行代碼是可以寫在一個文件里的早期寫程序，都是將代碼打在穿孔紙帶上，讓計算機實我也沒有那樣寫過程序，真實的苦楚我也不知道。后來有了匯編語言，可以寫一些代碼了。這時的代碼是寫在文本文件里，然后交給一個編譯器去編譯，再由一個器去，這樣就出來了程序。“ oWorld”程序，那個程序?qū)懺谝粋€文件里就行了。所以后來就成了慣，大家都把代碼寫到一個文件里。早期的匯編語言里，GTO語句是用得非常非常頻繁的，將一個語句GTO到另一個文本文件里去，既不現(xiàn)實也不方便。所以大家習以為常，便統(tǒng)統(tǒng)地把代碼寫到一個文件里。再后來出了高級語言，什么CPascal呀之類的。既然大家已經(jīng)形成習慣了，所以很自然地會把一個程序?qū)懙揭粋€文件里。無論這個程序有多大，多少行代碼，寫到一個文件里多方便呀。直到如今語言發(fā)展得更高級了?？墒浅绦騿T的習慣還是難改，一旦得了機會，還是喜歡把代碼寫到一個文件里的。好了，有人說我是想當然爾。En，這當然是有實據(jù)的。記得Delphi1.0版發(fā)布的時候，全世界一片叫好聲。連“不支持雙字節(jié)”這樣的大問題，都不影響他在華語地區(qū)的推廣。然而不久，爆出了一個大BUG！什么大BUG呢？Delphi1.0的編譯器居然不支持超過64K的源代碼文件！這被Fans們一通好罵。直到我用Delphi2.0時，一個從VB陣營轉(zhuǎn)過來的程序員還跑過來問我這件事。好在Delphi2.0改了這個BUG，這讓當時我的面子上好一陣風2光。64k的文件是什么概念呢？1行代碼大概(平均)是30字節(jié)，64k的源代碼是2184行，如果代碼風格好一點，再多一些空行的話，差不多也就是3000行上下。也就是說，在Delphi1的時代(以及其后的很多很多時代)，程序員把3000行代碼寫到一個文件里，是司空見慣的事了。如果你不讓他這樣寫，還是會被痛罵的呢。所以呢，按照這一部分人的邏輯，一百萬行代碼其實是可以寫在一個文件里的。不單可以，而且編譯器、編輯器等等也都必須要支持。這才是正統(tǒng)的軟件開發(fā)。勤快的愚公創(chuàng)造不了方法。這我已經(jīng)了。對于要把“一百萬行代碼寫到一個文件”，查找一個函數(shù)要在編輯器里按五千次PageDown/PageUp鍵的勤快人來說，是不能指望他們創(chuàng)造出“單元文件(Unit)”這樣的開發(fā)方法然而單元文件畢竟還是出現(xiàn)了。上，有勤快人就必然有懶人，有懶人也就必然有懶人的懶方法。有了單元文件，也就很快出現(xiàn)了一個新的概念：模塊。把一個大模塊分成小模塊，再把小模塊分成更細的小小模塊，一個模塊對應于一個單元。于是我們可以開始分工作很好，終于可以讓源代碼分散開來。結(jié)構(gòu)化編程的時代終于開始了，新的方法取代了舊的方法，而這一切的功勞，是要歸終于那個在按第5001次PageDown鍵時，突然的程序師。他發(fā)自良心地說：不能讓這一切繼續(xù)下去我要在編譯器里加入一個Unit關(guān)鍵字。①你桌上的書是亂的嗎幾周之前，在一所電腦培訓學校與學生座談時，一個學員問我：“為什么我學了一年的編程，卻還是不知道怎了想，問了這個學員一個問題：“你桌上的書是亂的嗎？”他遲疑了一下，不過還是回答我道：“比較整齊?！蔽耶敃r便反問他：“你既然知道如何把書分類、歸整得整整齊齊地放在書桌，那怎么沒想過如何把所學的知道分類一下，歸納一下，整整齊齊地放在腦子里呢？”如果一個人學了一年的編程，他的腦袋里還是昏乎乎①TurboPascal3.0中才開始有了Uses和Unit關(guān)鍵字。在ANSI標準里并沒有它。2有一個原因：他學了，也把知識學進去了，就是不知道這些知識是干什么的?；蛘哒f，他不知道各種知識都可以用來做什么。其實結(jié)構(gòu)化編程的基本單位是“過程(Procedure)”，而不是上一小節(jié)說到的“單元(Unit)”。然而在我看來，過程及其調(diào)用是CPU指令集所提供的執(zhí)行邏輯，而不是普通的開發(fā)人員在編程實踐中所總結(jié)和創(chuàng)生的“方法”。這里要提及到CPU指令集的產(chǎn)生。產(chǎn)生最初的指令集的方式我已經(jīng)不可考證，我所知道的是CISC指令集與RISC指令集之爭在1979年終于爆發(fā)。前者被稱為復雜指令集，然而經(jīng)過Patterson等科學家的研究，發(fā)現(xiàn)80%的CISC指令只有在20%的時間內(nèi)才會用到；更進一步的研究發(fā)現(xiàn)常用10條指令中含的流程控制只有件分支(IF...THEN(JUMP)用返回(CALL/RET)”??于是CISC被RISC(精簡指令集計算機)替代了。動搖CISC指令集地位的方法，就是分類統(tǒng)計。正如CISC指令集攪亂了一代程序設(shè)計師的思路一樣，大量的知識和資訊攪亂了上面給我提問的那位學員的思想。他應該嘗試一下分類，把既有的知識象桌子上的書一樣整理一下，最常用的放在手邊，而最不常用的放在書①在x86系統(tǒng)中，循環(huán)是用條件分支來實現(xiàn)的，而且條件分支指令并不是IF...THEN...，這里用這兩個關(guān)鍵字，僅用于說明問題。柜里。如果這樣的話，他已經(jīng)在九個月前就開始寫第一個軟件產(chǎn)品了。你桌上的書還是亂的嗎？我的第一次思考：程序=算法+結(jié)構(gòu)+方法我的第一次關(guān)于程序的本質(zhì)的思考其實發(fā)生在不久前。那是我在OICQ上與Soul的一次談話。Soul()是DelphiBBS現(xiàn)任的總版主，是我很敬重的一位程序員。那時我們正在做DelphiBBS的一個“B計劃II”，也就是出第二本書。他當時在寫一篇有關(guān)“面向?qū)ο?OP)”的文章。而我正在寫《Delphi源代碼分析》，在如下我：En.這個倒與我的意見一致。。①這段的確很長。如果你不是非常有經(jīng)驗的程序員，那么不能完整地閱讀和理解這段文字是很正常的。部分讀者甚至可以跳過這段引文，直接閱讀后面的結(jié)論。而有的讀者，可以在我的上讀到它的全文( 2Soul我：對流程進一步概括的，是“驅(qū)動”程序模型。而這個模型不是OO，而是Windows的消息系統(tǒng)內(nèi)置的。所以，現(xiàn)在很多人迷惑于“對象”和“”，試圖通過OO來解決一切的想法原本就是我：如果要了解驅(qū)動的本質(zhì)，就應該追溯到Windows內(nèi)核。這樣就Soul：OO里面我覺得的概念是很牽強的，因為真正的對象之間是相互來傳遞的。也就是說，模型停留在“面向過程”編程時代使用Soul：所以所謂的面向?qū)ο蟮倪€是“順序”的。所以我們經(jīng)常要考慮一個發(fā)生后對其他過程的影響，所以面向?qū)ο蟋F(xiàn)在而言是牽強我：如果你深入OS來看SEH，來看Messages，就知道這些東西原本就不我：的連續(xù)性并不是某種編程方法或者程序邏輯結(jié)構(gòu)所決定的。正如我：可能，將CPU夠龐大。但是我認為，如果有一天OS也是用.NETFramework來編寫的， 我：倒也不是不可能徹底。有絕對OO的模型，這樣的模型我見過。哈 Soul：還有不可能用徹底的面向?qū)ο蠓椒▉肀磉_世界。因為不我：程序＝ 我第一次提到我對程序的理解是“程序=數(shù)據(jù)+算法+方法”，便是在這一次與Soul的交談之中。在這次的交談2中的思考仍有些不成地方，例如我完全忽略了在面向過程時代的“方法”問題。實際上面向過程開發(fā)也是有相關(guān)的“方法”的。在代碼階段的一個習慣性的說法。而我忽略了這個階段的“方法”的根本原因，是即使沒有任何“方法”的存在，只需要有了“單元(Unit)”和“模塊(Module)”的概念，在面向過程時代，一樣可以做出任意大型的程序。在那個時代，“方法”問題并不會象鼻子一樣凸顯在每一個程序員的面前。面向過程開發(fā)中，“過程(procedure)CPU提供的，(unit)”則是編譯器提供的(機制)。程序員不需要(至少是不必須)再造就什么“方法”，就可以進行愚的開發(fā)工作了。如果不出現(xiàn)面向?qū)ο蟮脑?，這樣偉大的工程可能還要再干一百年??而與“面向?qū)ο蟆笔欠癯霈F(xiàn)完全無關(guān)的一個東西，卻因為“過程”和“單元”的出現(xiàn)而出現(xiàn)了。這就是工程(engineering第3章團隊缺乏的不只是管理——《漢書·高惠高后文功臣表序》顏師古注三個人的團隊《漢書》中說“言人三為眾”，是指三個人就算得上是“眾”了。這里的“眾”應該理解成一個群體，亦或者說是一個團隊。團隊是至少以三個人為規(guī)模的。這有其合理性。為什么呢？首先一個人算不得團隊，那是。兩個人則互相支撐，古文中“從”字是二人互立，就是這個意思。然而二人互立并不算團隊，因為沒有監(jiān)督。三個人便可以構(gòu)成團隊，這樣便有了團隊的一些基本特性：主從、監(jiān)督和責任。一個人的開為可以成功，這取決于個人努力。大家熟知的KV100、KV200反軟件，最早就是王江民先生一個人做出來的。二人小組如果能相互支撐，那也是①的是很多人的意思。然而，古人以“三”來泛指很多人或者群體，則是很值得玩味的事。3可以獲得成功的，同樣作為反軟件的AV95在9597年成功占據(jù)反軟件市場之一隅，就是周輝和劉杰先生兩個人的作品。然而到了三個人的時候呢，就得選個了。顏師古為《漢書·高惠高后文功臣表序》作注時，了孟康的話，說“取其功尤高者一人繼之，於名為眾”，簡意就是功高者代替群體受功。古人的受功當然包括封侯晉爵，因此這便仿然成了慣例而推廣開來，功勞大的、能力強的便成了團隊中的角色。殊不知彼時彼事，目的并非要選，表彰功績。項目結(jié)束會議上，總經(jīng)理M項目完成得很好，小S的進步尤其之大，他獨立完成了全部代碼的編寫，因此月獎加三倍。獎不可謂不豐然而這并不代表在下一個項目該讓小S來做項目經(jīng)理。同樣，三板斧定了瓦崗寨的，功不可謂不高，技不可謂不強。但不是將帥之才。做管理起碼需要能承擔責任，這是最基本的素質(zhì)?！妒酚洝ぱ袅袀鳌酚涊d了李離伏劍的故事。春秋時晉國最高司法長官李離，因為“過聽”，斷獄，把一個不該處死的人錯判了。隨后“自拘于廷，請死今過聽，傅其罪下吏，非所聞也?！彪S后拔 了同樣的道理你的項目經(jīng)理職位又沒有讓給別人做，你拿的經(jīng)理級工資又沒有分給別人，那項目失敗了，你為什么要把責任推到別人頭上呢？三人團隊中的那個，不是要一樣的牛人，李離一樣的死士。項目完成不了，切腦袋的事倒不必做，遞交辭呈的那點勇氣總是要有的。做項目=游戲如果項目做不成就要掉腦袋，那就象好比是枕著鍘刀在做程序；如果項目失敗就要交辭呈，那可能就從來不會有項目經(jīng)理。為什么這么說呢？3從管理角度來看，項目失敗與否與項目經(jīng)理的經(jīng)驗直接相關(guān)。我曾經(jīng)聽過一個來自澳大利亞的講師說軟件工程。她說到項目的成功是兩個方面的評估：項目完成質(zhì)量項目完成時間由于項目的時間是在項目前期對項目工期的設(shè)定，因此我問這個講師：什么方法能保證預期的工期是正確的，或者說是可以完成的。近地預估工期，但沒有辦法保障(預估的)工期是絕對合理的①。那么進一步的推論是，由于沒有絕對合理的工期，所以項目的完成時間可能總是被進度變更所修正，所以項目——看來外來的和尚(包括尼姑)也未必能比本地的更會念經(jīng)。在這一點上，來自澳大利亞的講師，與來自北極的愛斯基摩人(如果他們也念經(jīng)的話)如出一轍。項目工期的問題不能解決，就不能保證項目成功。只有經(jīng)驗更加豐富，才能更盡可能地近“合理的工期”。因此在此之前，項目經(jīng)理的就是失敗。這個失敗可能不是項目經(jīng)理本身能力所決定，或者也不是團隊成員的工作所決定，而是在一開始，那份給客戶的項目協(xié)議就簽錯了。項目經(jīng)理是需要時間來成。他需要有機會來承受錯誤，而不是一開始就享受成功。ISO質(zhì)量體系的教Y公司終于在2001①軟件工程中有專門的學科來研究項目的工期問題。學者們試圖尋找來計算項目的復雜度，從而計算出所需的工時和人月。然而在實踐中，這被認為是不可行的。3引進ISO質(zhì)量認證體系，希望通過這系來規(guī)范管理行為，提高產(chǎn)品質(zhì)量和對外的競爭力。他們做得非常認真，把全公司的人員都調(diào)動起來了，質(zhì)量手冊的論證做到了每一個員工；他們按照標準的軟件工程模型進行了開發(fā)流程的重組；每一份流程相關(guān)的材料都約定了格式，并進行了歸檔說明；每一個環(huán)節(jié)都設(shè)定了質(zhì)量監(jiān)督員來考核和回顧；??接下來，他們開始實施。三個月后，他們發(fā)現(xiàn)了一個問題：所有環(huán)節(jié)的質(zhì)量監(jiān)督員是同一個人，他沒有工程經(jīng)驗，于是他問題總是得不到工程的確認?！茱@然，沒有工程負責人愿意說自己這里存在問題：有問題就要改，就有可能中斷或者重新來過。再則這質(zhì)量監(jiān)督員也沒有管理權(quán)限，于是他即使確認了問題，也沒利要求立即整改，工程負責人隨時可以以進度為由擱置這份監(jiān)督報告。再兩三個月后，他們發(fā)現(xiàn)一切如舊，好象工作并沒有因為《質(zhì)量手冊》的存在而發(fā)生什么變化，在手冊上被改造的流程因為人力資源不充分而沒有辦法運作起來；絕大多數(shù)應該書寫的材料因為時間不夠而被“候補”。改變最大的是綜合部，這里多了一個虛設(shè)的機構(gòu)用于分ISO質(zhì)量，綜合部的經(jīng)理也變成了分管質(zhì)量的副總，但又沒有因此而多拿一分錢。改變最少的是開發(fā)部，其表現(xiàn)為每個人的顯示器頂上放了一本質(zhì)量手冊，用來擋住窗口射進來的陽光，以及落向顯示器的灰塵。兩年之后，我們一群人來回顧這一次失敗時，很多人都說是“體制的問題”，說是原有的公司到新的公司，不適合新的公司的管理體制以及對管理的要求。其實這并不十分正確。體制的內(nèi)涵是分兩個方面的，質(zhì)量體系”所產(chǎn)生的那份手冊只是“制度”，在它的背后，所要求的是對舊有“體系”的改變?！f的公司到新的公司，不是搬來一本“管理制度”給每個員工讀一遍就要可以的了。在這一個期，第一要務是解決“體”的問題，也就是“組織機構(gòu)建的問題。如果把這個問題縮小到開發(fā)部門的工程環(huán)節(jié)，那么就是“如何組織開發(fā)團隊”的問題。式，才能尋求相應的管理制度，并且才能把這樣的制度實施在團隊之上。漢朝的劉向在《新序·雜事二》中記錄了一個故事，說是出游，見路人把羊皮統(tǒng)子毛向內(nèi)3皮朝外地反穿著，還背著一簍喂牲口的草。文侯奇怪地問。這個人答道：我愛惜這件皮衣，怕毛被磨掉了。文侯嘆道：你難道不知道，如果皮被磨盡了，毛不也就掉光了嗎？皮之不存，毛將焉附。沒有確定的組織機構(gòu)，又如何能指望做出來的管理制度“合用”呢？Y公司在1999年至2001年一直保持著從K公司移植過來的組織機構(gòu)模式和管理模式，兩年的組織機構(gòu)建設(shè)的時候被白白浪費了。本來，做ISO體系是最后一次彌補組織機構(gòu)建設(shè)的機會，然而在管理者還沒有“皮之不存”的時候，Y誰動搖了你的制度組織模式確定的同時，相應的制度也有隨之建立。很少是有幾年之后才來補制度的。然而制度究竟決定了什么呢？我們先來看看，如果員工在工作中出了紕漏：沒有制度，你沒有辦法和依據(jù)來懲戒員工，因此是管理者的過失；有了制度而沒有懲戒他，是執(zhí)行者和監(jiān)督者的過一而再、再而三地犯錯，又一而再、再而三地被懲戒，那就是教而不改，就真正是員工的品性和素質(zhì)的問題了。因此，先做制度總是好的。至少在你選擇做伏劍自刎的李離之前，你還有機會把黑鍋扔到出問題的員工的頭上。對于一個已經(jīng)規(guī)范管理、體制健全的公司，不容許員工犯錯是對的。即使是一次犯錯，立即也說得過去。但還是有前提的，這至少包括：員工已經(jīng)接受過相關(guān)的培訓，這至少包括員工規(guī)技術(shù)技能的學習在該員工之前，相同的或者相關(guān)的錯誤沒有被枉縱第一條是人性化的體現(xiàn)。常說不知者不為過：員工不知道，管理者也沒有給他知道的條件，那怎么能說是他的過錯呢？如果因為不知道而出了問題，那管理者首先應該自省才是。第二條則是公平性的體現(xiàn)。不管是針對誰，制度都是一樣的，沒有情面可講的，常說的“特殊情況特殊處理”在制度面前行不通。規(guī)矩一旦被破壞就，反而被員工作為笑柄，用來類比其它的制度。如此一來，整個的制度也就離不遠了。反過來，在已經(jīng)被破壞了制度面前，若再做殺雞儆猴狀，那猴子是被嚇著了，不平聲、怨憤聲也就跟著出來了。因此最好的方法是趕緊修訂制度，而不是修理人。所以，經(jīng)常的情況下，動搖了制度的人不是犯錯的員工，而是管理者自己。如果在制度面前，既做得到“人性3化”，又做得到“公平性”，那么當管理者的便可以多做幾次黑臉的包龍圖，而脖子上的腦袋便可以比李離頂?shù)瞄L久一些。那我們就開始開發(fā)吧現(xiàn)在，公司的組織機構(gòu)和制度建設(shè)已經(jīng)完成①了，在這個組織機構(gòu)里，我們已經(jīng)有了一個或者多個團隊。接下來，我們要真正的開始團隊建設(shè)了。這是任務。因為正在讀書的你，和我一樣，是要拉齊七八桿槍，開始做工程的了。而在這一切開始之前，再之前的時間里，我還想知道一件事：你知道如何做工程嗎？我們先來回顧一下。前一章說的是編程，EN，那實在簡單，愚的工作。我們先不管愚公們的水平如何，以及夠不夠勤快，反正，他們會編程就是了。上一章呢，說的是一部分懶人“創(chuàng)造”或“尋找”到一些編程的方法。這些懶人們可能來源于做得太老的、或者太累的愚公，或者是??一些看著愚公們著急，又被閑出毛病了人。反正他們找了一些方法出來，而我們的愚公們也已經(jīng)學會了這些方法?，F(xiàn)在，有了會(比較快速地)編程的愚公，而且有了公司，我們完成了組織機構(gòu)建設(shè)，我們還找到了一名(或好①成，并不等于完善。而完美，則更是無可企及。多名)項目經(jīng)理他們一不二不怕苦??對了，更為可喜的是我們還有了開發(fā)部：對內(nèi)，我們訂了一套規(guī)章制度；對外，我們還拿到了項目?！昂芫靡郧?，很久很久以前，人們都是這樣做的。拿到項目，然后“那我們就開始開發(fā)吧”。這樣的事出現(xiàn)得很自然，因為積極的愚公們總是有挖山不止的。所以他們一看到項目，第一個反應就是：那我們就開始開發(fā)吧。組織的學問：角色現(xiàn)在先一下你的公司，在整個系統(tǒng)里面，有沒有這樣的人：他既不歸任何人管理，也不管理任何的他人。如果有，那么就早早地把他開掉好了。這樣的人在組織機構(gòu)中是一個盲點，或者空洞。按照我的觀點來看，他在組織中不擔任任何的角色，既然“不是角色”，那么當然要開掉。在任何錯誤被歸咎于員工之前，管理者應該先想想是不是自己的問題。是的。你可能很快發(fā)現(xiàn)問題出在了管理者。因為管理者沒有確定組織機構(gòu)模式，或者沒有為組織中的成員進行3角色定位和分工。如果這樣，出現(xiàn)“既不能令，又不受命”的人就是必然的事了。同樣的道理，在工程開始“做”之前就得先把“角色”確定好?！赡懿糠纸巧墙M織機構(gòu)相關(guān)的，例如“部門經(jīng)理”和“開發(fā)人員”；而有些就需要臨時授命。對于一個項目來說，第一個授命的人的當然是“項目經(jīng)理”。接下來的就復雜得多了。按照微軟的慣例，授命項目經(jīng)理的同時，會有“產(chǎn)品經(jīng)理”、“開發(fā)經(jīng)理”、“市場經(jīng)理”以及“文檔化和培訓。這當然不表明至少需要5個人才能構(gòu)成團隊，在大量角色從項目團隊中抽取與剝離后，我們可以得到一個精減的團隊模型①（在后面我會把它叫“R模型①我非常不情愿給出一個模型來讓讀者跟隨，但如果沒有這樣的一個模型，接下來的講述可能會令很多人如墜霧里。明確的組織機構(gòu)，既是團隊的關(guān)鍵，也是我們思考問題的基礎(chǔ)。②我試圖找一個單詞來表現(xiàn)這個模型的簡單和粗糙。我得到的一個建議是Rough(粗糙的)。然而我更愿意溯源到這個單詞在古英語中的形態(tài)(Ruh)，希望我這樣一再強調(diào)，能讓你真正地注意到：“R模型”是一個原始而且粗糙的東西。品質(zhì)部品質(zhì)部 文檔和培訓部門開發(fā)團隊開發(fā)經(jīng)理開發(fā)人員項目經(jīng)理市場部門更上層管理在保障這樣機構(gòu)模式的過程中，有幾點是需要注意的：如果項目針對直接客戶，而且沒有產(chǎn)品化的可能性(或必要性，那么可以將與市場以及市場部門)相關(guān)的問題和角色先暫時放在一邊。已經(jīng)存在于開發(fā)團隊中的成員，不適合在品質(zhì)部門中兼任角色。項目經(jīng)理應致力于減少團隊中開發(fā)角色與其它部門的溝通，必要時開發(fā)經(jīng)理應該站在開發(fā)人員之前進行部門間的交互。品質(zhì)部門、文檔和培訓部門和部門應該主要由有專門培訓的人員構(gòu)成，盡管開發(fā)人員可以(或者經(jīng)常會)參與文檔、培訓和工作，但這也通常是他們最不能勝任的角色。這是中小型規(guī)模的公司和團隊的參考組織機構(gòu)模型，對大型團隊并不適用。3在這個模型中，我們?nèi)匀豢吹搅艘粋€至少由三個人構(gòu)成團隊。其中，在開發(fā)經(jīng)理和開發(fā)人員之間，既存在主從關(guān)系，也存在協(xié)作關(guān)系。而項目經(jīng)理，則在團隊中處于領(lǐng)導者、組織者和團隊保障者的地位。如果非得要精簡到兩個角色的團隊模式，那么這種情況下，通常是開發(fā)經(jīng)理兼任項目經(jīng)理，因此這位開發(fā)經(jīng)理一定要能清楚地區(qū)分這種雙層角色的：在任何時候，明確自己是在進行“團隊內(nèi)協(xié)作”、還是“團隊管理(和組織)”、還是在與“團隊流”。如果這個開發(fā)經(jīng)理總是自己的角色，那么，我建議，吧。跟隨螞蟻。但不要栽進螞蟻洞里。團隊真的需要管理嗎？這經(jīng)常是“經(jīng)營”開發(fā)團隊的管理者最容易給錯答案的問題。這些管理者兢業(yè)，試圖細化每一個管理環(huán)節(jié)，將自己的意愿到??EN，CPU里去。實際上，開發(fā)團隊并不需管理?；蛘哒f，在你還沒有弄清楚狀況之前，不要去管它。溫伯格(GeraldM.Weinberg)在“給軟件開發(fā)經(jīng)理的建議”中提到了這樣一個問題：開發(fā)經(jīng)理如何面對一個并非由他親自雇傭成員的團隊。溫伯格的回答是：與成員面談，或者，解聘他們；再或者，放棄這個職位。溫伯格的意思是“沒辦法管就不管”。溫伯格當然可以有的選擇，他總可以找到適合自己管的公司。然而目前，你可能是唯一的人選?；蛘吣阍揪推诖@個角色很久了，當然不能象溫伯格一樣放棄。你得找辦法來解決團隊問題?！昂灱s”這樣的事，在大多數(shù)環(huán)境下是行不通的。要知道，既然他們與公司的簽約保證不了他們工作的質(zhì)量，同樣與你的這份簽約也不會。協(xié)議并不能建立管理者與被管理者的信任，而只是確保了這種關(guān)系。但是你應該相信我，在你接手這個團隊之前，上一任經(jīng)理也確保了這種關(guān)系。然而團隊失敗了，否則不會換作所以告訴團隊成員“現(xiàn)在輪到我管理了”，根本就是一句廢話?；蛘咴谀銇碇?，他們就已經(jīng)知道你要來了。小的時候，我就喜歡觀察螞蟻。我喜歡看它們成群結(jié)隊地搬著東西穿過小路，或者水溝。我嘗試用木棍導引它們改變行動的路線，然而不久之后，它們就會翻過那根木棍，按照既定的路線行進。稟性難移，要改變一個人都難，何況是改變一個團隊的既定習慣。如果有一群開發(fā)人員象螞蟻一 地工作著，3么，先不要打擾他們。你應該跟隨他們，看看他們是如何做的。發(fā)現(xiàn)規(guī)律，分析這個規(guī)律的價值，最后再嘗試改變它們(的一些價值的規(guī)律)。所以你要緊緊地跟隨他們?！艘粋€地方。那地方是你去不得的，那就是螞蟻洞。顯然，你不是開發(fā)者，你是管理人員。所以盡管你是團隊中的角色，但千萬記得離螞蟻洞遠點。你在洞外張望，可以發(fā)現(xiàn)問題；你在洞內(nèi)，就只有做“循規(guī)蹈矩”的螞蟻。管理者是那個可以在洞外放人8.“什么 現(xiàn)在你已經(jīng)足夠地觀察了你的團隊，你知道這個團隊存在問題，你也知道你需要改變。當然，你也知道這種改變并不是放一根木棍那么簡單。你已經(jīng)確定了組織結(jié)構(gòu)，確定了組織中的角色，還有了一個團隊(5個？或者10個？)的人。所以作為項目經(jīng)理，你需要先分工。在分工之前，那個團隊只能算是一個沒有組織與合作的群體所以英文中群是Group，而開發(fā)團隊是Team。被優(yōu)先考慮的是彈性分工。每一個人都被要求做一顆的螺絲釘，哪里需要哪里擰。所以彈性分工總是被放在企業(yè)節(jié)省人力資本的第一要務上。然而我們真的會做彈性分工嗎？螞蟻的分工模式之一就是彈性分工。一只螞蟻搬食物往回走時，碰到下一只螞蟻，會把食物交給它，自己再回頭；碰到上游的螞蟻時，將食物接過來，再交給下一只螞蟻。螞蟻要在哪個位置換手不一定，唯一固定的是起始點和目的地。確定被“彈性分工”的員工需要可以快速地轉(zhuǎn)換到新的角色，但首要的并不是他是否“有能力”勝任這個角色。能力可以通過學習來增強，而角色的轉(zhuǎn)換，則首先是思想的轉(zhuǎn)換。1997P&J的公司打算全面拓展市場，我隨他一起到了。當時我是開發(fā)部的三個主力開發(fā)人員之一，因此在原定計劃里，我是到組建西南區(qū)開發(fā)部(或技術(shù)中心)。然而在兩周之后，P&J發(fā)現(xiàn)總公司的運作存在問題，因此他必須回鄭州。P&J決定將市場的問題全權(quán)交給我，換而言之，我必須出任辦事處經(jīng)理。我對市場一竅不通，也不懂得公司的經(jīng)營與管理。但很明顯，做辦事處經(jīng)理不是做技術(shù)，這與我(當時的)個人意愿是相背的。于是我拒而不受。理由也很充分：我不會做市場。P&J用了兩天的時間來說服我，直到在臨回鄭州的前一晚我仍未能接受這個任命。這時他告訴我：即使是做開發(fā)，也是需要了解市場的，你必須知道用戶想要什么，你必須理解你的客戶。因此你如果想要做一個好的開發(fā)人3員，你應該正視這次機會。我沉默了許久。明白了兩件事：從公司的角度上，我必須接受這個職務；從個人的角度上，我需要接受這個職務。于是，我問了我的第一個問題：“什么是發(fā)P&J笑了。接下來我們開始討論經(jīng)營問題。第二天P&J飛回鄭州。五個月后我升任西南區(qū)總經(jīng)理，一年后，西南區(qū)做到六個分區(qū)市場績第二。此后我辭職回到鄭州，再一次從開發(fā)人員做起?！笆裁词?？”意味著從技術(shù)到經(jīng)營的角色轉(zhuǎn)變。這個問題本身帶來的并不是能力的提升，但如果我提不出這個問題，我將沒有可能理解經(jīng)營與市場。盡管彈性分工非常有效，然而真正做彈性分工卻并非易事。螞蟻的角色轉(zhuǎn)換是本能的，而P&J卻不得不花兩天時間來說服我。因而更應當留意團隊成員“自激”式的角色轉(zhuǎn)換，知道他是不是真的想(而不是需要)轉(zhuǎn)變一下角色，這樣起碼可以省去你兩天的功夫。然而能提問“什么是 ”的愚公畢竟不是太多，大多數(shù)時候他們在“箕畚運于渤海之尾”，如果實在閑得厲害，他們可能會去發(fā)明翅膀，而不是思考“什么更好的選擇是明確分工，而不是彈性分工。你應該明白，重要角色的更替通常是極具風險的，例如項目經(jīng)理或者開發(fā)經(jīng)理；頻繁的開發(fā)人員的調(diào)度也會直接影響到工程的質(zhì)量和進度。如果所有人都在思考“什么是 ”，那么你的組織機構(gòu)將立散。因此，明確分工是你的管理職責。做管理≠做伯樂。第4章流于形式的溝通“足下求速化，不于其人，乃以訪愈，是所謂借聽于聾，求道于盲?！薄啤ろn愈《答客戶不會用CUML嗎我們總是要先接觸客戶的，是的，如果不這樣，我們將無法確知要做什么。作為開發(fā)人員，可能更希望客戶能學習或者精通C語言，這樣客戶就知道開發(fā)人員正在做什么，以及有多么地勤勞?；蛘?，這樣的客戶還能以C語言的方式告訴開發(fā)人員他們究竟想要什么。然而要求客戶學習C語言明顯是式的行為。在客戶(的代表)學會用C語言來向開發(fā)人員描述他們的需求之前，可能他就已經(jīng)被開掉了。因此沒有客戶會笨到愿意用C語言來描述他們的需求。C語言是程序員與計算機交流的語言，而不是他與客戶交流的語言。程序員面對的是計算機，但計算機不是客戶。因此面所提到的R模型中，開發(fā)人員最好不直接面對客戶。項目經(jīng)理有這樣的一種優(yōu)勢：他可以不用了解C語言，也可以用一種非C的語言來與客戶交流(比如說漢語)?！蛘吣愀敢忾_發(fā)人員盡早地進入狀態(tài)，那么你可以讓開發(fā)人員以需求調(diào)研的出現(xiàn)在客戶面前。但是，請注意這個人員的角色將變成“需求調(diào)研”，如果他不能適應這種轉(zhuǎn)變，那就別讓他去?！菚堑拈_始。要深入項目的需求階段的項目經(jīng)理或者調(diào)研人員，被要求深諳項目所涉的業(yè)務。但這往往我們所做不到的，因為我們是軟件公司，而不是做這些(客戶的)業(yè)務的公司。這時慣常的做法是聘請行業(yè)咨詢公司或者個人來介入需求階段，協(xié)助了解和分析需求。他們總是很喜歡把事情搞得很復雜，所以他們會說這一切的過程有個名詞，“En...這叫需求建?！彼麄兒軐I(yè)地說。現(xiàn)在你應該發(fā)現(xiàn)了差距。比如我們的項目經(jīng)理，以及那個被調(diào)來充當調(diào)研角色的程序員，他們就不會什么“需接下來咨詢公司會與我們的客戶一起做業(yè)務建模，然后再做業(yè)務到需求的映射，再抽取需求并完成需求建模。他們做業(yè)務建模的時候，可能使用一些客戶業(yè)務范疇內(nèi)的符號和標識；而在做需求建模時，則需要使用一些軟件行4業(yè)中(的設(shè)計和分析人員)習慣的符號和標識。這些符號和標識也有個名稱，“En...這個叫模型語言(ML)?！彼麄儫o時無刻不在向你展現(xiàn)他們的專業(yè)(這已經(jīng)是他們還存在的唯一原因了)。如果他們更加專業(yè)，他們會告訴你他們用的是UML。向你介紹這個名詞的時候，他們的眼鏡或者眼睛里通常將大放異彩。UML是模型世界里的世界語①到現(xiàn)在為止，你應該看到，咨詢公司除了把問題搞得更加復雜之外，他們?nèi)匀恍枰鎸ψ钪苯拥膯栴}：與客戶如何交流？他們的解決之道是模型語言。有什么差別嗎？程序員不能要求客戶會CLanguage，難道需求分析師們就能要求客戶會ModelingLanguage嗎？！項目文檔真的可以用甲骨文來寫獨孤 曾經(jīng)在一《UML,OOADandRUPUML實際應用中的問題。其中的兩個問題是：①現(xiàn)實的情況未必如此。但UML這個名詞起碼顯示了它本源性的期望：UnifiedModelingLanguage(統(tǒng)一模型語言)?！按蟛糠值氖褂谜?，以及客戶的信息人員，其實并沒有足夠的能力，來確認這些文件(UserCase)UML，OOADRUP以外，另外一個更糟糕的現(xiàn)象就是projectteam里面這實在是很有趣的事?？磥碓谝恍┣闆r下，在項目中UML只是完全不懂的，以及什么都懂的博士的主意，而真實的場景中去做事的那些客戶與項目成員，其實是未見得就能用好UML的。僅以UML的UserCase來說，由“用例圖”和“用例規(guī)約”組成。規(guī)約跟我們寫的需求說明書差不多，不過更加細節(jié)罷了，而且還有一套相應的方法論來闡述如果去實作。圖則很簡單，就是幾個圖形符號來描述系統(tǒng)邊界和角色關(guān)系。顯然甲骨文也能描述范圍與關(guān)系。例如甲骨文中的“家”這個字，就是上有房子下有豬①，這個邊界就定義得很好在古文中，“三”通常是泛指，UML圖中的線條上標注的那個“*”是同義的，而甲骨文中“眾”這個①至于是“內(nèi)有豬”還是“下有豬”的問題，不是我們要爭論的。有些考古學家根據(jù)甲骨文的象形來認為古人與家豬是雜居的，但那時的豬可能還比較野性，因此這種可能性還是小些。4字，就是日字下立有三個人，也就是在同一個日頭下做事的很多人即為“眾”，這個關(guān)系也描述得很確切。所以只要你運用得法，甲骨文一樣可以用來畫用例圖和寫用例規(guī)約。同只要約定一套“語法”，你同樣可以用甲骨文來做活動圖、類圖、構(gòu)件圖??以及這些圖相關(guān)的規(guī)約。相比來說，古巴比倫人使用的楔形文字“象形性”差一些，因此我不建議用它來畫用例圖。既然甲骨文可以用來做為一種模型語言(同時它也是一種文字和口頭的語言)，那么，如果你的項目中面對的對象是商周文化的考古學家，以及你的項目組都由精通這種語言的成員構(gòu)成，這時你就可以用甲骨文來做項目文檔，以及畫各種模型圖例。你要明白，要讓考古學家看懂用例圖，難度遠大于看懂甲骨文。與其要求他們學一種語言，不如使用他們那個世界的通用語(當然，前提你的項目組也懂得這種語言)所以說是“求道于盲”。然而他用了一個不恰當?shù)谋扔鳎阂烂と瞬⒎遣恢缆啡绾巫?，只是他不能象常人一樣描述他所知道的路。因此“問道于盲”是沒有錯誤的，真正錯誤的是你睜著眼睛問。我們需要在正常人與盲人之間建立一種溝通的方式，既然盲人不能睜開眼睛，那么你就閉上眼睛好了。UML圖在一些客戶眼里無異于盲人的世界，如果需要向他們做需求調(diào)研，你只能使用一種這些客戶能夠理解和接受的方式，例如表格、流程圖以及??更深入的交談。你要確認你的溝通方式是否有效，而不是去追求這種方式是不是UML，以及用UML表達得是否正確?！蛻羰且驗樗J為你理解了他們的需求，而在“需求確認書”上簽字，而不是因為你的UML畫得是否精準。現(xiàn)在來思考：為什么非要讓客戶看UML圖呢？如果有能夠滿足“極限編程(XP)”所要求的“現(xiàn)場客戶”，那當然可以不畫用例圖；相反，如果客戶雇了一個專家組來評審需求，那么你就老老實實地畫用例圖好了。需要留意的是，專家組還要式與客戶溝通，這有可能不是UML?！斎?，客戶愿意增加溝通成本，那是他們的事。一旦確定，你就可以接下來約定在項目組中要使用的溝愚公——這個偉大的項目經(jīng)理——所使用的“聚室而謀曰”，就是很好的溝通方式。當然，如果客戶精通UML，那么愚公采用的項目溝通方式將會是“聚室而論UML”。一定會這樣，因為愚公是很懂得溝通的、偉大的項目經(jīng)理。①這是極限編程的特征之一，指的是要求客戶可以在程序員開發(fā)的第一現(xiàn)場，隨時可以向程序員確認完成功能的有效性，以及修正需求或者先前的需求描述。4最簡溝D項目中，我向我的項目組員提出在需求階段與客戶的溝通計劃。這個計劃只有三條：在一個月中，三次聯(lián)系中，一個月后，提交全部的需求調(diào)研報告、需求分析和關(guān)于該項目的遠景規(guī)劃。D項目并不大，所以從上來講，客戶(代表)并不會為這個項目投入太多的精力。重要的是，我們期中已經(jīng)發(fā)現(xiàn)：這個客戶代表為大量其它的項目和工作所困擾，他不會有時間來處理我們的問題。因此，減少溝通和保障溝通質(zhì)量的問題就顯得非常突出。在大多數(shù)的項目中，這樣的問題都是存在的。真正能滿足極限編程(XP)所“現(xiàn)場客戶”的情形并不經(jīng)常出現(xiàn)。即使能將程序員送到客戶現(xiàn)場中去，溝通問題仍然是不可避免的。因此在D項目中我提出了“最簡溝通”。我們開始在網(wǎng)絡上查看相關(guān)的軟件系統(tǒng)的特征以抽取客戶所關(guān)注的內(nèi)容；了解該客戶的公司、、組織結(jié)構(gòu)形式以及工作模式；了解同類公司的成功經(jīng)驗和優(yōu)秀的管理模式，以及客戶的競爭對手在做什么和在關(guān)心什最后，我們開始綜合以下兩個方面的因素：客戶在公司層面的外在表現(xiàn)、內(nèi)部機制和運營管理?？蛻粼陧椖恐屑纫衙鞔_的需求和可能發(fā)生的需求，以及客戶圍繞其公司行為(和方向)所這樣我們就了解了客戶項目中所有會產(chǎn)生需求的信我們開始設(shè)計提問，每一個提問涵蓋盡可能多的信息點，盡可能的具有發(fā)散性以便形成的推論和假設(shè)。我們把這些做成項目概要用mail提交給客戶，并在第二天回訪他。他以口頭的形式回復了這封mail，這讓我們盡可能地得到了項目在方向上修正。我們確定了項目的實際目標，以及遠期的方向。接下來就是設(shè)計需求條目?？蛻粢呀?jīng)先期提供了一些關(guān)于項目的文檔、報表和工作數(shù)據(jù)。因此基于這些數(shù)據(jù)的需求分析，將是下一個溝通前所進行的最堅苦的工作。項目組員被要求：分析用戶的每一個表格，分析每一條數(shù)據(jù)的含義以確定它的上下限，以及數(shù)據(jù)間的相關(guān)性；從工作文檔中去了解客戶的組織機構(gòu)及其相互關(guān)系，同時確定了每一類使用該系統(tǒng)的角色；從報表中去了解客戶關(guān)注的數(shù)據(jù)信息，以及被他們所忽略掉的數(shù)據(jù)信息。我們從數(shù)百條的需求條目中，整理出系統(tǒng)結(jié)構(gòu)和模4塊，需求條目被映射到各個模塊。我們很快畫出了模塊間的相互關(guān)系圖，并通過這個圖分析了數(shù)據(jù)交叉關(guān)系，設(shè)計了相應的數(shù)據(jù)索引并增加了一些新的關(guān)系性數(shù)據(jù)。我們對用戶角色、原始數(shù)據(jù)和系統(tǒng)結(jié)構(gòu)進行了梳理之后，我們花了很短的時間實現(xiàn)了第一個系統(tǒng)模型。當然，很多的功能項目，我們都只是簡單sowadialog。但我們優(yōu)化了每一個操作流程，以保證不同的用戶(角色)在使用時都盡可能流暢。這一次的溝通我們使用了面對面的模式。我們很慶幸的得到了與這個系統(tǒng)的每一類用戶(角色)接觸的機會，而正好我們有一個模型，我們便讓他們來操作并提出意見。這一次我們終于有了一份詳盡的的調(diào)研報告。接下來的分析設(shè)計是順理成章的事。我們在一個月后完成了這個項目的需求分析報告，以及在這個分析上的一些框架型的設(shè)計。還有，一個被用戶所接受的原始模型。——盡管，第三次的溝通中還發(fā)現(xiàn)了一些問題。但我們終于有了一個好的開端。應該清楚的是，保障每一次溝通的有效性都是最重要的事。溝通不是打或者請客戶吃飯那么簡單的事。你得到的每一次溝通機會，都是向客戶了解更次的需求的機會，因此最好在見到客戶之前，你就已經(jīng)設(shè)計了所有的問題和提問方式。吃飯并不是有效的溝通。大多數(shù)時候，那將以酒醉收場。為不存在的角色留下溝通的大多數(shù)人不會知道，我們中國的“五千年文明史”實際上僅有三千年“有史可查”。司馬遷在史記：“維三代尚矣，年紀不可考，??于是略推，作三代世表。也就是說，他在寫史記時“(夏商周)三代”的年代已經(jīng)不可考了，因此只能做世表”；而其后十二諸候國的年代才可考(十二諸侯)年表”。世表和年表的準確性和可靠性有明顯的差異，因此我國古代編年史能追溯到的上限，就成了《史記·十二諸侯年表》中記載的西周共和元年，亦即公元前841年。司馬遷無法做夏商周三代的年表是因為其年代不可4考，這是因為自黃帝以來的許多文獻材料部分雖有年數(shù)，但比較模糊且不一致，所以他只能棄而不用?，F(xiàn)在國家在“夏商周工程”中再次推算和考證編年史，這些相關(guān)資料也同樣只做參考，實際采用的方法是更有可信度的金文(記載)、歷史學、天文學、碳-14測年等。資料的缺失、及其有效性的缺乏，給中國編年史撰寫帶來了莫大的。項目的中斷和中止，與歷史產(chǎn)生斷層的內(nèi)因是一致的?！野l(fā)現(xiàn)很多的項目(尤其是產(chǎn)品計劃)在員離開后，就自然而然地死掉了。我把這一切的原因歸咎于“沒有history”。在先人寫“譜牒”(簡、冊)時想必是沒有考慮過后人要讀的，或者更為遠古的先人可能根本沒想過要留下他們的生活和部落記錄，再加上有象秦始皇這樣的人面放火燒東西，所以司馬遷拿不到夏商周三代的確切史料，也是情理之中的事了?！h古的先人不知道司馬遷這一號角色的存在，司馬遷也沒有辦法跟古人約定一下要留點記錄給他寫《史我們做項目的時候，如果也不留下歷史記錄(History)，那么以后別人來看這個項目，也會是兩眼一抹黑，要么就象司馬遷一樣“存而不論”，項目便就此中止；要么就象“夏商周工程”一樣，花大量的人力物力來舊項目比做新項目更難，許多人深有同感。然而這些“有同感”的人又何曾想過，自己在做“新項目”的時候，要為“項目”這種還不存在的角色，留下一個溝道、的呢？我把項目的History作為跟這存在的角通的式。History的豐富和準確為項目的后繼開發(fā)、提供了可能。歷史記錄(History)與注釋(Comment)不是一回事。代碼中的注釋是為閱讀代碼而留備的，而History是為整個項目而記錄的。一些參考的記錄內(nèi)容有：需求階段：與誰聯(lián)系，、過程、結(jié)果以及由此的需求或變更；設(shè)計階段：如何進行設(shè)計、最初的構(gòu)架、各個階段的框架變化、因需求變更導致項目結(jié)構(gòu)上的變化(有助于了解構(gòu)架的可擴充性)；開發(fā)階段：每一種技術(shù)選型的過程、每一種開發(fā)技巧的細節(jié)和相關(guān)文檔、摘引的每一段代碼、算法、開發(fā)包、組件庫的出處和評測；程序單元的測試框架每一個設(shè)計和構(gòu)架變更所導致的影響；測試階段：還記得測試用例和測試報告嗎？那是最好的history之一。4當然，另一件最重要的事，是記得在每一筆記錄后寫下時間和你的名字。你的每一筆記錄都是打算留給一些根本不了解這個項目的人看的，之所以要記下你的名字，是便于那些人能夠再找到你并溯源到問題的?！斎?，這得趕在你和古人一樣“與天地共存”之前。我們知道，大多數(shù)的工具都有歷史記錄的功能。在開發(fā)工具和測試工具中尤為突出。此外，版本管理工具也留下了每個階段的印跡。然而，我不建議過于信任它們①，如果不明確要求項目組員寫下詳細的History，那么他們可能在每一次版本簽入時都只寫下兩個字的備注：“完成流于形式的溝通在很多的時候，我所聽到的溝通，都是一種形式。例如與客戶吃飯或者打回訪。其實溝通是具有目的性的，如果在沒有明確目的的情況下與客戶溝通，那將是浪費客戶和自己的時間。這種目是交流感情。然而大多數(shù)的情況下，它僅僅被看著交流感情。這便①大多數(shù)的軟件公司已經(jīng)版本管理的重要性。然而項目各個階段的文檔、代碼及其它輸入輸出都是具有版本問題的。單一的版本管理軟件并不能勝任這些。因此我仍舊采用相對原始的、編寫History這樣的方法，來彌補ClearCase、SourceSafe、CVS等這些軟件的不足。成了形式。且往往是客戶所討厭的一種形式。溝通問題不僅僅存在與客戶交流之中。還存在于與項目的各個角色之間。項目的分析報告為設(shè)計人員所看不懂，設(shè)計人員的方案為開發(fā)人員所看不懂，而開發(fā)的結(jié)果以為測試人員所看不通。等等都是溝通問題。UML的確是解決溝通問題的最佳之一。然而如果項目一開始就不能用它，那么強求的結(jié)果必然是痛苦UML在一個沒有經(jīng)過相關(guān)培訓的團隊及其也存在經(jīng)驗問題。千萬不要指望僅僅一個項目，就能讓你的組員深刻的理解UML的思想。也不要指望在每個項目中都能用它，如果你的客戶能理解并支持使用UML，那以這個項目就會有一個良好的UML使用環(huán)境。否則發(fā)環(huán)節(jié)中資料的不一致性會使得項目難以收場。使用與不使用UML，其根本的問題在于溝通方式的選擇。只要是行之有效的、能在各個項目角色間通用的，就是好的溝通方式。在每一次回顧項目時都應該注意：流于形式的溝通，可能是使得你的項目被不斷和不斷延遲的最直接原因。4第5章失敗的過程也是過程——《明皇做過程不是做工軟件工程這個概念被時候大概是在上個世紀60年代末。它作為成概念的標志是軟件工程的瀑布計、開發(fā)和測試等5個主要階段，其主要環(huán)節(jié)關(guān)系表現(xiàn)為如下的這樣一種形態(tài)：在瀑布模型之后，很多人開始研究過程模型的問題。很多從實際工程中提煉出來的過程模型都是值得稱道的，5例如RAD(快速應用開發(fā))模型、螺旋模型和現(xiàn)在常被提及的RUP模型。模型就是“樣子”。人家拿出一個東西來說：這是模型。其言下之意就是要你按照這個樣子來做。然而正如下在這張圖所展示的：按照模型的這個“樣子”，做完過程的每一個階段，并不等于做工程?；蛘哒f，工程并不是這樣就可以做成功的。換而言之，無論是用RAD模型還是RUP模型來做工程，即使是亦步亦趨，也做不好工程。如果工程可以那樣做成的話，只需要有瀑布模型就足夠了。因此做過程并不是做工程的精義。也不是目的。做過為什么會存在這樣的問題呢？有句地方話叫“做過場”，也有說成“走過場”的?！斑^場”是舞臺術(shù)語，意思是角色從舞臺一端出場，再走到另一端進場的一個過程。過場角色一般沒有唱腔或道白，即便是有，也是沒有什么實質(zhì)內(nèi)容的。前面那張圖就是一個過場。盡管那是一張用來描述“溝通問題”的經(jīng)典圖例，然而你應該注意到，每一個角色都把自己的環(huán)節(jié)當成一個“過場”。如同演戲一樣，從A做到Z，就一切都完成了。當然，按照RUP的思想，是要從A到Z一遍又一遍地做下去的。然而，如果每一遍(或者用RUP的那個術(shù)語“迭代”)都只是“過場”的話，項目將是一場無休止的演出而已。就散伙。戲目和項目的結(jié)局，竟如此地相似。實現(xiàn)，才是目的很多人把問題的本質(zhì)給忘掉了。從最開始，從我們編程開始，我們的目的就是實現(xiàn)一個東西。無論這個東西是小到一個稱手的工具，還是一個大到千萬的工程，我們的5目標，都是要“實現(xiàn)”它。工程只是一種實現(xiàn)的途徑。最初做開發(fā)的前輩們，不用什么工程或者過程，也一樣編出了程序，也一樣解決了問題，也一樣實現(xiàn)了目的。而現(xiàn)如今，我們講工程了，講過程了，講方法了，卻什么都再也做不出來了。不奇怪么？工程被當成了借口，掩蓋了我們做事的真正目的現(xiàn)”。因此，我們在一個項目中常常聽到說“工程要這樣做”，或者“工程要那樣做”，而絕少聽到“項目要求這樣這樣的結(jié)果是：我們做完了工程(的每一個過程)，卻沒有完成項目(的每一個“實現(xiàn)目標”)。為工程而工程的人，都迷失在項目中了。就象開發(fā)人員迷失在一個技術(shù)的細節(jié)上一樣。專注于RUP或者RAD之間的區(qū)別的人，可以把每一個過程的流程圖都畫出來，卻也被這每一個流程給得死死的，再也沒有掙扎一下的力氣。過程不是死模型試著跳出大師們的身影，再仔細地看一下那些所謂的“經(jīng)典”過程，不過是在瀑布模型上的一再變形。瀑布模型描述了開發(fā)的主要環(huán)節(jié)，于是一群人把這些環(huán)節(jié)擰來扭去或者反復迭加，就成了RAD、螺旋、RUP，以及未知的、還沒有被扭出來或者堆疊出來的X、Y、Z。2002年前后，我在CSDN中看到一個漂洋過海東渡扶桑的取經(jīng)人，貼出了一個被稱為“IT工業(yè)發(fā)展史的”牛人指點的，足以令人震聾發(fā)饋的“V字這個模型是這樣：\ /\ / \/詳細設(shè) \/我看后就很不以為然。為什么呢？你看，你把V模型拉直了，還不就是瀑布模型嗎？\\\\5如果僅僅是這樣看問題，《韓非子·外儲說左上》記載了“買櫝還珠”的故事：“楚人有賣其珠于鄭者，為木蘭之柜，熏以桂椒，綴以珠玉，飾以玫瑰，輯以羽翠。鄭人買其櫝而還其珠。”鄭人就只看到了事物的表面，而忽略了實質(zhì)的東西。如果我們只是把V模型當成折彎了的瀑布，那便是犯了相同的錯誤。因此，我們應該去思考由瀑布模型到V模型這種變化的真實意圖。V模型在每一個環(huán)節(jié)中都強調(diào)了測試(并提供了測試的依據(jù))，同時又在每一個環(huán)節(jié)都對實現(xiàn)者和測試者的分離。由于測試者相對于實現(xiàn)者是一種監(jiān)督、和評審的關(guān)系，因此它相當于在不斷地做回顧和確認。這有什么意義呢你把它放在一個工程外包的背景里去考慮就明白了。由于近年來化嚴重，因此勞動力短缺導致的勞工輸入和項目外包，直接影了它的組織管理模式。無論是在本國雇傭外來勞工，還是將項目直接外包給國外的開發(fā)團隊，項目成果的階段性都是他們的第一要務，這直接決定了何時、如何，以及由進入下一個環(huán)節(jié)。因此V模型變得比其它模型更為實用。模型的左端是外包給的團隊或者公司，而右端則是軟件企業(yè)中有豐富經(jīng)驗的工程人員。這樣既節(jié)省人力，又可以保障工程質(zhì)量。事實上，即使左端外包方是由多個團隊同時承接，右邊的工程人員也不需要的投入。相對于瀑布模型V模型有改變了什么嗎？是的。源于實際的需要，它把測試(和評審)階段抽取出來，于是就成了V模型。那么，如果需要，為什么不能把瀑布模型變成W模型，或者M模型呢？為什么就一定要跟隨那個以迭代為基礎(chǔ)的RUP模型呢？更進一步想，如果瀑布可以變成V、W和M，為什么它不能更關(guān)注于其中某個具體的環(huán)節(jié)(例如實現(xiàn)和設(shè)計環(huán)節(jié))在這些環(huán)節(jié)上引RUP的思想，哈哈，你看看，是不是出現(xiàn)了勛章模型和煙斗模型？然而你要知道，過程模型是在既有工程中總結(jié)出來就已經(jīng)被一些團隊或者公司創(chuàng)生并使用了。過程理論的團隊或者公司呢？刻鵠類東漢時期，伏波將軍馬援在南征交趾期間寫過一封著名的家書，是教導兩個“喜譏議而通輕俠客”的侄兒的，希望他們學習敦厚謹慎的龍伯高，不要仿效豪俠仗義的杜5。龍伯高時任越騎司馬，杜時任山都長，都是馬援所“愛之重之”的人。然而馬援告誡兩個侄兒說：“效伯高不得，猶為謹敕之士，所謂刻鵠不成尚類鶩者也。效季良不得，陷為天下輕薄子，所謂畫虎不成反類狗者也。”于是，伯高、因馬援家書而名留史冊，“刻鵠類鶩”和“畫虎類犬”就此成為典故。這意思便是說，雕刻天鵝不成，總還可以像只鴨子(鶩)；若畫虎不成反而像條狗，那就事與愿違，貽人笑柄了。后來的后來，近代作家朱湘就了這個典故，寫了鼠的老前輩便是這樣警勸后生：學老杜罷，千萬不要學李太白。因為老杜學不成，你至少還有個架子；學不成李的時候，你簡直一無所有。這學的風氣一盛，便從此不再出現(xiàn)于中國詩壇之上了。所有的只是一些杜的架子，或一些《畫虎》這篇文章真的是好，真是建議大家讀讀。其中畫師與畫匠之論，精妙深徹，痛指骨質(zhì)。而后論及，“國家中的畫匠”幾個字便打發(fā)了。大師的眼光果然獨到。然而朱老先生反駁馬援所說的“刻鵠強于畫虎”，卻有什么關(guān)系呢？馬援說刻成鴨子比畫成狗好，其真實的意思是說學龍伯高不成，可得“謹敕”；學杜不成，則會流于“輕。馬援比較的是二者在骨子里所得所失的東西而不是架子上的象與不象。同樣，以得失而論，在瀑布模型與RUP模型之間，學習前者而不成，可思過程的本質(zhì)；學習后者而不成，可得文字的架子。——用RUP用不好的人，總會說自己終歸還有一堆文檔模板可以抄，便是這個緣故。過程理論中，如果懂得了所謂的模型原本都演化自那個簡單的瀑布，那么文檔是按XP寫還是按RUP寫，也就可以應時、應需，因地置宜，擇善而從了。——本質(zhì)的東西若能理解得透，架子還不是隨手搬來就可以用的嗎？越是簡單的東西，往往越是接近于本質(zhì)。RUP中，真正精髓的東西，既不是那個R(Rational)，那是人家的招牌；也不是那個U(Unified)，那是人家的廣告。而是那個P(Process)，那才是實實在在的東西。你要明白，如果瀑布模型理論是Rational，他們一樣會把它叫RUP。朱湘說：“畫不成的，真像狗；刻不成的鴻鵠，真像鶩嗎？不然，不然。成功了便是虎同鵠，不成功時便5馬援說：“學龍伯高，即使達不到他的水平，總還能成為一個謹慎的人；而學杜如果學不到家，便會淪為你到底是選擇架子？還是骨子？工程不是做的，是組織的我們總是在說“做工程”，好象工程就是面包饅頭一樣，有個模子，拿來照著一堆面按上一按，放在籠屜上蒸上一蒸，就可以“做”出來了。經(jīng)歷過工程的人都知道，我們沒有那個模子，而工程中的人員也不是那一堆面。所以我們當然不能“做”工程，“組織”工程。項目經(jīng)理的工作，就是要去組織這個工程中的各個角色，使得分工明確，步調(diào)一致，共同地完成這個項目。第6章從編程到工程“得其精而忘其粗，在其內(nèi)而忘其外；見其所見，不見其所不見，視其所視，而遺其所不視。”——《列子·語言只是工具我曾經(jīng)是非常執(zhí)著的開發(fā)人員。我有連續(xù)幾天幾夜做Coding的經(jīng)歷，也曾經(jīng)為了一個技術(shù)問題耗上三、四個星期而導致項目一再延遲，還曾經(jīng)為了一個實現(xiàn)細節(jié)與項目相關(guān)的人員逐一爭論。我也曾經(jīng)象大多數(shù)的開發(fā)人員一樣熱衷于爭論語言之間孰優(yōu)孰劣。我在“Delphi大富翁”上寫過一個簡介，其中個人特長是“長TPascal、Delphi、TASM系列語C/C++。(凡見有價值之C代碼，先讀通，后寫成Pascal/Delphi最后罵一句C寫得真笨！”。我至今保留這段文字，因為那的確是真實的經(jīng)歷。如今我已經(jīng)不再專注于語言，正如我在第一章中寫到的一樣：成天討論這門語言好，或者那門語言壞的人，甚至是可悲的。6《Delphi源代碼分析》，我還是無盡止地深入語言的細節(jié)，深入操作系統(tǒng)的細節(jié)，以及深入??開發(fā)的細節(jié)。就在2004年3月間，我接受一個朋友的邀請，去北京做一個名為“Delphi&DephiNET源碼分析”的專題培訓。我用了近兩周的時間，做了50頁的幻燈，全面講述DelphiDelphiNET。然而在臨行前的一晚，我輾轉(zhuǎn)反徹，總是在思考一個問題：我究竟做了些什么？或者說，我究竟想告訴學員些什么？5點，我在幻燈的末頁后插入了一張幻燈，標題是“語言只是工具”，而幻燈的內(nèi)容是一張圖：這是與培訓完全無關(guān)的一張幻燈。然而，這是自從1997年我接觸到管理，以及從1998年我接觸到工程以來，我第一次正視“軟件工程”這。我第一次看清楚代碼、方法、過程、工程與組織的關(guān)系！對于一個程序員，或者以程序員自命的人來說，看清楚這一切的第一步，竟是一句“語言只是工具”！猿之于為人，“學會制作和使用工具”是最重要的標志。因而我不知道“語言只是工具”這句話，究竟是對語言的膜拜，還是漠視。程上面的這個圖中，在最內(nèi)層的