大道至簡——軟件工程實踐者的思想 第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

[新一篇] 大道至簡——軟件工程實踐者的思想 第5章 失敗的過程也是過程

[舊一篇] 大道至簡——軟件工程實踐者的思想 第7章 現實中的軟件工程
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表