 |
相關閱讀 |
大道至簡——軟件工程實踐者的思想 第7章 現實中的軟件工程
|
>>> 讀書—連接古今充實信仰 >>> | 簡體 傳統 |
第7章 現實中的軟件工程
“王不如遠交而近攻，得寸，則王之寸；得尺，亦王之尺也。”
——《戰國策．秦策》
1. 大公司手中的算盤
從最早僅僅關注于軟件開發工具到現在，軟件行業中的巨頭們已經在層出不窮的思想中涅槃了一回又一回。
Rational 被 IBM 購并的真實原因在于 IBM 需要構建一個完整的軟件工程體系。有了 Rational 的 IBM 會變成
這個樣子：
IBM 的軟件工程(2004)
理論體系 實 現
工具 Language Rational Suite、WebSphere、Eclipse
方法 OOA/D/P IBM軟件開發平臺(SDP)
過程 RUP RUP2000、RUP2003
IBM 得到 Rational 的最大好處是在軟件工程方面，快
速地擁有了一套成熟的理論體系和實作工具。對于 IBM
來說，Rational 有著 UML 語言的非常豐富的實踐經驗，
還有著 RUP 作為理論框架的創立者和領導者的地位，這
些對 IBM 在確立大型軟件工程應用方案提供商的行業形
象，都是極大的支持。
在語言方面，IBM 注意到 JAVA 作為平臺中立的語言
特性，以及它在大型應用工程方面的成功表現，作為扼制
Microsoft 的平臺優勢的唯一途徑，IBM 在語言方面選擇
支持 JAVA 是明智的。
出于同樣的理由，IBM 親近開源軟件界，并很快成為
開源軟件領域的頭羊地位。這使得 IBM 從沒有語言優勢
立即變成了“可以忽略語言劣勢”。開源界給了 IBM 一種
對抗的背景和實力，而 IBM 只需要做到把握這種力量，
就可以在潮流中穩如磐石。
把握力量總之比創造力量來得經濟。
同樣，Borland 也從開發工具廠商的位置跳出來，希
望構建類似的軟件工程體系。所以現在你會看到這樣的一
個 Borland：
Borland 的軟件工程(2004)
理論體系 實 現
工具 Language Togther、StarTeam、Delphi、CBX、JB...
方法 OOA/D/P Galileo、PrimeTime
過程 ALM Borland ALM Solution
對于 Borland 來說，在對軟件開發語言(C、Java、Delphi)
的把握方面是優勢，所以 Borland 一直保持在語言上的中
立，以尋求一種在不同平臺上的開發者社群的支持最大
化。Borland 積極的推動 UML 的標準化，一方面可以使
得 Borland 有機會在模型語言標準的制定上有機會制造影
響，另一方面也可以快速地與 IBM/Rational 構成對抗
Mircosoft 的戰線。
作 為 工 具 開 發 商 ， Borland 快 速 地 擁 有 了 實 現
ALM(Application Lifecycle Management)所需的絕大多數
軟件產品。然而 Borland 也很快意識到，(當前的)ALM 是
一個產品體系，而不是一個理論體系：Borland 沒有在
ALM 作為工程理論方面的任何優勢。于是 Borland 開始
購并與實現 ALM 體系相關的公司，其中收購過程改進咨
詢公司 TeraQuest 并組建流程優化實務部，以及收購
TogetherSoft 為開發工具來強化模型構建能力，都是相當
大的一些舉措。通過這些努力，Borland 快速地補全了
ALM 作為一個工程體系在理論方面的不足。
對于 IBM 來說，RUP 和 UML 是優勢，所以 IBM 用
來削弱 Borland 在開發語言的上優勢的最佳手段，就是支
持開源的 Eclipse，以及用 UML 的標準化來確立其規范制
定者的地位。然而你會驚異的發現，Borland 一方面在支
持 UML 的標準化，另一方面還在支持著 Eclipse 的開發并
協助其快速成為一個完整的、具有商業品質的開發平臺。
這似乎是極其怪異的戰略：幫對手磨劍。
如果 Borland 只為一個對手磨劍，那他可能是一個傻
子。但問題是，Borland 幾乎為他所有既已成為的或者終
將成為對手的人磨劍：Kylix 是 Linux 平臺上的產品，
C++Builder、C#Builder、CBX、Delphi 是 Win32 和.NET
平臺上的產品，JBuilder 則是 SUN 平臺上的產品。——一
切正如 Borland 自己說的那樣，他是“(語言、平臺和技術)
中立的軟件廠商”。
Borland 走在鋼絲繩的中間，對他的考驗是平衡的藝
術和技術：如果他倒下，鋼絲繩兩端之任一，對他都不及
援手；然而如果他存在，那么他向哪邊邁出的一步，都將
給對方以最大的壓力。
敵人的敵人就是自己的朋友，聰明的戰略家總是能看
到這一點。然而 Borland 卻力圖使這個敵我都分不清的戰
場呈現出一種古怪的格局：一方面 Microsoft 是 Borland
的股東之一，另一方面 Borland 在做 SUN、IBM 以及 Linux
平臺上的軟件提供商。
與 Borland 和 IBM 通購并來達到目的的方式并不相
同，Microsoft 有足夠的力量全方位出擊，因此你看到的
體系會這是這個樣子的：
Microsoft 的軟件工程(2004)
理論體系 實 現
工具 Language VS.NET、DSL、.NET Framework
方法 OOA/D/P 需求方法、模型方法、測試方法...
過程 MSF MSF Process Model v.3.1
Microsoft 在工具、方法和過程方面都有具體的實現。
而 IBM 在方法和過程層面上大都停留在理論階段，
Borland 在這些方面雖有豐富的產品實現，卻又相對缺乏
理論基礎。
Microsoft 并不僅停留于此。從.NET Framework 提出
開始 Microsoft 就試圖在開發語言和基礎框架上實現大統
一，希望能達到 UML 在模型語言中的地位。因此出現了
通用的語言體系：CLR+CTS，以及其具體的實現：.NET
CLR+IAsm。.NET 上的代碼要求最終被實現成中間代碼，
可以反匯編到 IAsm，這意味著任何其它公司在開發語言
層 面 上 的 優 勢 喪 失 殆 盡 ， 所 以 開 發 者 們 看 到 C# 、
JScript.NET 和 VB.NET 的同期實現的“壯舉”。
而 Mono 的出現，對于 Microsoft 來是絕對的福音。
Microsoft 把.NET Framework 中的 C#、公共語言架構(CLI)
以及通用類型系統(CTS)等做成 ECMA 標準，最期望看到
的就是類似 Mono 這樣的第三方產品的出現。事實上，
Mono 做了 Microsoft 從來都想做而不敢做的事。——解決
了 Microsoft 產品的跨平臺問題，進而削弱了 SUN 這樣的
語言的跨平臺優勢。Microsoft 一方面不想放棄自己的平
臺優勢，另一方面又為 SUN 的跨平臺優勢所制肘。而
Mono 的出現以及它適度的影響力，正好成為 Microsoft
平衡這種微妙的、相對優劣形勢的棋子。
接下來 Microsoft 開始向模型語言發難。領域專用語
言（Domain-Specific Language，DSL）的提出絕非偶然，
那是在硝煙未盡的戰場上重新燃起的戰火。
軟件業界如今的局面，不是一些人(例如程序員或者
評論家們)爭爭吵吵的結果，而是大公司們相互制衡的結
果。Borland 與 IBM，IBM 與 SUN，以及 SUN 與 Apple
都在做著相同的事， 又都有各自的算盤。他們一面打壓
對手的優勢，一面又借助對手和同盟的力量來削弱自己的
劣勢或者補充實力。
跳出到局外來看，并不是說 Microsoft 是他們的共同
對手，而只是因為 Microsoft 占在了峰頭浪尖，便成了眾
矢之的。所有人面對的并不是 Microsoft 的這個名字，而
只是這個地位，無論誰成就了這個地位，都將承受相同的
風險與壓力。
當然也包括機會。
大公司們在標準、理論、語言上的爭來奪去，未必全
然出于“軟件實現”的考慮。對統一理論、統一工具、統
一過程的企圖，其最終目的是在整個軟件工程體系中的全
面勝出。
算盤上的絕大多數人，只是用于計算勝負的一枚算
子。
2. 回到工程的關鍵點
因而，除了軟件本質力量的推動之外，商業因素也推
動著軟件工程體系的發展。大公司們的爭奪戰的最終結
果，已經開始把軟件工程，從原始的“自生演進”狀態，
逐漸推進到“它激發展”的狀態上了。
這種它激發展可能會影響到軟件工程發展的速度，然
而在各個工程層面上的關注點并不會發生變化。在前面的
模型圖中，每一條縱向的細線用于定義一個關注點①。我
在另一次培訓中為這些關注點加上了標注：
實現 團隊 經營
這被我命名為軟件工程層狀模型(EHM, Engineering
Hiberarchy Model)。與“牛屎圖”所代表的“軟件工程體
系層次”不一樣的是，EHM 不描述工程元素間的關系，
甚至在試圖割裂這些元素，以使得工程角色定位以及各自
的視角更加清晰明確。
① 我的確畫出的線而不是點，“關注點”只是一個概念。如果你非
要去發現一個“點”，那么你可以用幾何的目光，關注于弧線與直
線的切點。然而，這樣的結果將是你徹底的忽視了“關注點”的
本質含義。
-89-
第 7 章 現實中的軟件工程
從這個模型中可以看到，在“程序”與“方法”層面，
是關注于“(具體的)實現”的；而在“過程”和“工程”
層面，更首要考慮的是團隊問題。從角色的角度上來說：
開發經理思考項目的實施方案和管理具體的開發行為；而
項目經理則保障團隊的穩定性和一致性。
然而這只是基本模式，或者說，是理想模式。
3. 思考項目成本的經理
在標注關注點時，如下的問題引起了我的思考：
項目的管理到底是組織管理還是成本管理？
項目的計劃到底是組織規劃還是成本計劃？
簡單的說：項目管理要不要考慮成本問題？
現在，我們從一個細節跳出來，來看看我們的角色。
這個細節就是：如何完成今天的工作。
正如前面所說，如果你是一個軟件公司里的項目經
理，你可能今天的工作是寫一份項目計劃案，或者聽測試
部的報告，又或者是安排會議來聽取和分析一個新的產品
需求。然而，我需要說的是：
這是細節。
細節就是你使用的 Project 2003，或者你正在公司內
部署和推廣的 ClearCase。如果它們正好是你今天要完成
的工作，或者是你明天要用來工作的工具，那么，作為項
目經理的你，現在就要立即跳出來。
理想狀況下，“軟件工程=過程+方法+工具”。然而工
程成功的真正關鍵，并不在于你把你的團隊“組織”得有
多好。即使在團隊中他們都顯示有條不紊，你一樣會面臨
失敗。
螞蟻的團隊總是被本能地組織得非常好。然而如果一
個螞蟻的群體中有了流行疾病，螞蟻在死去，而新生螞蟻
不能跟上其死亡的速度，那么很快，這個團隊就潰散了。
這是因為螞蟻用于維護團隊運作的“資本”在流失。
如果資本沒有了，就沒了運作，團隊的存在就沒有了必要
性和可能性。
項目就死亡了。
埋頭于畫甘特圖的項目經理犯下了與挖山不止的愚
公類同的錯誤：忽略了成本。
如果愚公真的可以成功，那么可能是 300 年之后。然
而如果一個工程要 300 年才能做成，那么在做成之前，客
戶就選擇了放棄。
如果有機會，項目經理可以選擇向另一家公司購買一
個產品來賣給客戶，從“為客戶開發”變成“為客戶定制”，
以及“為客戶服務”。這樣在沒有任何開發成本的前提下
完成了工程。與另一個同樣極端的例子相比，你會發現它
與第五章中那個“做過場”的項目全然不同。后者是做完
了工程，卻沒有做成工程。而現在這個項目經理卻做成了
工程，但是在許多的過程環節上，他根本就沒有開始。
然而現在，除了躍躍欲試的技術經理之外，沒有人會
不滿意這個結果。
技術經理最常說的話是：我們可以開發出來；開發人
員最常說的話是：我可以開發出來；愚公最常說的話是：
何苦而不平？
還記得那句話？——不要栽進螞蟻洞里！
愚公如果停下來，思考的問題可能是碎石的“方法”。
而項目經理從細節中跳出來，思考的問題就應當是完成工
程的“方法”。評價這個方法的好壞的標準只有一個：節
約成本。
Y 公司由 K 公司過渡而來的時候帶來了一個市場前
景非常看好的產品。而存在的問題則是兩方面的，一是擴
大市場占有，二是繼續的技術投入。
于是，Y 公司請來了專家 D。他是一個在行業中摸年
爬滾打了多年的顧問型專家，做過公司，也在無數個公司
做過。D 先生的項目計劃可能是無可挑剔的，但其投資規
模決定了它無法實施；D 先生在一些產品計劃上的思考上
也是切近市場的，然而他沒有學會如何為團隊爭取到兩名
以上的開發人員；D 先生在部門管理上的方法也是適當
的，然而他忘記了訓練部門人員以使他們與自己保持一致
的步調和方向(組織和管理一個松散的團隊比照顧一群螞
蟻難得多)。
于是在 Y 公司建立到倒掉的四年時間里，D 先生三
進三出，營銷計劃一再被否決，而產品的再研發計劃也數
度擱置。很快，這個并不生動的故事被終結于我跟他的最
后一次會談：三年之后，產品徹底從市場中退出。
——思考成本，這是 D 先生給我的教訓：
不計成本的項目計劃不會得到經營者的支持；
毫無目的地消耗成本是項目中的慢性毒藥；
最致命的風險是成本的枯竭①。
4. 審視 AOP
我讀到的第一篇關于 AOP 的文章居然說它是“新一
代的 java 語言”。OH，正如文章的標題所表現的那樣，作
者大概是在學習如何向方格子里填寫“錯誤”：其結果當
然是每一個格子都是“錯誤”。——如果他象小學生一樣
勤奮的話。
AOP 不是語言。AOP 首先是方法論，這就象 OOP 是
“面向對象的編程方法”是方法論一樣。而 Delphi／C++
才是語言，是對這個方法論的一個實現工具。
① 我經常注意到的成本因素包括時間、人力、資金和客戶成本。
而大多數情況下，人們不會把客戶的數量以及耐心當做(客戶)成本
來計算。而在我的項目規劃中，這是成本。
很好，有了這個基礎，我們再來討論相似性的問題。
我們提到過開發方法是基于一種數據結構的編程實踐的
結果。很顯然，OOP所基于的數據結構是對象(Object)，
而AOP所基于的數據結構就是方面(Aspect)①。落足到開發
工具的實現上，Delphi將Object表現為一組有(繼承)關系的
“記錄(Record)”②。相對應的，Java將用類(Class)來實現
Aspect。
Aspect 在定義時沒有確定的對象模塊，Aspect 本身只
是對一個“對象模塊群體”的觀察視角，因此它更易于表
現成接口。——只有描述而沒有實現。
在 Object 一層的抽象上，Object 關注于“有繼承關系
的考察對象”的個體特征；而在 Aspect 一層的抽象上，
Aspect 關注于“有相似需求的考察對象”的群體特性。其
相似性在群體中表現得越廣泛，則 AOP 的優勢也就越明
顯。例如在 Delphi 的 VCL 框架中，以下兩個需求就可以
① 人們在爭論Aspect到底應該譯成“切面”還是“方面”這件事上
花了很多功夫。其實，就如同討論前面的“關注點”究竟是“點”
還是“線”的問題一樣，他們陷入了細節。如果這些細節被作為
問題持續下去，那么可能有一天臺海戰爭將不是發生在軍隊之間，
而是在程序員之間：到底是“物件”，還是“對象”？
② 在C中，這個名詞是“結構(Struct)”。很多人不會承認“對象是
有繼承關系的記錄”這樣的觀點。是的，所有的教科書上都不會
這樣寫。但是從數據結構本身以及數據結構在語言中的實現來看，
對象終究是記錄。記錄是平板化的內存存儲體系中所能表達的最
復雜的單一數據體。
用 AOP 的思想來實現：
使 Delphi 中的全部對象具有多線程特性(即線程
安全)；
實現助手工具類以觀察、控制 Delphi 對象的運
行期特性或表現。
到現在為止，我們弄清楚了 AOP 作為“思想、方法、
工具”的一些基本知識，以及它的應用范圍：至少你要明
白，他是用來考察對象(而不是設計對象)的思想方法。
所以接下來 AOP 的三個概念我們就明白了：
指示(advice)/攔截器(interceptor)：考察這些對象
以“達到什么樣的目的”(即需求)；
引導(introduction)：在目標上實現這些需求時，
目標所需要表現出來的公共特性。引導特性可能
需要配合編譯器來實現。
元數據(metadata)：如果需要，為既有對象實體
再補充一些參考數據。
確切的說，切分點(Pointcut)并不是 AOP 編程方法所
需要的概念，而是 AOP 作為一個框架時所需要的一個工
具：一組辨識 Acpects 和 Objects 的索引。
現在你已經會用 Acpect 的思想來編程了，而無論它
是用 Java 來實現的，或者是用 C#、Delphi，乃至于
FORTRAN 或 COBOL。你需要做的是，回到工程最核心
的那個環節：編程＝算法＋結構＋方法。
5. 審視 MDA/MDD
MDA(Model Driven Architecture)也是一個方法論層
面上的名詞。它討論的是“創建出機器可讀和高度抽象的
模 型 ” 的 方 法 。 受 MDA 影 響 的 開 發 活 動 被 稱 為
MDD(Model Driven Development)。
與 MDD 在同一個層面上的概念是：
TDD(Test Driven Development)
FDD(Feature Driven Development)
BDD(Business Driven Development)
R-TDD(Rapid Template-Driven
Development)
CDD(Contract Driven Development)
RDD(Requirements Driven Development)
...
我不厭其煩地羅列這些名詞，只想告訴讀者一個事
實：什么都可以“驅動開發”。
不同的方案提供商基于自己的產品構架和當前的理
論傾向，隨時都在準備改變他們“驅動開發”的方式。在
這種形勢下的 “xDD”或“xDA”，已經成為他們促銷產
品的保留用詞。
回到軟件工程的過程環節中來吧，你會看到，“以什
么驅動開發”只是一個“以哪個環節為中心(或導引)”的
問題。所以你會看到 TDD 中的 X 模型(也可參考 V 模型)
是這樣的：
如果你仍舊不能明白為什么會有這么多被神秘力量
所“驅動著的開發”，那么你就干脆去廚房找個平底鍋燒
點熱油，然后敲下一個雞蛋，很快，你就體悟“以蛋黃驅
動開發”的真諦了。
拋開實現的技術細節不論，在工程中，“以什么驅動
開發”其實是一個過程問題。而你應該明白，過程的選擇
(或制定)取決于你的工程需要，以及它在相關應用領域的
適用性、過程工具的充備性和這個過程理論的完善程度，
而不是大公司們的鼓吹。
過程模型決定了工程的實施步驟和組織方式。但是Object Management Group (OMG) 盡管對 MDA 提出了一套完備的技術和方法體系，工程實施者卻無法在這個體系中找到一個可以適用的軟件過程模型。——MDA 不討論過程。
也就是說，MDA 架構作為一個新的軟件開發方法的架構，即使在技術研究、底層協議和軟件實現方面經過了持續地完善而漸至成熟，然而如果沒有同樣成熟的軟件過程理論支持，那么它在工程中的實用價值也就有限。
仔細審視一下這個 MDA，如果你現在就決定將下一個工程項目建立在這個構架的基礎上，或者用 MDD 的方式來開發 BIOS，那么你離精神病就不遠了。
周愛民(Aimingoo) 2013-08-24 22:35:59
評論集
暫無評論。
稱謂：
内容：
驗證：
返回列表