說到業務是個讓人又愛又恨的東西，客戶、領導把它看的很重，不少“技術控”卻瞧不起它，認為它是“低智商”的代名詞。當然了，這些看法都很偏激。技術僅僅是一個工具，因“業務”的需求而誕生至使用，小說里常常寫到，當一個人學會了屠龍之術，卻發現天地之間沒有龍給他“屠”，這個是最悲慘的事情了，這里的“龍”就是業務，“屠龍之術”就是技術，離開了業務的技術是沒有意義的。
業務本身是個抽象的集合，真正把它搞懂了其實也能鍛煉人的抽象能力。
說來說去“業務”是個什么東西，似乎沒有明確的定義，我覺得“業務”就是個“標準”，程序員完成的系統必須滿足這個“標準”，不同行業，不同硬件環境都會有自己的合適的標準，某項技術都有其對應的“標準”。
比如一直討論很久的問題，C++和Java到底誰快，為此也有衍生出了很多討論，技術控也是樂此不疲，但是或多或少都脫離具體環境。
計算機語言發展了這么多年，都會相互學習優點，不過總有些本質的區別，比如C++的優勢是和硬件結合緊密，Java的優勢是屏蔽了硬件限制，兩者在誕生的時候發展的方向就有不同，比如通信系統的交換機等各類硬件的程序非C/C++莫屬，Java在這里難有使用的地方，但是在異構硬件集群中，現在很火的“云”系統，Java的優勢就很明顯，現在常用的服務器系統大多都是Java。當然也有人說Java免費，所以比C++更容易推廣，的確沒錯，但是這也屬于“業務”的范疇。
說完了業務的大范圍，下面說說具體行業的業務。我最熟悉的是電信的業務。相比金融、電商系統，從網上的信息來看似乎電信的系統是最沒技術含量的，其實電信的數據量遠大于金融、電商，只是大量的數據是后臺處理，可以異步展現，所以給的要求并不高，總體來說電信系統是入門的技術低，做好了很不容易。
我和不少電信的程序員人聊過，他們紛紛吐槽是，工作就是配置各種業務參數，體力活。但是說到具體的業務模型時，卻說不清楚。
我總結的電信系統分2兩大部分，業務模型（CRM）和工作流（IOM）。CRM和IOM是比較老的名詞了，新的我也不太清楚。
模型如下：
主產品+子產品+產品規則+動作
解釋如下：
主產品，和硬件掛鉤?，F在的電信產品有手機（移動，聯通，電信分屬不同網段）、固話、ADSL、光纖、2B+D、30B+D等。
子產品，依賴于主產品。比如移動電話的各種優惠包，寬帶的互聯星空等。
產品規則，這里是最讓人抓狂的。產品規則分3類、
1、主產品規則，主產品之間是沒有任何關系的，比如一家人可以裝兩條寬帶，用多個手機。
2、子產品規則，基于不同主產品的子產品之間沒有任何關系，基于同一主產品的子產品之間有各種規則，比如手機的資費包開通了一個就不能開通另一個，這類為互斥。不同的優惠可以共同作用，這類為疊加。由于各種子產品的數量繁多，所以這些規則的校驗和實現是個很龐大的數字。
3、運營商制定的規則，比如，從硬件角度來說，裝寬帶、裝電話、開通手機是互不相干的，但是運營商制定了各種套餐，“強迫”統一辦理。這個無論是對程序員還是消費者都是是很討厭的……
動作，裝、拆，（改=裝+拆）
分析完了以后可以發現真正麻煩的地方是業務規則這塊，一個電信客戶系統的質量高低很大程度上就由這個“業務規則引擎”決定，如果只是悶頭往這個引擎里加參數的確無聊，但是這正了解這個引擎的工作步驟還是很有趣的，個人認為理解一個系統的運行是很容易提高能力的。
下面說說“工作流”，消費者的任何一個請求在電信系統中都會轉變一個流程，某些特殊的業務流程會很長，比如裝高清寬帶，需要人上門施工，并測試寬帶質量等，這些都成功了才會觸發其它的步驟。消費者的業務請求在后端實現往往是“事務”型的，比如原來是套餐A，改成套餐B的會有3個步驟，不熟悉電信業務的人可以想下“神州行”改“全球通”。當步驟1和2施工成功后，步驟3發現現有條件不滿足時（這里的判斷不在當前系統中，或者說當前系統無法判斷，必須將數據發送到另一個平臺之后由那個平臺來判斷，這種情況在電信系統里很常見，比如當前系統沒有客戶資料，所以無法判斷），也就意味著不能辦理套餐B，這樣得回復成套餐A，這樣需要對步驟1和2得進行反向施工，也就是“事務回滾”。先后這就是“工作流”的任務。
工作流在電信系統中是很重要的角色，相比于是電商和金融系統，電信系統的工作流最強大。
簡單解釋下工作流，工作流有兩個最基本單元(節點)，邏輯節點和工作節點(不同的系統中叫法也不同，但是作用都一樣)。
邏輯節點，就是if判斷。
工作節點，就是一個具體的施工環節，一般關聯一個平臺。
一般工作流的具體配置都由這兩種節點組成。
工作流定義的關系有，串行和并行(電信里的叫法是同進同退，一般直接定義成事務)。
于一個系統來說，業務層的調優效果優于代碼層的調優效果(代碼錯誤引起的宕機問題不屬于調優范圍)。比如，一個業務的判斷規則精簡了，比你優化幾個計算語句強的多。比如之前說的例子，在步驟1、2、3中，因為3出了問題，導致1、2得反向施工，所以實際有5步操作，1、2、3、2反向、1反向。所以如果3最容易出問題，那么應該調整順序應該是3、1、2，把最容易出問題的放在最開始，這樣可以避免不必要的步驟。其實在系統上線后運行一段時間，就可以統計出那些平臺的出錯率高，調整順序幾乎是0修改，但是帶來的效率提升是明顯的，但是沒有幾個地方有這么做的。
說了這么多，我覺得把整個系統的框架搞明白還是很能提高個人能力，抽象邏輯對于程序員來說必不可少。所以現在每次抱怨工作無聊時，我都會想想，真的就不能挖出點東西么？