? ? ? Fred.Brooks在1987年就提出：沒有銀彈。沒有任何一項技術或方法可以能讓軟件工程的生產力在十年內提高十倍。
????????我無意挑戰這個理論，只想討論一個方案，一個可能大幅提高業務系統開發效率的方案。

方案描述

????????我管這個方案叫做“由基線擴展業務線的方案”。從名字就可以看出，它至少包括兩部分：基線；業務線。其實還有一部分隱藏在動詞后面：擴展點。這三部分及相互之間的關系大體上是這樣的：

基線

????????基線是一套領域模型、流程框架，但不包含任何業務的實際邏輯——即使是某種“通用”的、“默認”的邏輯。

????????基線中絕對不能混入業務邏輯，這是為了避免系統框架的“特化”。而系統一旦為了某種業務而進行“特化”，那么一定會在某一次業務變化中，系統要么像三葉蟲、恐龍那樣陷入死胡同；要么像總鰭魚、庫克遜蕨一樣，大幅改造自己。無論哪一種都是代價昂貴、難以接受的。因此，基線中絕對不能混入業務邏輯。
????????業務基線中不做業務邏輯，做什么？領域模型和流程框架。
????????領域模型描述的是這個業務系統關注哪些數據，這些數據之間有什么樣的關系、約束、依賴，必須在業務模型中描述清楚。這是整個業務系統的基石、首要問題：我們要做什么樣的業務。就像人類仰望星空時的第一問“我是誰”一樣，如何回答這個問題，決定了我們如何實現系統。

????????流程框架描述的是系統如何將數據組織、流轉起來，使之成為我們期望的業務。這個流程可以是一級分發、二級分發、實際處理；可以是校驗、預處理、核心邏輯、后處理；也可以是迭代、是遞歸、是鏈式、是并發……等等，這些都可以具體問題具體分析。

????????但是，盡管可以具體問題具體分析，無論是數據結構、還是流程框架，在實現上一定要保證高度的擴展性。這就是這個設計方案的第二部分：擴展點所重點關注的目標。

擴展點

????????由于基線中并不包含業務邏輯，我們必須在基線中埋入若干擴展點。否則，業務邏輯就無法按照基線中的流程來運轉。
????????借助于面向對象的繼承和泛型等特性，我們可以很便捷的擴展領域模型中的數據結構。但是流程框架中的擴展點，要更復雜一些。
????????從最簡單的方面來考慮，我們同樣可以利用繼承、泛型和多態，以及各種設計模式，來將原有的一套代碼擴展為另一套新的代碼。然而，我們如何讓基線代碼執行到某個擴展點時，流轉到特定的業務代碼上去呢？
????????詳細的解決辦法可以有很多，比如我之前總結的分發模式。一般來說，都是利用一些依賴倒置（例如SpringIOC）或者服務注冊等方式，在適當的位置上讓業務流程走向不同的代碼分支。

????????例如上圖中，基線右側的流程框架被分為三條分支。其中最上方的流程分為三個步驟；中間的流程以循環方式，依次執行兩個邏輯；最下方的流程又再次被分為三個分支。
????????那么，這條基線的擴展點，就可以是一個工廠+策略（對應三個分支的分叉點）、一個模板（對應最上方流程）、一個責任鏈（對應中間流程）、以及又一個工廠+策略（對應最下方流程）。
????????其中，這兩個分支判斷所需工廠的具體實現，可以是Map<Enum,Service>、或者Express-Service、抑或Regular-Service。這些機制可以輕松地把我們為某個業務而擴展出來的Service注冊、插入到由基線定義的流程框架中。
????????總之，有了擴展點，我們就可以把具體的業務代碼加入到基線流程中，使之成為一條獨立的業務線了。

業務線

????????就代碼而言，業務線實際上并不是一條“線”。它往往只是針對一兩個擴展點而開發的代碼。實際上，只有在這些代碼注冊到基線中之后，它才能成為一條“業務線”。
????????盡管如此，我還是把它單獨地畫在了整個方案的最下方（擴展點的下方），就像這樣：

????????上圖中展示了三條業務線分別擴展基線、并注冊到基線中去的情況。如果再有新的業務線加入其中，可以依樣畫葫蘆。

實踐

????????實際上，這個方案是我在xx公司參加一個業務系統的改造開發過程中，逐步整理、積累出來的。所以，在這個業務系統中，我實踐了這套方案的大部分想法。
????????沒有實現的想法主要是基線中不能包含業務邏輯。一方面，基線的業務流程中包含有業務邏輯：這是一套“默認”邏輯。也就是說，如果一條業務線沒有任何特殊的地方，那么它就會按照基線中的“默認”邏輯進行處理。但是，這導致了后期大量的業務代碼以“默認邏輯”的名義涌入基線中，使得基線越來越特化、退化為一條“業務線”——盡管它是“默認”業務線。另一方面，領域模型中沒有配置擴展點。這導致一套數據結構中包含了所有業務線所需數據。這也是“默認邏輯”不斷擴大的一個“元兇”：數據結構中的每個字段都必須有“默認”值。

分析

????????“由基線擴展業務線”，這個方案的內容基本就是這樣。這個方案的優缺點都有哪些呢？這里簡單分析一下。

優點

????????這個方案的優點，基本都來自于它的高內聚低耦合特性。

高內聚低耦合

????????盡管高內聚低耦合在很多團隊中只是一句口號，但是這個設計實實在在地踐行了這一理念。基線對業務封閉，對擴展點開放；業務線對彼此封閉，對新業務開放。這樣高度的封閉與有限的開放保證了基線和業務線自身的高內聚和相互的低耦合。

完整的業務模型

????????由于基線中包含了完整的領域模型和流程框架，它就能代表系統的業務模型。這是這個方案能成功的一個前提；同時，這也是使這個方案出類拔萃的一個產出。
????????在我們的實踐中，這一點帶來了很大的好處。在改造之前，系統中的業務非常混亂。產品不知道完整業務流程，經常出現需求只覆蓋到一小部分流程、因而不斷進行修改，甚至出現前后矛盾的需求。開發也不知道完整的代碼流程，這導致了一個更嚴重的問題：產品怎么說開發怎么做，完全沒有技術上的考慮和設計。測試同事反而是最熟悉完整流程的人，但是測試階段太靠后，發現問題時往往為時已晚。
????????而完成改造后，變化首先出現在開發身上。開發人員對業務有了全局的掌控，開始和產品討論、甚至是爭論；此后產品給出的需求描述也更加準確、完善。

項目管理可控

????????項目管理的四個要點：范圍、工期、成本、質量，都可以在高內聚、低耦合的特性下得到有力的控制。
????????這是我們的實踐中改進最大的一點。在改造之前，產品提出需求之后，會問這樣幾個問題：開發同事們估計要改哪些地方？大概要多久？我們開發只能回答不知道，回去翻翻代碼再說、問問老同事再說。在改造之前，我們代碼質量非常糟糕，無數的巨型Java類、重復代碼、超長的switch-case……
????????改造之后，我們對照基線梳理一遍，就能夠清楚地知道需要寫那些代碼、大約需要多久。而且，基線和擴展點大量運用設計模式、泛型、接口等編程方式，有效的提高了代碼質量。

技術易于演進

????????高內聚低耦合帶來的是高度的模塊化。在這樣的模塊化結構下，技術演進可以很輕松的推進。
????????在我們的實踐中，基線中的一個內部模塊前后經歷過四次重構和優化，包括同步改異步（后來又改回了同步）、對接外部系統、SQL優化、以及數據庫結構變更。盡管這個模塊負責系統核心業務，但它每一次變化都沒有影響到任何一個業務，并且都能順利地達成目標。尤其是SQL優化這項工作：在改造之前我們就曾經嘗試過，但因為代碼質量太差、模塊耦合度過高而放棄。

缺點

????????這個方案的缺點主要來自于它對業務模型的高要求。

建立和維護業務模型

????????建立模型本身就是一件困難的工作；讓團隊成員接受和理解這個模型，則是一項技術之外的工作；而讓團隊在后續的開發中維護這個模型，這幾乎只能靠上帝保佑了。
????????這三個問題中，只有建模可以稱得上技術工作；其它兩項主要是團隊中的組織和溝通工作。在這點上，“外科手術”式的團隊也許比敏捷團隊要更好一些。畢竟，“眾不可戶說”，將與模型有關的問題交給一兩個人來決定，其他人只需參謀和執行，這樣能減少一些建立和維護模型的問題。不過，如果能夠像敏捷團隊那樣，每個人都“自組織”地接受、理解、維護甚至優化模型，那簡直是求之不得的好事。
????????在我們的實踐中，團隊更類似于“外科手術”式。問題在于：團隊內的兩名權威——職級上的權威和技術上的權威——沒有對模型達成根本上的一致。這導致了團隊成員對模型的懷疑、誤解，更導致了模型以及代碼、系統的迅速腐化：基線中的業務代碼越來越多；業務線不斷突破彼此的邊界；新代碼的質量也大不如前。

代碼流程不連貫

????????盡管我私底下認為，這個問題的根本原因是開發人員不了解模型及其中業務的運作方式，或者是開發人員不理解“面向接口”、“面向對象”等編程思想。但是，鑒于這個問題在我們的實踐中被反復地提出，我還是把它記錄下來吧。
????????在這個模型下，實現業務的代碼會零散的分布在業務線、擴展點和基線中。這會給我們閱讀代碼、斷點追蹤和trouble shooting帶來一些麻煩。

束縛創新思維

????????這是一頂很大的帽子。一個業務模型規定了這項業務的處理方式——如何組織數據和流程。然而，這項業務就只能按照這種方式來處理嗎？顯然不是。然而，如果我們一味的泥于現有的業務模型，那么，遲早會出現這么一天：我們必須花費三倍、十倍的，才能把新的業務“塞進”這個模型中。這個問題已經很頭疼了，更不用說當我們需要主動地對業務進行全面創新（而不僅僅是升級換代）時，這樣“重”的一套模型會是多么大的一個負擔。
????????幸運的是，我們的實踐還完全沒有走到這一步。悲觀點想，也許根本就走不到這一步。

后記

????????我絕沒有真的自大到認為這真的是一枚“銀彈”，因為它甚至沒能把我們團隊的軟件開發生產力提高三倍。
????????但我仍然認為這是一個好的思路。不是銀彈——也許真的沒有銀彈——但是至少可以當顆大蒜。

本文轉自 斯然在天邊 51CTO博客，原文鏈接：http://blog.51cto.com/winters1224/1959644，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的是银弹吗？业务基线方法论的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。