大道至簡(jiǎn)軟件工程實(shí)踐者的思想

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