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