過程塑造: （四）一致性的思考

一致性原則是軟件開發中重要原則，也是最令人困惑的原則。做到完全的一致性將會導致高昂的成本，而不一致又會導致項目出現各種各樣的問題?？梢韵氲?，這又是一個需要權衡的問題。
意圖
軟件過程中的大部分工件都需要保持其相互之間的一致性?？墒?，工件越多，保持一致性的開銷也就越大。我們需要在一致性和成本之間保持平衡。

示例
天利軟件公司的項目經理正在為開發過程中出現的大量的不一致問題頭疼不已。從軟件過程一開始的需求階段，版本問題就一直困擾著項目組的成員。項目組的成員并非沒有經驗，只是這一次的項目規模超過了以往的項目，因此公司決定采用嚴格的過程，以保證軟件質量。開發過程中每個活動都必須產出文檔。第一次的不一致發生在需求調研中期的一次研討會上，當時的會議上發現了三種不同版本的需求規格書。之后情況越來越糟，文檔的數量不斷增多，由于所有的開發人員都需要編寫文檔、使用文檔，因此發生了各種原先沒有料到的事情，包括新文檔被覆蓋；設計人員手中的需求規格書不是最新的版本；設計書變更之后，代碼卻沒有相應的變更；代碼中的方法說明和設計模型中的方法說明不一致。為了對文檔進行控制，公司不得不從項目組中抽調了兩名開發人員來控制文檔，并加強了文檔的管理。但是隨之而來的是開發周期的延長。

上下文
一致性包括兩個方面：一是不同工件之間的一致性，二是使用同樣的方法來處理問題。

軟件過程的每個階段都需要產出不同的工件。典型的例如需求分析階段將產出需求規格書、用例模型、非功能需求等，設計階段產出設計模型、類圖。而在軟件開發中，我們常常會遇到需求的變更的情況，因此我們需要依次對我們的需求模型、分析模型、設計模型、代碼進行修改，以保持它們之間的一致性。如果項目處于前期階段，這種修改量并不大，因為工件較少，如果項目進行到后期。需求的改變將會涉及到大量的工件。對于期限比較緊張的項目而言（這似乎是所有項目共同的特征），這種成本幾乎是無法接受的。

另一方面，在同一個軟件組織中，解決同樣的問題有著不同的辦法。不同的人有著不同的編碼習慣、不同的目錄組織方式、不同的類庫、不同的框架。雖然我們并不反對同一問題的不同解法，但是當這種情況對項目的進展起到負面的效果的時候，我們就有必要來思考這個問題了。

問題
我們如何在一致性和一致性帶來的成本之間做好平衡？我們如何保證不同工件之間的一致性，又該如何保證項目中解決方法的一致性。

方法
首先，我們應該肯定，一致性這個問題并沒有標準的答案。不同的項目對一致性有著不同的要求。對于要求嚴格、規模龐大、涉及到一些重要領域的項目來說，一致性的要求是極為嚴格的。而對于一個小型的、較為無關緊要的項目來說，一致性的要求就低了許多。因此，和前面介紹的模式類似的，一致性的正確的答案只能夠從讀者自己的項目中去尋找。而這里提供的，是尋找該項標準的建議。

我們先從后者－解決方法一致性入手。
和這個標準答案相關的是一致性的程度。一致性的標準可大可小。大的標準包括了設計原則、軟件架構；小的標準包括用例的書寫格式、設計模型的注釋格式等等。由于大的標準對開發過程的作用最大，因此在進行一致性處理的時候，應該先從大的標準入手。在 代碼是最終目的模式中，我們提到了構架的概念。以構架為中心來制定標準，保證一致性是一種自然的思路。核心構架應該要能夠確定軟件開發的方向，這樣可以最有效的保證一致性，但是不要涉及到過于具體的細節，除非你對它們已經有足夠的經驗。而標準的深入程度則要取決于組織經驗、已有的軟件過程、項目規模等因素。

對于項目來說，一致性存在一個逐步精化的過程。正如我們上面所講的，一開始最重要的是引入核心原則，這里我們認為是可重用框架。對于可重用框架中已經明確確立的事項，必需要嚴格的遵守，因為框架中的內容是足夠穩定的，已經經過驗證的。這其實是重用思想的一種衍生。我們在 短期利益和長期利益的權衡模式中還會談到。如果有必要，引入的核心原則需要針對項目進行部分調整。例如，框架中根據項目的規模大小定義了用例的三種寫作模板，在項目開始的時候，我們會選擇其中最接近的一種模板，并根據項目增刪模板中的一些元素。而對于框架中不曾定義的，一些尚未明晰的事件，我們在項目初期不需要進行過于詳細的處理，而是隨著項目的進展來慢慢的完善它。例如，由于需求沒有確定，我們并不知道最后的設計模型是什么樣的，因此我們先根據框架定義，選擇JSP和Servelet作為主要的技術基礎，由JSP負責提供視圖，由Servelet提供業務邏輯。其它的信息則等待進一步的精化。

在項目一開始的時候，不要過分注意工件的修飾。例如，我們選擇的用例模板要求每一個用例都需要包括6種元素，包括主要角色、級別、前置條件、主要流程、備選流程、優先級。并規定引用其它用例的地方需要做出鏈接。但是在一開始需求調研的時候就按照這種標準完善用例將會提高成本，因為需求尚未穩定，我們主要的工作是盡可能完整的收集用例，而不是把時間花費在修飾用例上。因此一開始任何形式的用例描述都是允許的。你可以使用幾句話來描述用例（事實上，利用自然語言來描述用例有著圖形無法比擬的優勢），并用著重號標記出其中可能和其它用例相關聯的詞匯。這樣就已經足夠了，修飾的工作可以等到下一步來做。其它的工件也是一樣的。這時候的一致性的要求并不十分嚴格。

我們需要注意一些關鍵點（檢查點），例如在 知識接力模式中提到的需求復審。在項目接近這個關鍵點的時候，用例應該是已經根據要求整理完畢，可以接受復審了。粗糙的工件能夠迅速的創建，但是不容易讓人理解，也違背了一致性。因此我們雖然可以延遲工件的精化，但是這個工作是不可以缺少的，當然，精化的程度是可以變化的。利用關鍵點來保證工件的一致性也保證了信息傳遞的一致性（參見 知識接力模式）。