“得其精而忘其粗，在其內而忘其外；見其所見，不見其所不見，視其所視，而遺其所不視”——《列子 說符》
1. 語言只是工具
我曾經是非常執著的開發人員。我有連續幾天幾夜做Coding的經歷，也曾經為了一個技術問題耗上三、四個星期而導致項目一再延遲，還曾經為了一個實現細節與項目相關的人員逐一爭論。
我也曾經像大多數開發人員一樣熱衷于爭論語言之間孰優孰劣。我在“Delphi大富翁論壇”上寫過一個簡介，其中個人特長是“擅長TPascal、Delphi、TASM系列語言，痛恨C/C++”。我至今保留這段文字，因為那的確是真實的經歷。
如今我已經不再專注于語言，正如我在第一章中寫到的一樣：成天討論這門語言好，或者那門語言不好的人，是可悲的。
然而就在我寫這段文字之前的一年，我還在寫《Delphi源代碼分析》，我還是無止盡地深入語言細節，深入操作系統細節，以及深入……開發的細節。
就在2004年3月間，我接受一個朋友的邀請，去北京做一個名為“Delphi & Delphi .NET源碼分析”的專題培訓。我用了近兩周的時間，做了50頁的幻燈，全面講述Delphi和Delphi .NET。然而在臨行前的一晚，我輾轉反側，思考著一個問題：我究竟做了些什么？或者說，我究竟想告訴學員些什么？
凌晨5點，我在幻燈的末頁后插入了一張幻燈，標題是“語言只是工具”，而幻燈的內容是一張圖：
這是與培訓完全無關的一張幻燈。然而，這是自1997年我接觸到管理，以及從1998年我接觸到工程以來，第一次正視“軟件工程”這四個字。我第一次看清楚代碼、方法、過程、工程與組織的關系！
對于一個程序員，或者以程序員自命的人來說，看清楚這一切的第一步，竟是一句“語言只是工具”！
猿之于為人，“學會制作和使用工具”是最重要的標志。因而我不知道“語言只是工具”這句話，究竟是對語言的膜拜，還是漠視。
然而從那一刻開始，我才真正地知道工程。
2. 程序
上面的這個圖中，在最內層的環里，是“程序＝算法＋結構”。這是編程的本源定義，也是原始的狀態。與代碼相關的任何工作，最終仍舊會落足于這樣的一條規則。
編程的精義于此。從有開發行為開始，它就存在。挖山不止的愚公在數千年前就在用類似的行為做編程實踐，而幾十萬年前的智人，也在循環與分支所構成的邏輯中打轉。
3. 方法
推動這種邏輯向前發展的是“方法”和“方法論”。長期編程實踐，自然的推演與總結，必須沉淀為某種（軟件開發）方法，于是“過程”出現了， “對象”出現了，相關的方法論也就出現了。
這是實踐的成果。方法不是某個人或者某個組織創造的。瓜熟而蒂落，實踐積累達到一定的程度，就算微軟不提出某個方法，IBM也會提出這個方法。即便他們都不提出，可能你自己已經在使用這個方法了。
方法并不神秘，因為它就是你今天正在做的、從事的和實現的。正如“模式”是一種方法，而模式就是你昨天書寫代碼的那個行為。只不過，GoF歸納、抽取、提升了這些行為的內在規律。
你看不到你做事的行為，也就不能理解“模式”作為一種方法的價值。所以大師們眾口一詞：模式需要一定的編程經驗才能理解。
同理，理解過程也需要編程經驗，理解對象也需要編程經驗，理解MDA與SOA還是需要編程經驗。
這可能就發生在你回顧上一行精彩的代碼，或者上一個失敗的項目的一瞬息。經驗來源于回顧、理解與分析，而不是你將要寫的下一行代碼。
有人在寺院掃了一輩子的落葉而得道，也有人因為一句話而得道。
GoF因為無數次的代碼回顧而得道。
4. 過程
過程隨生工程出現。過程解決的是工程中角色間的關系問題。
過程說的是很多人（團隊）如何組織在一起進行開發。它首先把工程中的各個環節分解出來。這樣，有了環節，就有了角色；有了角色，就有了溝通。
因此過程中的問題，就是角色、溝通和環節的問題。
哪些環節更重要取決于具體的編程行為，也就是具體的項目。
例如產品開發的周期可以一再拖延，因為對產品來說，更重要的是其品質和技術壁壘。因此你可以看到暴雪公司的游戲總是一再跳票，而它從來都是將大量玩家測試和開發人員的個性特征放在第一位。相類同的，DOOM與QUAKE系列的靈魂就是在游戲引擎的開發和設計上。
如果用這樣的模式去做項目，可能軟件公司沒死掉，工程需求方也被拖死。試問你有看見客戶因為你對技術的遠景描述而憧憬嗎？不，你只會看到他們因為項目的一再延遲而懊惱，而沮喪，或……暴怒。
憧憬這種事情，只會發生在那些鐵桿玩家身上。
分不清玩家與客戶的區別，對項目經理來說，是可怕的。這將意味著他不能清楚地知道哪個環節更加重要。
角色的確定，以及角色間的溝通問題，在項目過程中同樣重要。工程組織是否合理，相互協作是否緊密，是這個項目成功的保障。
“合作無間”通常是流于書面報告中的措辭。真正的“無間”，應當是溝通的結果。然而UML，則可能是你與客戶，以及項目經理與開發人員被“離間”的第一因素 。
5. 工程
最狹義的工程，是描述“做什么”和“做到什么”。
也就是說，是對目標的描述和成果的檢測。至于這個工程目標的實現，是“過程”和“方法”的事；而有效、快速地實現“過程”和“方法”所需的，就是“工具”。[NextPage]
這種軟件工程體系層次（Software Engineering Architectural Layers）被描述成一張圖(見下圖)：
過程伴隨工程而出現，解決的是工程中“步調一致”的協作問題。那么工程是因為什么而出現的？
很顯然，軟件規模的不斷增大是導致軟件工程出現的根本原因。所以你會看到在幾年前，開發一個小工具可以不講工程；或者現在在你的Word中，為了將半角替換成全角字符而寫的那個宏，也不需要工程。
接下來，即使軟件規模增大，如果有一個牛人中的超牛人，愿意用20年來寫一個任意龐大和復雜的操作系統，他也是能做到的。然而現實中不會有軟件公司給他這樣的機會。
項目的“復雜”可能要求不同知識領域的角色參與，而“龐大”則要求更多（人力、技術與管理）資源。“團隊”作為開發行為的模式，是軟件規模和復雜度漸次累積的結果。
團隊必將越來越龐大，因為（與工程對應的）軟件規模必將越來越復雜。沒有團隊意識的軟件公司將在高度過程化、通曉方法理論 、擁有大量工具的集團軍面前一觸即潰 。
6. 組織
工程理論其實是包含組織學的。然而我在上面的那張圖中，將組織與工程分離開來，并在二者之間畫下了一道縱向的線。
如果說工程關心的是“需求”、“配置”和“文檔”等等這些要素，那么這樣的工程還是停留在技術層面：關注的仍是工程實現細節，而非目標。從角色角度來看，這是項目經理和技術經理共同關注的那一部分。
然而項目經理還必須關注于人力資源、項目資金以及多個項目之間的協調等問題。這些問題與工程本身并沒有直接關系，而是“組織”方面的內容。
所以在工程環節里，“文檔管理”和“配置管理”等詞匯中的那個“管理”，是管理的具體技術和方法；而在“組織”這個環節中的 “管理”，才是真正的管理學上的用詞。
在這張圖上，我試圖從這個角度上來說明：作為項目經理，你必須有一部分的工作是非技術性的。甚至，你可能絕大部分的工作是非技術性的。因為與技術相關的管理技能（需求、配置、過程管理等）可以由開發經理來做，或者公司對于這一方面有較統一且成熟的規范，因而無需投入過多的精力。
你必須更關注于對這個(或這些)工程的組織與計劃。站在“組織者”這個角色上，你現在要考慮的內容可能會是：
為項目的各個階段建立計劃，并逐漸地細化計劃內容，以及確立項目過程中每一個環節、每一個計劃階段的優先級和復雜度；
確立項目或者產品階段目標，成果的準確描述、定位，以及整個項目的質量目標及其考核辦法；
對團隊中的不同角色展開培訓，以指導并協調角色間的工作，從而消除因為工作習慣的差異帶來的影響；
為每一個人準備他所需要的資源，這不單單是把一套shareware變成正式版或者把512M內存變成2G，還包括準確地評估他的工作量，以及決定是否為他增加一個（能協同工作的）副手；
決定在哪些環節上反復審核和回顧，而在哪些環節上采用較為寬松的方式以加快進度；
習慣于開會、組織更短而有效的會議以及建立激勵機制，當然也不要忘記讓每一個成員意識到這一項目的風險； 不要樂觀
即使你做好這一切，可能項目的結果仍然不夠理想。但是你應該知道，好的項目經理并不是不犯錯誤的人，而是以盡可能少的失敗來獲得成功的那個人。
無論是你的團隊成員，還是你的老板，對重復的錯誤以及可預料的錯誤都是不會寬容的。在一個團隊中，失去了組員的信任比失去老板的信任更為可怕。
所以回顧每一個項目，或者項目中的每一個階段，以及與每一個團隊成員交流的細節，是你的日常工作。
7.BOSS
很多人以為BOSS是給自己發錢的那個人，這其實是錯誤的。發錢的決策通常是由三個角色來做出的：
部門／團隊經理。你的直接上司，他是雇傭你的人，是他用薪金的多少來衡量你的價值，或者反之。
績效經理。如果你的公司有這個角色的話，那么他總是盯著你的錯誤以決定從你的薪水里的扣除比例 。
財務經理。有錢？沒錢？沒錢？有錢……
BOSS并不決定你的薪水。
BOSS在公司中解決的是“經營”問題。這其實是在比“組織”更靠外側的一層。在前面的圖例中并沒有給出，這也意味著“經營者”與“工程”基本沒有關系。
在一個更大規模的組織機構里，你可以會更直接地觀察到“經營者”與“組織者”之間的差異。例如公司的大小股東是“經營者”，董事會通常是解決經營問題的地方；而總經理、執行經理以及各個部門經理則是各級的“組織者”，經理辦公會則是解決組織問題的地方。
你應該清楚，真正的BOSS是經營者。
這有助于你明確你被雇來的原因，你的工作是面向哪個層面的，以及你或者你的上司有沒有權限來決定一個項目是否應該立項或中止。
BOSS（經營者）決定了一個方向，組織者保證決策與這個方向是同步的，而工程是在這樣的一個方向、決策的構架下的一個具體行為。
工程中沒有BOSS。
8. 上帝之手
從最初的簡單編程開始，到現在工程團隊的組織開發，實現（一個軟件）都是最終的目的。所以可以這樣說：實現，是軟件開發的本質需求。
我們看到，正是出于實現需要，我們才設計了一些數據結構或邏輯結構來映射物理模型。因此類似于過程、單元、記錄（結構）、對象等的出現，其實都是源于編程實現的需要。
而后，基于某種數據結構的編程實踐（的不斷積累），決定了軟件開發方法理論的產生。
從這一點可以看出：方法，是對既有行為的歸納總結。因而實現方法總是最先出現的，而后才有分析和設計方法。例如面向對象分析（OOA）、設計（OOD）與編程（OOP）的出現順序，與它們在工程過程中的實作順序正好相反，而與編程實踐行為的順序則正好相同。
為了實現更大規模的軟件系統，逐漸產生了團隊組織模式，而團隊的協作決定了過程模型的產生，在過程環節中的溝通問題導致了（模型化）語言的出現。
如同編程工具中的編譯器和集成開發環境(IDE)一樣，開發中的編程語言、過程中的模型語言都只是一種工具。
工具的產生仍舊是出于“（軟件）實現”的需要。不可能從軟件開發實踐中產生出輪子和指南針，因為那不是“軟件開發的本質需求”可以推動的。
軟件工程體系中，“實現”作為軟件開發的本質需求和基本動因，如同上帝之手在推動這幾十年來的軟件工程理論體系的形成。
：鞏經理
：13915946763
：南京塞姆泵業有限公司
