“得其精而忘其粗，在其內(nèi)而忘其外；見(jiàn)其所見(jiàn)，不見(jiàn)其所不見(jiàn)，視其所視，而遺其所不視”——《列子 說(shuō)符》

1. 語(yǔ)言只是工具

我曾經(jīng)是非常執(zhí)著的開(kāi)發(fā)人員。我有連續(xù)幾天幾夜做Coding的經(jīng)歷，也曾經(jīng)為了一個(gè)技術(shù)問(wèn)題耗上三、四個(gè)星期而導(dǎo)致項(xiàng)目一再延遲，還曾經(jīng)為了一個(gè)實(shí)現(xiàn)細(xì)節(jié)與項(xiàng)目相關(guān)的人員逐一爭(zhēng)論。

我也曾經(jīng)像大多數(shù)開(kāi)發(fā)人員一樣熱衷于爭(zhēng)論語(yǔ)言之間孰優(yōu)孰劣。我在“Delphi大富翁論壇”上寫(xiě)過(guò)一個(gè)簡(jiǎn)介，其中個(gè)人特長(zhǎng)是“擅長(zhǎng)TPascal、Delphi、TASM系列語(yǔ)言，痛恨C/C++”。我至今保留這段文字，因?yàn)槟堑拇_是真實(shí)的經(jīng)歷。

如今我已經(jīng)不再專(zhuān)注于語(yǔ)言，正如我在第一章中寫(xiě)到的一樣：成天討論這門(mén)語(yǔ)言好，或者那門(mén)語(yǔ)言不好的人，是可悲的。

然而就在我寫(xiě)這段文字之前的一年，我還在寫(xiě)《Delphi源代碼分析》，我還是無(wú)止盡地深入語(yǔ)言細(xì)節(jié)，深入操作系統(tǒng)細(xì)節(jié)，以及深入……開(kāi)發(fā)的細(xì)節(jié)。

就在2004年3月間，我接受一個(gè)朋友的邀請(qǐng)，去北京做一個(gè)名為“Delphi & Delphi .NET源碼分析”的專(zhuān)題培訓(xùn)。我用了近兩周的時(shí)間，做了50頁(yè)的幻燈，全面講述Delphi和Delphi .NET。然而在臨行前的一晚，我輾轉(zhuǎn)反側(cè)，思考著一個(gè)問(wèn)題：我究竟做了些什么？或者說(shuō)，我究竟想告訴學(xué)員些什么？

凌晨5點(diǎn)，我在幻燈的末頁(yè)后插入了一張幻燈，標(biāo)題是“語(yǔ)言只是工具”，而幻燈的內(nèi)容是一張圖：

這是與培訓(xùn)完全無(wú)關(guān)的一張幻燈。然而，這是自1997年我接觸到管理，以及從1998年我接觸到工程以來(lái)，第一次正視“軟件工程”這四個(gè)字。我第一次看清楚代碼、方法、過(guò)程、工程與組織的關(guān)系！

對(duì)于一個(gè)程序員，或者以程序員自命的人來(lái)說(shuō)，看清楚這一切的第一步，竟是一句“語(yǔ)言只是工具”！

猿之于為人，“學(xué)會(huì)制作和使用工具”是最重要的標(biāo)志。因而我不知道“語(yǔ)言只是工具”這句話，究竟是對(duì)語(yǔ)言的膜拜，還是漠視。

然而從那一刻開(kāi)始，我才真正地知道工程。

2. 程序

上面的這個(gè)圖中，在最內(nèi)層的環(huán)里，是“程序＝算法＋結(jié)構(gòu)”。這是編程的本源定義，也是原始的狀態(tài)。與代碼相關(guān)的任何工作，最終仍舊會(huì)落足于這樣的一條規(guī)則。

　編程的精義于此。從有開(kāi)發(fā)行為開(kāi)始，它就存在。挖山不止的愚公在數(shù)千年前就在用類(lèi)似的行為做編程實(shí)踐，而幾十萬(wàn)年前的智人，也在循環(huán)與分支所構(gòu)成的邏輯中打轉(zhuǎn)。

3. 方法

推動(dòng)這種邏輯向前發(fā)展的是“方法”和“方法論”。長(zhǎng)期編程實(shí)踐，自然的推演與總結(jié)，必須沉淀為某種（軟件開(kāi)發(fā)）方法，于是“過(guò)程”出現(xiàn)了， “對(duì)象”出現(xiàn)了，相關(guān)的方法論也就出現(xiàn)了。

這是實(shí)踐的成果。方法不是某個(gè)人或者某個(gè)組織創(chuàng)造的。瓜熟而蒂落，實(shí)踐積累達(dá)到一定的程度，就算微軟不提出某個(gè)方法，IBM也會(huì)提出這個(gè)方法。即便他們都不提出，可能你自己已經(jīng)在使用這個(gè)方法了。

方法并不神秘，因?yàn)樗褪悄憬裉煺谧龅?、從事的和?shí)現(xiàn)的。正如“模式”是一種方法，而模式就是你昨天書(shū)寫(xiě)代碼的那個(gè)行為。只不過(guò)，GoF歸納、抽取、提升了這些行為的內(nèi)在規(guī)律。
你看不到你做事的行為，也就不能理解“模式”作為一種方法的價(jià)值。所以大師們眾口一詞：模式需要一定的編程經(jīng)驗(yàn)才能理解。

同理，理解過(guò)程也需要編程經(jīng)驗(yàn)，理解對(duì)象也需要編程經(jīng)驗(yàn)，理解MDA與SOA還是需要編程經(jīng)驗(yàn)。

這可能就發(fā)生在你回顧上一行精彩的代碼，或者上一個(gè)失敗的項(xiàng)目的一瞬息。經(jīng)驗(yàn)來(lái)源于回顧、理解與分析，而不是你將要寫(xiě)的下一行代碼。

有人在寺院掃了一輩子的落葉而得道，也有人因?yàn)橐痪湓挾玫馈?/P>

GoF因?yàn)闊o(wú)數(shù)次的代碼回顧而得道。

4. 過(guò)程

過(guò)程隨生工程出現(xiàn)。過(guò)程解決的是工程中角色間的關(guān)系問(wèn)題。

　過(guò)程說(shuō)的是很多人（團(tuán)隊(duì)）如何組織在一起進(jìn)行開(kāi)發(fā)。它首先把工程中的各個(gè)環(huán)節(jié)分解出來(lái)。這樣，有了環(huán)節(jié)，就有了角色；有了角色，就有了溝通。

因此過(guò)程中的問(wèn)題，就是角色、溝通和環(huán)節(jié)的問(wèn)題。

哪些環(huán)節(jié)更重要取決于具體的編程行為，也就是具體的項(xiàng)目。

例如產(chǎn)品開(kāi)發(fā)的周期可以一再拖延，因?yàn)閷?duì)產(chǎn)品來(lái)說(shuō)，更重要的是其品質(zhì)和技術(shù)壁壘。因此你可以看到暴雪公司的游戲總是一再跳票，而它從來(lái)都是將大量玩家測(cè)試和開(kāi)發(fā)人員的個(gè)性特征放在第一位。相類(lèi)同的，DOOM與QUAKE系列的靈魂就是在游戲引擎的開(kāi)發(fā)和設(shè)計(jì)上。

如果用這樣的模式去做項(xiàng)目，可能軟件公司沒(méi)死掉，工程需求方也被拖死。試問(wèn)你有看見(jiàn)客戶因?yàn)槟銓?duì)技術(shù)的遠(yuǎn)景描述而憧憬嗎？不，你只會(huì)看到他們因?yàn)轫?xiàng)目的一再延遲而懊惱，而沮喪，或……暴怒。

憧憬這種事情，只會(huì)發(fā)生在那些鐵桿玩家身上。

分不清玩家與客戶的區(qū)別，對(duì)項(xiàng)目經(jīng)理來(lái)說(shuō)，是可怕的。這將意味著他不能清楚地知道哪個(gè)環(huán)節(jié)更加重要。

角色的確定，以及角色間的溝通問(wèn)題，在項(xiàng)目過(guò)程中同樣重要。工程組織是否合理，相互協(xié)作是否緊密，是這個(gè)項(xiàng)目成功的保障。

“合作無(wú)間”通常是流于書(shū)面報(bào)告中的措辭。真正的“無(wú)間”，應(yīng)當(dāng)是溝通的結(jié)果。然而UML，則可能是你與客戶，以及項(xiàng)目經(jīng)理與開(kāi)發(fā)人員被“離間”的第一因素 。

5. 工程

最狹義的工程，是描述“做什么”和“做到什么”。

也就是說(shuō)，是對(duì)目標(biāo)的描述和成果的檢測(cè)。至于這個(gè)工程目標(biāo)的實(shí)現(xiàn)，是“過(guò)程”和“方法”的事；而有效、快速地實(shí)現(xiàn)“過(guò)程”和“方法”所需的，就是“工具”。[NextPage]

這種軟件工程體系層次（Software Engineering Architectural Layers）被描述成一張圖(見(jiàn)下圖)：

過(guò)程伴隨工程而出現(xiàn)，解決的是工程中“步調(diào)一致”的協(xié)作問(wèn)題。那么工程是因?yàn)槭裁炊霈F(xiàn)的？

很顯然，軟件規(guī)模的不斷增大是導(dǎo)致軟件工程出現(xiàn)的根本原因。所以你會(huì)看到在幾年前，開(kāi)發(fā)一個(gè)小工具可以不講工程；或者現(xiàn)在在你的Word中，為了將半角替換成全角字符而寫(xiě)的那個(gè)宏，也不需要工程。

接下來(lái)，即使軟件規(guī)模增大，如果有一個(gè)牛人中的超牛人，愿意用20年來(lái)寫(xiě)一個(gè)任意龐大和復(fù)雜的操作系統(tǒng)，他也是能做到的。然而現(xiàn)實(shí)中不會(huì)有軟件公司給他這樣的機(jī)會(huì)。

項(xiàng)目的“復(fù)雜”可能要求不同知識(shí)領(lǐng)域的角色參與，而“龐大”則要求更多（人力、技術(shù)與管理）資源?！皥F(tuán)隊(duì)”作為開(kāi)發(fā)行為的模式，是軟件規(guī)模和復(fù)雜度漸次累積的結(jié)果。

團(tuán)隊(duì)必將越來(lái)越龐大，因?yàn)椋ㄅc工程對(duì)應(yīng)的）軟件規(guī)模必將越來(lái)越復(fù)雜。沒(méi)有團(tuán)隊(duì)意識(shí)的軟件公司將在高度過(guò)程化、通曉方法理論 、擁有大量工具的集團(tuán)軍面前一觸即潰 。

6. 組織

工程理論其實(shí)是包含組織學(xué)的。然而我在上面的那張圖中，將組織與工程分離開(kāi)來(lái)，并在二者之間畫(huà)下了一道縱向的線。

如果說(shuō)工程關(guān)心的是“需求”、“配置”和“文檔”等等這些要素，那么這樣的工程還是停留在技術(shù)層面：關(guān)注的仍是工程實(shí)現(xiàn)細(xì)節(jié)，而非目標(biāo)。從角色角度來(lái)看，這是項(xiàng)目經(jīng)理和技術(shù)經(jīng)理共同關(guān)注的那一部分。

然而項(xiàng)目經(jīng)理還必須關(guān)注于人力資源、項(xiàng)目資金以及多個(gè)項(xiàng)目之間的協(xié)調(diào)等問(wèn)題。這些問(wèn)題與工程本身并沒(méi)有直接關(guān)系，而是“組織”方面的內(nèi)容。

所以在工程環(huán)節(jié)里，“文檔管理”和“配置管理”等詞匯中的那個(gè)“管理”，是管理的具體技術(shù)和方法；而在“組織”這個(gè)環(huán)節(jié)中的 “管理”，才是真正的管理學(xué)上的用詞。

在這張圖上，我試圖從這個(gè)角度上來(lái)說(shuō)明：作為項(xiàng)目經(jīng)理，你必須有一部分的工作是非技術(shù)性的。甚至，你可能絕大部分的工作是非技術(shù)性的。因?yàn)榕c技術(shù)相關(guān)的管理技能（需求、配置、過(guò)程管理等）可以由開(kāi)發(fā)經(jīng)理來(lái)做，或者公司對(duì)于這一方面有較統(tǒng)一且成熟的規(guī)范，因而無(wú)需投入過(guò)多的精力。

你必須更關(guān)注于對(duì)這個(gè)(或這些)工程的組織與計(jì)劃。站在“組織者”這個(gè)角色上，你現(xiàn)在要考慮的內(nèi)容可能會(huì)是：

為項(xiàng)目的各個(gè)階段建立計(jì)劃，并逐漸地細(xì)化計(jì)劃內(nèi)容，以及確立項(xiàng)目過(guò)程中每一個(gè)環(huán)節(jié)、每一個(gè)計(jì)劃階段的優(yōu)先級(jí)和復(fù)雜度；

確立項(xiàng)目或者產(chǎn)品階段目標(biāo)，成果的準(zhǔn)確描述、定位，以及整個(gè)項(xiàng)目的質(zhì)量目標(biāo)及其考核辦法；

　對(duì)團(tuán)隊(duì)中的不同角色展開(kāi)培訓(xùn)，以指導(dǎo)并協(xié)調(diào)角色間的工作，從而消除因?yàn)楣ぷ髁?xí)慣的差異帶來(lái)的影響；

　為每一個(gè)人準(zhǔn)備他所需要的資源，這不單單是把一套shareware變成正式版或者把512M內(nèi)存變成2G，還包括準(zhǔn)確地評(píng)估他的工作量，以及決定是否為他增加一個(gè)（能協(xié)同工作的）副手；

決定在哪些環(huán)節(jié)上反復(fù)審核和回顧，而在哪些環(huán)節(jié)上采用較為寬松的方式以加快進(jìn)度；

　習(xí)慣于開(kāi)會(huì)、組織更短而有效的會(huì)議以及建立激勵(lì)機(jī)制，當(dāng)然也不要忘記讓每一個(gè)成員意識(shí)到這一項(xiàng)目的風(fēng)險(xiǎn)； 不要樂(lè)觀

即使你做好這一切，可能項(xiàng)目的結(jié)果仍然不夠理想。但是你應(yīng)該知道，好的項(xiàng)目經(jīng)理并不是不犯錯(cuò)誤的人，而是以盡可能少的失敗來(lái)獲得成功的那個(gè)人。

無(wú)論是你的團(tuán)隊(duì)成員，還是你的老板，對(duì)重復(fù)的錯(cuò)誤以及可預(yù)料的錯(cuò)誤都是不會(huì)寬容的。在一個(gè)團(tuán)隊(duì)中，失去了組員的信任比失去老板的信任更為可怕。

所以回顧每一個(gè)項(xiàng)目，或者項(xiàng)目中的每一個(gè)階段，以及與每一個(gè)團(tuán)隊(duì)成員交流的細(xì)節(jié)，是你的日常工作。

7.BOSS

很多人以為BOSS是給自己發(fā)錢(qián)的那個(gè)人，這其實(shí)是錯(cuò)誤的。發(fā)錢(qián)的決策通常是由三個(gè)角色來(lái)做出的：

部門(mén)／團(tuán)隊(duì)經(jīng)理。你的直接上司，他是雇傭你的人，是他用薪金的多少來(lái)衡量你的價(jià)值，或者反之。

　績(jī)效經(jīng)理。如果你的公司有這個(gè)角色的話，那么他總是盯著你的錯(cuò)誤以決定從你的薪水里的扣除比例 。

　財(cái)務(wù)經(jīng)理。有錢(qián)？沒(méi)錢(qián)？沒(méi)錢(qián)？有錢(qián)……

BOSS并不決定你的薪水。

BOSS在公司中解決的是“經(jīng)營(yíng)”問(wèn)題。這其實(shí)是在比“組織”更靠外側(cè)的一層。在前面的圖例中并沒(méi)有給出，這也意味著“經(jīng)營(yíng)者”與“工程”基本沒(méi)有關(guān)系。

在一個(gè)更大規(guī)模的組織機(jī)構(gòu)里，你可以會(huì)更直接地觀察到“經(jīng)營(yíng)者”與“組織者”之間的差異。例如公司的大小股東是“經(jīng)營(yíng)者”，董事會(huì)通常是解決經(jīng)營(yíng)問(wèn)題的地方；而總經(jīng)理、執(zhí)行經(jīng)理以及各個(gè)部門(mén)經(jīng)理則是各級(jí)的“組織者”，經(jīng)理辦公會(huì)則是解決組織問(wèn)題的地方。
你應(yīng)該清楚，真正的BOSS是經(jīng)營(yíng)者。

這有助于你明確你被雇來(lái)的原因，你的工作是面向哪個(gè)層面的，以及你或者你的上司有沒(méi)有權(quán)限來(lái)決定一個(gè)項(xiàng)目是否應(yīng)該立項(xiàng)或中止。

BOSS（經(jīng)營(yíng)者）決定了一個(gè)方向，組織者保證決策與這個(gè)方向是同步的，而工程是在這樣的一個(gè)方向、決策的構(gòu)架下的一個(gè)具體行為。

工程中沒(méi)有BOSS。

8. 上帝之手

從最初的簡(jiǎn)單編程開(kāi)始，到現(xiàn)在工程團(tuán)隊(duì)的組織開(kāi)發(fā)，實(shí)現(xiàn)（一個(gè)軟件）都是最終的目的。所以可以這樣說(shuō)：實(shí)現(xiàn)，是軟件開(kāi)發(fā)的本質(zhì)需求。

我們看到，正是出于實(shí)現(xiàn)需要，我們才設(shè)計(jì)了一些數(shù)據(jù)結(jié)構(gòu)或邏輯結(jié)構(gòu)來(lái)映射物理模型。因此類(lèi)似于過(guò)程、單元、記錄（結(jié)構(gòu)）、對(duì)象等的出現(xiàn)，其實(shí)都是源于編程實(shí)現(xiàn)的需要。

而后，基于某種數(shù)據(jù)結(jié)構(gòu)的編程實(shí)踐（的不斷積累），決定了軟件開(kāi)發(fā)方法理論的產(chǎn)生。

　從這一點(diǎn)可以看出：方法，是對(duì)既有行為的歸納總結(jié)。因而實(shí)現(xiàn)方法總是最先出現(xiàn)的，而后才有分析和設(shè)計(jì)方法。例如面向?qū)ο蠓治觯∣OA）、設(shè)計(jì)（OOD）與編程（OOP）的出現(xiàn)順序，與它們?cè)诠こ踢^(guò)程中的實(shí)作順序正好相反，而與編程實(shí)踐行為的順序則正好相同。

為了實(shí)現(xiàn)更大規(guī)模的軟件系統(tǒng)，逐漸產(chǎn)生了團(tuán)隊(duì)組織模式，而團(tuán)隊(duì)的協(xié)作決定了過(guò)程模型的產(chǎn)生，在過(guò)程環(huán)節(jié)中的溝通問(wèn)題導(dǎo)致了（模型化）語(yǔ)言的出現(xiàn)。

如同編程工具中的編譯器和集成開(kāi)發(fā)環(huán)境(IDE)一樣，開(kāi)發(fā)中的編程語(yǔ)言、過(guò)程中的模型語(yǔ)言都只是一種工具。

工具的產(chǎn)生仍舊是出于“（軟件）實(shí)現(xiàn)”的需要。不可能從軟件開(kāi)發(fā)實(shí)踐中產(chǎn)生出輪子和指南針，因?yàn)槟遣皇恰败浖_(kāi)發(fā)的本質(zhì)需求”可以推動(dòng)的。

軟件工程體系中，“實(shí)現(xiàn)”作為軟件開(kāi)發(fā)的本質(zhì)需求和基本動(dòng)因，如同上帝之手在推動(dòng)這幾十年來(lái)的軟件工程理論體系的形成。