過程塑造: （三）代碼是最終目的

意圖
無論哪一種過程，其最終目的都是為了產生出可執行、并且可用的軟件。因此軟件過程中的各種活動應該圍繞著快速、準確的實現這一目的而展開的。

示例
維力亞軟件公司是一家合資公司，由于有外資背景，公司內部很早就引入了軟件工程，并嚴格的對人員角色進行分工。包括領域建模人員、架構設計師、高級程序員、程序員、界面設計師等等多種角色。每個人各司其職，充分發揮出了分工的特點。但是隨著公司開發項目的逐漸增多，這種方式也顯露出其弊端來。每個人的主要目標都是為了通過評審，而有時候，就算是通過評審的工件，依然可能存在問題。但這時候扯皮就出現了。項目中存在的一些中空地帶。以及交錯地帶，常常發生無人問津的情況。開發過程的效率開始下降，開發成本開始上升。問題雖然不是一下子出現的，但是已經逐漸變得嚴重起來了。

上下文
我們在進行過程設計，或引入一個過程理論的時候，有沒有思考過該過程的每一個階段、每一個活動的目的是什么，它們對生成最后的軟件有什么樣的幫助，這些幫助對于我們所在的組織有意義嗎。很多情況下，我們并沒有這么做，或者隨著軟件過程的定型，就不再思考這類的問題。一開始并沒有什么了不起的，但是當軟件過程演變成了一種政治體系的時候，那么問題就會慢慢嚴重起來。

問題
如何讓過程圍繞著產出軟件的核心目標而不斷演進？

方法
從上一篇介紹的內容中，我們知道軟件過程的每一個階段都是知識轉換的過程，知識轉換的終點就是軟件。問題在于，我們如何保證這種轉換的效率呢？

現代軟件的發展的趨勢是重用。我們開發一個軟件已經很少會從最底層開始編寫了。我們使用各種各樣的技術和平臺。包括數據庫、分布式體系、UI機制、業務元素等等。因此現在的軟件編寫往往都是站在巨人的肩膀上開始的。不同的軟件組織，肩膀的高低也不一樣。比如有的軟件組織使用J2EE平臺，有的軟件組織則使用.NET平臺。但是可以肯定的一點是，每個軟件組織都或多或少的擁有自己的平臺體系開發經驗。這些經驗的表現形式也不盡相同，可能是保存在某些高級技術人員的腦中，也可能是保存為文檔、模型或代碼的形式。

對于單個的項目而言，其過程一定是從需求開始，以部署（以及后續維護）為終結的。但是對于長時間存在的軟件組織而言，更重要的是項目經驗、技術經驗、管理經驗的積累。這樣說可能過于抽象，我們舉一個具體的例子。在完成了一個庫存管理項目之后，我們把庫存管理的領域知識制作為商業組件的形式，而把項目中學習到的一些編碼的技巧整理為模式的形式，并把項目過程中積累的過程方法添加到現有的軟件過程中。這些經驗的堆積就是在一開始我們提出的可重用框架。對一個軟件團隊的來說，它的所有軟件項目都應該是圍繞著這一個可重用框架而展開的。

迄今為止，我們見過的大多數的可重用框架表現形式都可以總結為：以開發平臺為基礎，積累自己的商業組件，并以此為中心訂立開發活動。這種形式是不是最好并沒有定論，但我們是抱著學習的態度來研究它的。

以開發平臺為基礎的意思是軟件組織必須有自己所熟悉的開發平臺，其大部分的項目都是在此基礎上進行的。目前最流行的兩種軟件開發平臺是J2EE和.NET，但是就算是同一個平臺，不同的軟件組織對平臺內部的側重也是不同的（同樣對于J2EE技術，有的軟件組織可能把JSP和Servlet作為核心選擇，而另一些軟件組織則把重點放在EJB上）。選擇一種廣泛應用的、具有生命力的平臺技術是非常重要的。因為你的框架將會以此為基礎進行，而框架的轉移成本是非常之高的。雖然我們在一開始介紹的MDA思路為我們繪制了一副平臺無關設計的美好愿景，但是在目前階段，我們仍然要面對不同軟件平臺造成的嚴重隔閡。

必須指出的是，我們上面提到的開發平臺指的是在操作系統這個層次之上的平臺，也就是俗稱的中間件平臺。但是從中間件到最終的產品之間有沒有過渡的平臺呢。其實可重用框架就扮演了這一角色。軟件市場上已經出現了商業化的可重用框架了。IBM的SanFrancisco框架就是這種概念的代表。

平臺技術僅僅只是提供了一個技術，而軟件組織要生存和發展，還需要積累和發展自己的商業組件。并將商業組件發展成為可重用框架。商業組件的好壞，直接和軟件組織的能力、經驗，以及平臺技術相關。商業組件可能直接表現為代碼的形式（Bean、類、COM組件等），也可能只是描述性的記錄（文檔）。商業組件是經驗積累而成的。請注意，商業組件的設計并不完全等同于面向對象開發，因為面向對象只是一種技術手段，但是商業組件設計的優劣，更重要的是對業務的理解程度。舉一個最淺顯的例子，一個精通面向對象開發、面向組件開發的設計師，讓他介入他完全不了解的行業組件設計，他的表現將會大打折扣。

到目前為之，大家所認識的框架仍然是技術型的框架。但事實并非如此，框架還包括了外延的一系列軟件活動。這才是一個完整的框架。結合之前我們討論的軟件交付為開發目標。我們把這種開發方式稱為以可重用框架為核心，以交付為目標的軟件開發。這其實并不是什么了不起的概念，大部分的軟件組織都已經這么做了，只是沒有意識到自己的方式而已。了解這一點，能夠幫助軟件組織有效的改進自身的構架。

平臺技術和組件開發并不是本文的重點，因此我們在肯定了兩者的重要性之后，把精力轉移到軟件活動上。

在擁有一個框架核心（平臺和商業組件）之后，框架需要包含這樣的活動（或活動集）：收集項目需求，并將需求映射到核心構架上來。這其實就是需求階段到設計階段要做的事情。但是由于我們的活動是以軟件交付為目標的，因此我們需要明確的指出活動中的注意事項。

為映射工作設計需求描述規格。需求并不是一件容易的事。最難的莫過于尺度的把握了，例如需求要多詳細。使用現成的技術來定義需求描述規格，并根據核心框架的特點進行必要的擴展。例如，我們使用成熟的用例技術來描述需求，同時我們要求需求按照不同類的商業組件進行分類索引。用例技術的推薦讀物是Alistair Cockburn的Writing Effective Use Cases一書，該書目前已有英文影印版。