從編程到工程

語言只是工具

我曾經是非常執著的開發人員。我有連續幾天幾夜 Coding 的經歷，也曾經為了一個技術問題耗上三四個星期而導致項目一再延遲，還曾經為了一個實現細節與項目相關的人員逐一爭論。

我也曾經像大多數的開發人員一樣熱衷于爭論語言之間孰優孰劣。我在“Delphi大富翁論壇”上寫過一個簡介，其中個人特長是“擅長 TurboPascal、Delphi、TASM 系列語言，痛恨 C/C++。（凡見有價值之 C 代碼，先讀通，后寫成 Pascal/Delphi，最后罵一句：C 寫得真笨！）”。我至今保留這段文字，因為那的確是真實的經歷。

如今我已經不再專注于語言，正如我在第一章中寫到的一樣：成天討論這門語言好，或者那門語言壞的人，甚至是可悲的。

然而就在我寫這段文字之前的一年，我還在寫《Delphi 源代碼分析》，我還在無休止地深入語言的細節，深入操作系統的細節，以及深入……開發的細節。

就在 2004 年 3 月間，我接受一個朋友的邀請，去北京做一個名為“Delphi &Delphi .NET 源碼分析”的專題培訓。我用了近兩周的時間，做了 50 頁的幻燈，全面講述 Delphi 和 Delphi .NET。然而在臨行前的一晚，我輾轉反側，一直在思考一個問題：我究竟做了些什么？或者說，我究竟想告訴學員些什么？

凌晨 5 點，我在幻燈的末頁后面插入了一張幻燈，標題是“語言只是工具”，而幻燈的內容是如圖 7-1 所示的這樣一張圖。

這是與培訓完全無關的一張幻燈。然而，這是我自 1997 年接觸到管理，以及 1998年接觸到工程以來，第一次正視“軟件工程”這四個字。我第一次看清楚代碼、方法、過程、工程與組織的關系！

對于一個程序員，或者以程序員自命的人來說，看清楚這一切的第一步，竟是一句“語言只是工具”！

猿之于為人，“學會制作和使用工具”是最重要的標志。因而我不知道“語言只是工具”這句話，究竟是對語言的膜拜，還是漠視。

然而從那一刻開始，我才真正地知道工程。

關注點

在前面的模型圖中，每一條縱向的細線用于定義一個關注點①。我在另一次培訓中為這些關注點加上了標注，如圖 7-2 所示。

這被我命名為軟件工程層狀模型（EHM，Engineering Hierarchy Model）。EHM 模型不描述工程元素間的關系，甚至在試圖割裂這些元素，以使得工程角色定位及各自的視角更加清晰明確。

從這個模型中可以看到，在“程序”與“方法”層面，是關注于“（具體的）實現”的；而在“過程”和“工程”層面，更首要考慮的是團隊問題。從角色的角度上來說：開發經理思考項目的實施方案和管理具體的開發行為，而項目經理則保障團隊的穩定性和一致性。

程序

EHM 模型圖中，在最內層的環里，是“程序＝算法＋結構”。這是編程的本源定義，也是原始的狀態。與代碼相關的任何工作，最終仍舊會落足于這樣的一條規則。

編程的精義在于此。從有開發行為開始，它就存在了。愚公在數千年前就在用類同的行為做編程實踐，而幾十萬年前的智人，也在循環與分支所構成的邏輯中打轉。

方法

推動這種邏輯向前發展的，是“方法”和“方法論”的出現。長期的編程實踐，自然的歸演與總結，必須沉淀為某種（軟件開發）方法，于是“過程”出現了，于是“對象”出現了，于是相關的方法論也就出現了。

這是實踐的成果。方法不是某個人或者某個組織創造的。瓜熟而蒂落，實踐積累達到一定的程度，微軟不提出某個方法，IBM 也會提出這個方法。即便他們都不提出，可能你自己已經在使用這個方法了。

方法并不神秘，因為它就是你今天正在做的、從事的和實現的。正如“模式”是一種方法，而模式就是你昨天書寫代碼的那個行為。只不過，GoF 歸納、抽取、提升了這些行為的內在規律。

你看不到你做事的行為，也就不能理解“模式”作為一種方法的價值。所以大師們眾口一詞：模式需要一定的編程經驗才能理解。

同理，理解過程也需要編程經驗，理解對象也需要編程經驗，理解 MDA（模型驅動架構）與 SOA（面向服務的體系結構）還是需要編程經驗。

——這可能就發生在你去回顧你的上一行代碼編寫的經過，或者上一個項目失敗的經歷的那一瞬息。經驗來源于回顧、理解與分析，而不是你將要寫的下一行代碼。

有人在寺院掃了一輩子的落葉而得道，也有人因為一句話而得道。

GoF 因為無數次的代碼回顧而得道。

過程

過程伴生工程而出現。過程解決的是工程中角色間的關系問題。

過程說的是很多的人（團隊）如何組織在一起進行開發的問題。它首先把工程中的環節分解出來。這樣，有了環節，就有了角色；有了角色，就有了溝通。

因此過程中的問題，就是角色、溝通和環節的問題。哪些環節重要，取決于具體的編程行為，也就是具體的項目。

例如產品開發的周期可以一再拖延，因為對產品來說，更重要的是品質和技術壁壘。因此你可以看到暴雪公司（Blizzard）的游戲總是一再跳票，而它從來都是將大幅的玩家測試和開發人員的個性特征放在第一位。與此相同，DOOM 與 QUAKE 系列的靈魂就是在游戲引擎的開發和設計上。

如果用這樣的模式去做項目，可能軟件公司沒死掉，工程需求方也被拖死掉了——你有看見客戶因為你對技術的遠景描述而憧憬嗎？不，你只會看到他們因為項目的一再延遲而懊惱、沮喪，或……暴怒。

憧憬這種事情，只會發生在那些鐵桿玩家的身上。

分不清玩家與客戶的區別，對項目經理來說，是可怕的。這將意味著他不能清楚地知道哪個環節更加重要。

角色的確定，以及角色間的溝通問題，在項目過程中也同樣重要。工程組織是否合理，相互的協作是否緊密，是這個項目能否成功的保障。

“合作無間”通常是流于書面報告中的措辭。真正的“無間”，應當是溝通的結果。然而 UML，則可能是你與客戶，以及項目經理與開發人員被“離間”的第一因素。

本文節選自《大道至簡——軟件工程實踐者的思想（典藏版）》

周愛民 著    電子工業出版社出版