從程式設計到工程——軟體工程實踐者的思想（《從程式設計到工程》第六章）
「得其精而忘其粗，在其內而忘其外；見其所見，不見其所不見，視其所視，而遺其所不視」
——《列子 說符》
1. 語言只是工具
我曾經是非常執著的開發人員。我有連續幾天幾夜做coding的經歷，也曾經為了乙個技術問題耗上
三、四個星期而導致專案一再延遲，還曾經為了乙個實現細節與專案相關的人員逐一爭論。
我也曾經像大多數開發人員一樣熱衷於爭論語言之間孰優孰劣。我在「delphi大富翁論壇」上寫過乙個簡介，其中個人特長是「擅長tpascal、delphi、ta**系列語言，痛恨c/c++」。我至今保留這段文字，因為那的確是真實的經歷。
如今我已經不再專注於語言，正如我在第一章中寫到的一樣：成天討論這門語言好，或者那門語言不好的人，是可悲的。
然而就在我寫這段文字之前的一年，我還在寫《delphi源**分析》，我還是無止盡地深入語言細節，深入作業系統細節，以及深入……開發的細節。
就在2023年3月間，我接受乙個朋友的邀請，去北京做乙個名為「delphi & delphi .net原始碼分析」的專題培訓。我用了近兩周的時間，做了50頁的幻燈，全面講述delphi和delphi .net。然而在臨行前的一晚，我輾轉反側，思考著乙個問題：我究竟做了些什麼？或者說，我究竟想告訴學員些什麼？
凌晨5點，我在幻燈的末頁後插入了一張幻燈，標題是「語言只是工具」，而幻燈的內容是一張圖：
這是與培訓完全無關的一張幻燈。然而，這是自2023年我接觸到管理，以及從2023年我接觸到工程以來，第一次正視「軟體工程」這四個字。我第一次看清楚**、方法、過程、工程與組織的關係！
對於乙個程式設計師，或者以程式設計師自命的人來說，看清楚這一切的第一步，竟是一句「語言只是工具」！
猿之於為人，「學會製作和使用工具」是最重要的標誌。因而我不知道「語言只是工具」這句話，究竟是對語言的膜拜，還是漠視。
然而從那一刻開始，我才真正地知道工程。
2. 程式
上面的這個圖中，在最內層的環裡，是「程式＝演算法＋結構」。這是程式設計的本源定義，也是原始的狀態。與**相關的任何工作，最終仍舊會落足於這樣的一條規則。
程式設計的精義於此。從有開發行為開始，它就存在。挖山不止的愚公在數千年前就在用類似的行為做程式設計實踐，而幾十萬年前的智人，也在迴圈與分支所構成的邏輯中打轉。
3. 方法
推動這種邏輯向前發展的是「方法」和「方**」。長期程式設計實踐，自然的推演與總結，必須沉澱為某種（軟體開發）方法，於是「過程」出現了， 「物件」出現了，相關的方**也就出現了。
這是實踐的成果。方法不是某個人或者某個組織創造的。瓜熟而蒂落，實踐積累達到一定的程度，就算微軟不提出某個方法，ibm也會提出這個方法。即便他們都不提出，可能你自己已經在使用這個方法了。
方法並不神秘，因為它就是你今天正在做的、從事的和實現的。正如「模式」是一種方法，而模式就是你昨天書寫**的那個行為。只不過，gof歸納、抽取、提公升了這些行為的內在規律。
你看不到你做事的行為，也就不能理解「模式」作為一種方法的價值。所以大師們眾口一詞：模式需要一定的程式設計經驗才能理解。
同理，理解過程也需要程式設計經驗，理解物件也需要程式設計經驗，理解mda與soa還是需要程式設計經驗。
這可能就發生在你回顧上一行精彩的**，或者上乙個失敗的專案的一瞬息。經驗**於回顧、理解與分析，而不是你將要寫的下一行**。
有人在寺院掃了一輩子的落葉而得道，也有人因為一句話而得道。
gof因為無數次的**回顧而得道。
4. 過程
過程隨生工程出現。過程解決的是工程中角色間的關係問題。
過程說的是很多人（團隊）如何組織在一起進行開發。它首先把工程中的各個環節分解出來。這樣，有了環節，就有了角色；有了角色，就有了溝通。
因此過程中的問題，就是角色、溝通和環節的問題。
哪些環節更重要取決於具體的程式設計行為，也就是具體的專案。
例如產品開發的週期可以一再拖延，因為對產品來說，更重要的是其品質和技術壁壘。因此你可以看到暴雪公司的遊戲總是一再跳票，而它從來都是將大量玩家測試和開發人員的個性特徵放在第一位。相類同的，doom與quake系列的靈魂就是在遊戲引擎的開發和設計上。
如果用這樣的模式去做專案，可能軟體公司沒死掉，工程需求方也被拖死。試問你有看見客戶因為你對技術的遠景描述而憧憬嗎？不，你只會看到他們因為專案的一再延遲而懊惱，而沮喪，或……暴怒。
憧憬這種事情，只會發生在那些鐵桿玩家身上。
分不清玩家與客戶的區別，對專案經理來說，是可怕的。這將意味著他不能清楚地知道哪個環節更加重要。
角色的確定，以及角色間的溝通問題，在專案過程中同樣重要。工程組織是否合理，相互協作是否緊密，是這個專案成功的保障。
「合作無間」通常是流於書面報告中的措辭。真正的「無間」，應當是溝通的結果。然而uml，則可能是你與客戶，以及專案經理與開發人員被「離間」的第一因素 。
5. 工程
最狹義的工程，是描述「做什麼」和「做到什麼」。
也就是說，是對目標的描述和成果的檢測。至於這個工程目標的實現，是「過程」和「方法」的事；而有效、快速地實現「過程」和「方法」所需的，就是「工具」。
這種軟體工程體系層次（software engineering architectural layers）被描述成一張圖(見下圖)：
過程伴隨工程而出現，解決的是工程中「步調一致」的協作問題。那麼工程是因為什麼而出現的？
很顯然，軟體規模的不斷增大是導致軟體工程出現的根本原因。所以你會看到在幾年前，開發乙個小工具可以不講工程；或者現在在你的word中，為了將半形替換成全形字符而寫的那個巨集，也不需要工程。
接下來，即使軟體規模增大，如果有乙個牛人中的超牛人，願意用20年來寫乙個任意龐大和複雜的作業系統，他也是能做到的。然而現實中不會有軟體公司給他這樣的機會。
專案的「複雜」可能要求不同知識領域的角色參與，而「龐大」則要求更多（人力、技術與管理）資源。「團隊」作為開發行為的模式，是軟體規模和複雜度漸次累積的結果。
團隊必將越來越龐大，因為（與工程對應的）軟體規模必將越來越複雜。沒有團隊意識的軟體公司將在高度過程化、通曉方法理論 、擁有大量工具的集團軍面前一觸即潰 。
6. 組織
工程理論其實是包含組織學的。然而我在上面的那張圖中，將組織與工程分離開來，並在二者之間畫下了一道縱向的線。
如果說工程關心的是「需求」、「配置」和「文件」等等這些要素，那麼這樣的工程還是停留在技術層面：關注的仍是工程實現細節，而非目標。從角色角度來看，這是專案經理和技術經理共同關注的那一部分。
然而專案經理還必須關注於人力資源、專案資金以及多個專案之間的協調等問題。這些問題與工程本身並沒有直接關係，而是「組織」方面的內容。
所以在工程環節裡，「文件管理」和「配置管理」等詞彙中的那個「管理」，是管理的具體技術和方法；而在「組織」這個環節中的 「管理」，才是真正的管理學上的用詞。
在這張圖上，我試圖從這個角度上來說明：作為專案經理，你必須有一部分的工作是非技術性的。甚至，你可能絕大部分的工作是非技術性的。因為與技術相關的管理技能（需求、配置、過程管理等）可以由開發經理來做，或者公司對於這一方面有較統一且成熟的規範，因而無需投入過多的精力。
你必須更關注於對這個(或這些)工程的組織與計畫。站在「組織者」這個角色上，你現在要考慮的內容可能會是：
即使你做好這一切，可能專案的結果仍然不夠理想。但是你應該知道，好的專案經理並不是不犯錯誤的人，而是以盡可能少的失敗來獲得成功的那個人。
無論是你的團隊成員，還是你的老闆，對重複的錯誤以及可預料的錯誤都是不會寬容的。在乙個團隊中，失去了組員的信任比失去老闆的信任更為可怕。
所以回顧每乙個專案，或者專案中的每乙個階段，以及與每乙個團隊成員交流的細節，是你的日常工作。
7.boss
很多人以為boss是給自己發錢的那個人，這其實是錯誤的。發錢的決策通常是由三個角色來做出的：
boss並不決定你的薪水。
boss在公司中解決的是「經營」問題。這其實是在比「組織」更靠外側的一層。在前面的圖例中並沒有給出，這也意味著「經營者」與「工程」基本沒有關係。
在乙個更大規模的組織機構裡，你可以會更直接地觀察到「經營者」與「組織者」之間的差異。例如公司的大小股東是「經營者」，董事會通常是解決經營問題的地方；而總經理、執行經理以及各個部門經理則是各級的「組織者」，經理辦公會則是解決組織問題的地方。
你應該清楚，真正的boss是經營者。
這有助於你明確你被雇來的原因，你的工作是面向哪個層面的，以及你或者你的上司有沒有許可權來決定乙個專案是否應該立項或中止。
boss（經營者）決定了乙個方向，組織者保證決策與這個方向是同步的，而工程是在這樣的乙個方向、決策的構架下的乙個具體行為。
工程中沒有boss。
8. 上帝之手
從最初的簡單程式設計開始，到現在工程團隊的組織開發，實現（乙個軟體）都是最終的目的。所以可以這樣說：實現，是軟體開發的本質需求。
我們看到，正是出於實現需要，我們才設計了一些資料結構或邏輯結構來對映物理模型。因此類似於過程、單元、記錄（結構）、物件等的出現，其實都是源於程式設計實現的需要。
而後，基於某種資料結構的程式設計實踐（的不斷積累），決定了軟體開發方法理論的產生。
從這一點可以看出：方法，是對既有行為的歸納總結。因而實現方法總是最先出現的，而後才有分析和設計方法。例如物件導向分析（ooa）、設計（ood）與程式設計（oop）的出現順序，與它們在工程過程中的實作順序正好相反，而與程式設計實踐行為的順序則正好相同。
為了實現更大規模的軟體系統，逐漸產生了團隊組織模式，而團隊的協作決定了過程模型的產生，在過程環節中的溝通問題導致了（模型化）語言的出現。
如同程式設計工具中的編譯器和整合開發環境(ide)一樣，開發中的程式語言、過程中的模型語言都只是一種工具。
工具的產生仍舊是出於「（軟體）實現」的需要。不可能從軟體開發實踐中產生出輪子和指南針，因為那不是「軟體開發的本質需求」可以推動的。
軟體工程體系中，「實現」作為軟體開發的本質需求和基本動因，如同上帝之手在推動這幾十年來的軟體工程理論體系的形成。
軟體只是個工具而已
記得大學的時候有個日本的教授去我們學生寢室參觀，完了後感慨中國學生真有錢，日本學生都還在用photoshop5.0，而且還是好幾個同學合買的，你們人人電腦上裝的都是7.0了，聽了後我狂笑。大概是中國的軟體都是免費的吧，所以大家都喜歡追求軟體的最新版本，別人都還才出試用版，都還有很多bug沒解決，你就...
只是 只是習慣而已
我們習慣把結局當做故事的終點，把死亡當做生命的盡頭，但也許那些都僅僅是另乙個故事的，另乙個生命的開始。我們習慣把自己放在不屬於自己的位置，用不屬於自己的心情填補自己的時間，最終沒有任何得到。我們習慣告訴別人自己想要些什麼，卻把鎮長想要的深深的埋在心底，終成為只屬於自己乙個人的秘密。我們習慣對自己撒謊...
卷首語 「英語」不需要專業，因為它只是工具
卷首語 英語 不需要專業，因為它只是工具 有時候如果應聘到了乙個有外資背景的公司或者這個公司的很多人都有海外或外資工作背景時，你也許還會用到一些日常工作交流時候的詞彙。比如我們看一下某主管開會時的發言 小王，請你盡快 push 一下這件事，按照前期咱們定下來的 plan 來 follow 這個 ca...