1.大公司手中的算盤
　　從最早僅僅關注于軟件開發工具到現在，軟件行業中的巨頭們已經在層出不窮的思想中涅槃了一回又一回。
　　Rational被IBM并購的真實原因在于IBM需要構建一個完整的軟件工程體系，有了Rational的IBM會變成這個樣子(見表1)。

　　

　　

　　對于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是優疲訧BM用來削弱Borland在開發語言上的優勢的最佳手段，就是支持開源的Eclipse，以及用UML的標準化來確立其規范制定者的地位。然而你會驚斕姆⑾鄭珺orland一方面在支持UML的標準化，另一方面還在支持著Eclipse的開發并協助其快速成為一個完整的、具有商業品質的開發平臺。這似乎是極其怪異的戰略：幫對手磨劍。

　　如果Borland只為一個對手磨劍，那他可能是一個傻子。但問題是，Borland幾乎為他所有既已成為（或者終將成為）對手的人磨劍：Kylix是Linux平臺上的產品；C++ Builder、C# Builder、CBX、Delphi是Win 32和.NET平臺上的產品；JBuilder則是Sun平臺上的產品—— 一切正如Borland自己說的那樣，他是“(語言、平臺和技術)中立的軟件廠商”。

　　Borland走在鋼絲繩的中間，對他的考驗是平衡的藝術和技術：如果他倒下，鋼絲繩兩端的任一方都來不及施以援手；然而如果他存在，那么他向哪邊邁出的一步，就給對方以最大的壓力。

　　“敵人的敵人就是自己的朋友”，聰明的戰略家總是能看到這一點。然而Borland卻力圖使這個敵我都分不清的戰場呈現出一種古怪的格局：一方面Microsoft是Borland的股東之一，另一方面Borland在做Sun、IBM以及Linux平臺上的軟件提供商。

　　與Borland和IBM通過通過并購來達到目的方式，Microsoft有足夠的力量全方位出擊，因此你看到的體系如表3所示。

　

　　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不描述工程元素間的關系，甚至在試圖割裂這些元素以使得工程角色定位以及各自的視角更加清晰明確。

　　從這個模型中可以看到，在“程序”與“方法”層面，是關注于“(具體的)實現”的；而在“過程”和“工程”層面，首要考慮的是團隊問題。從角色的角度上來說：開發經理思考項目的實施方案和管理具體的開發行為；而項目經理則保障團隊的穩定性和一致性。
然而這只是基本模式，或者說，是理想模式。

　　3.思考項目成本的經理
　　在標注關注點時，如下的問題引起了我的思考：
　　項目的管理到底是組織管理還是成本管理？
　　項目的計劃到底是組織規劃還是成本計劃？
　　一言以蔽之：項目管理要不要考慮成本問題？
　　現在，從一個細節跳出來，進而分析我們的角色。這個細節就是：如何完成今天的工作。

　　正如前面所說，如果你是一個軟件公司里的項目經理，你今天的工作可能是寫一份項目計劃案或者聽測試部的報告，亦或安排會議來聽取和分析一個新的產品需求。然而，我需要說的是：這是細節。

　　細節就是你使用的Project 2003，或者你正在公司內部署和推廣的ClearCase。如果它們正好是你今天要完成的工作或者是你明天要用來工作的工具，那么，做為項目經理的你，現在就要立即跳出來。

　　理想狀況下，“軟件工程=過程+方法+工具”。然而，工程成功的真正關鍵并不在于你把你的團隊“組織”得有多好。即使在團隊中他們都顯示出有條不紊，你一樣會面臨失敗。

　　螞蟻的團隊總是被本能地組織得非常好。然而如果一個螞蟻的群體中有了流行疾病，致使螞蟻死去，而新生螞蟻不能跟上其死亡的速度，那么這個團隊很快就潰散了。

　　這是因為螞蟻用于維護團隊運作的“資本”在流失。如果資本沒有了，就沒了運作，團隊的存在就沒有了必要性和可能性。項目就死亡了。
　　埋頭于畫甘特圖的項目經理犯下了與挖山不止的愚公同樣的錯誤：忽略了成本。

　　如果愚公真的可以成功，那么可能是300年之后。然而如果一個工程要300年才能做成，那么在做成之前，客戶就選擇了放棄。
如果有機會，項目經理可以選擇向另一家公司購買一個產品來賣給客戶，從“為客戶開發”變成“為客戶定制”以及“為客戶服務”，這樣就在沒有任何開發成本的前提下完成了工程。與另一個同樣極端的例子相比，你會發現它與前面那個“做過場”的項目全然不同。后者是做完了工程，卻沒有做成工程。而現在這個項目經理卻做成了工程，但是在許多的過程環節上他根本就沒有開始。

　　然而，現在除了躍躍欲試的技術經理之外，沒有人會不滿意這個結果。
　　技術經理最常說的話是：我們可以開發出來；開發人員最常說的話是：我可以開發出來；愚公最常說的話是：何苦而不平？
　　還記得那句話嗎——不要栽進螞蟻洞里！
　　愚公如果停下來，思考的問題可能是碎石的“方法”。而項目經理從細節中跳出來，思考的問題就應當是完成工程的“方法”。評價這個　　方法的好壞的標準只有一個：節約成本。
　　Y公司由K公司過渡而來的時候帶來了一個市場前景非常看好的產品。而存在的問題則是兩方面的，一是擴大市場占有率，二是繼續技術投入。
　　于是，Y公司請來了專家D。他是一個在行業中摸爬滾打了多年的顧問型專家：做過公司，也在無數個公司做過。D先生的項目計劃可能是無可挑剔的，但其投資規模決定了它無法實施；D先生在一些產品計劃上的思考上也是切近市場的，然而他沒有學會如何為團隊爭取到兩名以上的開發人員；D先生在部門管理上的方法也是適當的，然而他忘記了訓練部門人員以使他們與自己保持一致的步調和方向(組織和管理一個松散的團隊比照顧一群螞蟻難得多)。
　　于是在Y公司建立到倒掉的四年時間里，D先生三進三出，營銷計劃一再被否決，而產品的再研發計劃也數度被擱置。很快，這個并不生動的故事終結于我跟他的最后一次會談：三年之后，產品徹底從市場中退出。
　　“思考成本”，這是D先生給我的教訓：
　　不計成本的項目計劃不會得到經營者的支持；
　　毫無目的地消耗成本是項目中的慢性毒藥；
　　最致命的風險是成本的枯竭②。

===================================================================================================================
===================================================================================================================
　　4.審視AOP
　　我讀到的第一篇關于AOP的文章居然說它是“新一代的java語言”。正如文章的標題所表現的那樣，作者大概是在學習如何向方格子里填寫“錯誤”：其結果當然是每一個格子都是“錯誤”——如果他象小學生一樣勤奮的話。

　　AOP不是語言。AOP首先是方法論，這就像OOP是“面向對象的編程方法”的方法論一樣。而Delphi／C++才是語言，是對這個方法論的一個實現工具。

　　很好，有了這個基礎，我們再來討論相似性的問題。我們提到過開發方法是基于一種數據結構的編程實踐的結果。很顯然，OOP所基于的數據結構是對象(Object)，而AOP所基于的數據結構就是方面(Aspect) ③。落足到開發工具的實現上，Delphi將Object表現為一組有(繼承)關系的“記錄(Record)④” 。相對應的，Java將用類(Class)來實現Aspect。
===================================================================================================================
　　③人們在爭論Aspect到底應該譯成“切面”還是“方面”這件事上花了很多功夫。其實，就如同討論前面的“關注點”究竟是“點”還是“線”的問題一樣，他們陷入了細節。如果這些細節被作為問題持續下去，那么可能有一天臺海戰爭將不是發生在軍隊之間，而是在程序員之間：到底是“物件”，還是“對象”？

　　④在C中，這個名詞是“結構(Struct)”。很多人不會承認“對象是有繼承關系的記錄”這樣的觀點。是的，所有的教科書上都不會這樣寫。但是從數據結構本身以及數據結構在語言中的實現來看，對象終究是記錄。記錄是平板化的內存存儲體系中所能表達的最復雜的單一數據體。
===================================================================================================
　　 Aspect在定義時沒有確定的對象模塊，Aspect本身只是對一個“對象模塊群體”的觀察視角，因此它更易于表現成接口——只有描述而沒有實現。

　　在Object一層的抽象上，Object關注于“有繼承關系的考察對象”的個體特征；而在Aspect一層的抽象上，Aspect關注于“有相似需求的考察對象”的群體特性。其相似性在群體中表現得越廣泛，則AOP的優勢也就越明顯。例如在Delphi的VCL框架中，以下兩個需求就可以用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，那么你離精神病就不遠了。
　　①我畫出的的確是線而不是點，“關注點”只是一個概念。如果你非要去發現一個“點”，那么你可以用幾何的目光，關注于弧線與直線的切點。然而，這樣的結果將是你徹底的忽視了“關注點”的本質含義。
　　②我經常注意到的成本因素包括時間、人力、資金和客戶成本。而大多數情況下，人們不會把客戶的數量以及耐心當做(客戶)成本來計算。而在我的項目規劃中，這是成本。

?