語言只是工具
我曾經是非常執著的開發人員。我有連續幾天幾夜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 年接觸到管理，以及2023年接觸到工程以來，第一次正視「軟體工程」這四個字。我第一次看清楚**、方法、過程、工程與組織的關係！
對於乙個程式設計師，或者以程式設計師自命的人來說，看清楚這一切的第一步，竟是一句「語言只是工具」！
猿之於為人，「學會製作和使用工具」是最重要的標誌。因而我不知道「語言只是工具」這句話，究竟是對語言的膜拜，還是漠視。
然而從那一刻開始，我才真正地知道工程。
關注點
在前面的模型圖中，每一條縱向的細線用於定義乙個關注點①。我在另一次培訓中為這些關注點加上了標註，如圖 7-2 所示。
這被我命名為軟體工程層狀模型（ehm，engineering hierarchy model）。ehm 模型不描述工程元素間的關係，甚至在試圖割裂這些元素，以使得工程角色定位及各自的視角更加清晰明確。
從這個模型中可以看到，在「程式」與「方法」層面，是關注於「（具體的）實現」的；而在「過程」和「工程」層面，更首要考慮的是團隊問題。從角色的角度上來說：開發經理思考專案的實施方案和管理具體的開發行為，而專案經理則保障團隊的穩定性和一致性。
程式
ehm 模型圖中，在最內層的環裡，是「程式＝演算法＋結構」。這是程式設計的本源定義，也是原始的狀態。與**相關的任何工作，最終仍舊會落足於這樣的一條規則。
程式設計的精義在於此。從有開發行為開始，它就存在了。愚公在數千年前就在用類同的行為做程式設計實踐，而幾十萬年前的智人，也在迴圈與分支所構成的邏輯中打轉。
方法
推動這種邏輯向前發展的，是「方法」和「方**」的出現。長期的程式設計實踐，自然的歸演與總結，必須沉澱為某種（軟體開發）方法，於是「過程」出現了，於是「物件」出現了，於是相關的方**也就出現了。
這是實踐的成果。方法不是某個人或者某個組織創造的。瓜熟而蒂落，實踐積累達到一定的程度，微軟不提出某個方法，ibm 也會提出這個方法。即便他們都不提出，可能你自己已經在使用這個方法了。
方法並不神秘，因為它就是你今天正在做的、從事的和實現的。正如「模式」是一種方法，而模式就是你昨天書寫**的那個行為。只不過，gof 歸納、抽取、提公升了這些行為的內在規律。
你看不到你做事的行為，也就不能理解「模式」作為一種方法的價值。所以大師們眾口一詞：模式需要一定的程式設計經驗才能理解。
同理，理解過程也需要程式設計經驗，理解物件也需要程式設計經驗，理解mda（模型驅動架構）與soa（面向服務的體系結構）還是需要程式設計經驗。
——這可能就發生在你去回顧你的上一行**編寫的經過，或者上乙個專案失敗的經歷的那一瞬息。經驗**於回顧、理解與分析，而不是你將要寫的下一行**。
有人在寺院掃了一輩子的落葉而得道，也有人因為一句話而得道。
gof 因為無數次的**回顧而得道。
過程
過程伴生工程而出現。過程解決的是工程中角色間的關係問題。
過程說的是很多的人（團隊）如何組織在一起進行開發的問題。它首先把工程中的環節分解出來。這樣，有了環節，就有了角色；有了角色，就有了溝通。
因此過程中的問題，就是角色、溝通和環節的問題。哪些環節重要，取決於具體的程式設計行為，也就是具體的專案。
例如產品開發的週期可以一再拖延，因為對產品來說，更重要的是品質和技術壁壘。因此你可以看到暴雪公司（blizzard）的遊戲總是一再跳票，而它從來都是將大幅的玩家測試和開發人員的個性特徵放在第一位。與此相同，doom 與quake 系列的靈魂就是在遊戲引擎的開發和設計上。
如果用這樣的模式去做專案，可能軟體公司沒死掉，工程需求方也被拖死掉了——你有看見客戶因為你對技術的遠景描述而憧憬嗎？不，你只會看到他們因為專案的一再延遲而懊惱、沮喪，或……暴怒。
憧憬這種事情，只會發生在那些鐵桿玩家的身上。
分不清玩家與客戶的區別，對專案經理來說，是可怕的。這將意味著他不能清楚地知道哪個環節更加重要。
角色的確定，以及角色間的溝通問題，在專案過程中也同樣重要。工程組織是否合理，相互的協作是否緊密，是這個專案能否成功的保障。
「合作無間」通常是流於書面報告中的措辭。真正的「無間」，應當是溝通的結果。然而 uml，則可能是你與客戶，以及專案經理與開發人員被「離間」的第一因素。
本文節選自《大道至簡——軟體工程實踐者的思想（典藏版）》
周愛民著電子工業出版社出版
說說「從程式設計到工程」專欄的由來
2005年06月07日 02 40 00 這本書現在終於能與讀者見面了。一方面，這本書薄到只有130頁，還是小幅面的。另一方面，我在其中完整地論及了我這些年來對軟體工程的思考。這些思考的核心只有一句，就是 靈活的軟體工程 而靈活的根本，就是要深深地領悟軟體工程的思想，而不是簡單地去了解或者掌握一種工...
從 Scratch 到程式設計
目前很多孩子在學 scratch 程式設計，但是覺得有些教育的方向有問題，大多數是在做遊戲設計，與演算法層面的培訓不多。實際上，作為一種兒童程式語言，當我第一次看到兒子用scratch，我就意識到這是乙個非常不錯的適合孩子用的程式語言。scratch的 控制 模組中包含的 迴圈重複執行 如果那麼條件...
讀《大道至簡 從程式設計到工程》有感
懷著熱情讀完這一章之後，了解到作者向我們介紹了 語言只是工具 程式 方法 過程 工程 組織 上帝之手 這8個方面，讓我深入認識到在工作當中應該注意的方面應該具備哪些素質和應該側重於哪一些方面。從程式設計到工程，從語言到程式，這是我們的必經之路。那麼語言是什麼，當我讀完這一章之後便對語言有了深一步的理...