業務系統的開發經驗小談

概要

• 關鍵要素：業務理解 + 系統架構 + 技術集合 + 迭代開發 + 嚴謹測試
  
  

業務理解

業務從何而生？ 一個具體的場景下遇到了問題不知道怎麼解決或解決的辦法很原始很笨拙，由此而產生了需求：在具體場景下須要解決某個問題，或者以更優的方式來解決。解決後，實現某事的效率大幅提高，進而促進總體的效益。

對業務有總體而深刻的理解， 才能設計出更好的系統架構來容納業務的有效處理和擴展。

業務抽象

業務可抽象爲：1. 需求層面：用戶故事與需求； 2. 語義層面：實體、關聯、約束； 3. 實現層面：流程、規則與數據。

• 提煉用戶故事是業務抽象的首要。需求一般能夠講述爲一個簡短的用戶故事：用戶在某種場景下須要實現某個目標，他須要經過執行某些步驟來完成這個任務。提煉出多個關聯的用戶故過後，就能夠考慮在建模層面來思考。

• 業務系統一般會有一個核心業務模型， 這個核心業務模型由如下要素組成： 重要的業務實體及其關聯和約束、使系統可以RUN起來的業務規則集合。

• 上層是「實體+流程+邏輯」。 經過業務實體及其關聯， 組合以業務流程及規則，完成各類業務功能。

• 底層是 「數據+規則」。 數據是核心，規則是外延。「數據+規則」 構成了業務系統的底層視圖。

• 必須發現那些使得系統運做起來的充分必要條件，即「總體規則」，這樣的規則一般由一系列子規則組合而成，每一個子規則規定了相關的構成子部件必須知足的充要條件。好比， 爲何 Ajax 可以異步刷新頁面？　爲何 XEN 可以讓多個虛擬機運行在一個機器上？而要發現這些規則，必須像科學家那樣充滿好奇心地去探索、嘗試、挖掘和創造，而不只僅只是照搬其成果。

• 將使得系統RUN起來的核心業務流程與規則集合梳理出來， 實現具體業務功能時就有據可依， 以不變應萬變， 可以更好滴考慮系統的可擴展性； 一旦完成核心業務規則的編寫，接下來能夠充分地考慮各類錯誤條件和異常檢測，加強系統的健壯性和一致性。

• 業務功能開發，便是在不一樣子系統之間傳輸數據以及在不一樣層次對各個來源的數據使用不一樣的規則進行檢測和組合， 從而使得系統 RUN 起來， 或者快速返回錯誤。 當編寫代碼時， 最核心的就是使系統RUN起來的核心業務流程與規則集合。

數據基礎

• 數據是一個業務系統的中心要素。整個的技術的做用最終是使得數據可以在其生命週期內在系統內順暢、正確、一致、高質量而低成本地流動；

• 數據源的生成和維護；數據的採集、傳輸、計算、存儲、去向；

• 即便是前端設計和開發，也會發現：本質上就是： a. 從服務端拉取數據；　b. 讓數據在頁面間流暢而安全地傳遞；c. 使用合適的組件展現得更加直觀易讀。

• 數據存儲是業務系統的關鍵導圖。 經過分析數據存儲設計， 理解該系統負責管理哪些數據， 能夠推出該系統所涉及到的重要業務實體。

評估量級

經過對用戶故事的提煉和梳理，預估業務量級，能夠在架構設計層面作出更好的決策，下降實現和運維成本。好比，限定時間範圍搜索，限定某些篩選條件搜索，減小須要考慮的活動業務量，就能夠減小分庫分片的須要，一樣達到相同的目標。

系統架構

• 架構能夠分爲開發架構、部署架構、產品架構、業務架構；程序員經常接觸到的是開發架構和部署架構；

• 開發架構的主要做用： 1. 良好的工程結構與總體設計，簡化業務邏輯處理模式，使開發者更專一於實現業務處理邏輯； 2. 選擇適合的長遠的技術集合，使得業務系統具有良好的可擴展性和持久發展；

• 部署架構須要關注多個應用之間的依賴關係，梳理這些關係，進行服務化治理和服務可用性監控；

• 業務功能的正確性和可維護性一般取決於數據庫設計、如何存取和更新資源記錄；性能與可靠性取決於算法與系統總體架構；

• 持續提高代碼可讀性，Keep Code Clean， 很是有益於系統的快速理解、維護和擴展。

技術棧

概覽代碼組織結構

• 代碼組織結構是業務系統的最明顯的總體特徵， 勾勒了系統的基本構成。

• 一般會按照兩種方式劃分： 按照業務模塊劃分； 按照組件模塊劃分。

• 熟悉代碼的組織結構，可以儘快地增長對系統總體的印象， 瞭解代碼該放在何處。通常 Java 業務系統都會劃分爲 controller, service, dao 三層， 此外會有一些基礎設施做爲輔助， 好比緩存、線程池、異步任務流框架等；
  
  

通讀配置文件

• 通讀工程的配置文件， 能夠得到該系統的很多重要信息。

• 對於Java業務系統而言，通常包括：IOC/AOP/ORM， 線程池/緩存/框架配置、第三方調用與服務、消息中間件、定時任務、對外提供的服務或接口等。
  
  

熟悉使用的技術及框架

• 一般在參與一個業務系統的開發以後， 會對業務系統裏使用到的技術和框架有基本的認識，而Java業務系統所使用的技術和框架每每是大同小異，所以， 經過瀏覽工程裏的代碼組織結構和配置文件， 大體閱讀裏面的一些重要類， 一般就能夠了解到這個系統所使用了哪些技術和框架。
  
  

熟悉子系統之間的交互

• 對於一些中大型業務系統， 一般會涉及到多個子系統之間的交互；

• 一箇中大型業務系統可能包含openapi, 二方庫以及提供二方庫實現的內部服務系統， 或者可能會包含一個對外的api，一個控制調度系統和多個分佈式節點的執行子系統。

• 熟悉子系統之間的交互， 會對總體業務的實現有更好的認識。
  
  

從重要業務操做及代碼着手

• 只讀不寫是難以真正深刻到系統的。所以， 最好可以從一個重要業務操做着手， 或者能參與到項目的重要業務功能的開發中，就能將以上全部元素的理解串聯起來， 造成對系統業務的實際理解。

迭代開發

開發主流程

1. 熟悉系統的總體設計、主要技術棧以及運行部署；

2. 持續溝通並理清業務處理邏輯；

3. 仔細分析其中的重難點問題，確保在真正投入時有可接受的解法；

4. 制定開發計劃和進度表；拆分任務，做出todo列表；

5. 開發/測試/持續改進的交替進行；嚴格測試，保證 UT, FT 和 測試用例經過。

6. 細緻周全地處理異常。

7. 反饋、維護、改進和文檔化。

　

細則

• 需求討論須要具有「條分縷析」的耐心和能力，像蠶食桑葉同樣把每一個業務小點都梳理清楚不含糊。 儘量反覆完全與業務方、產品經理、工做夥伴詢問和討論清楚業務需求，定義清晰的目標，梳理核心主要的業務流程，理解業務全景圖；切忌急於投入開發。

• 概要設計須要通悉常規的設計方法，主要是業務實體設計、數據庫設計、業務流程圖繪製等。平時也要多瞭解各類設計方法和實現，才能在須要的時候運轉自如。

• 詳細設計須要不急躁且不過分的平衡。不急躁是指必須先將技術難點攻克再投入實現的方法，避免方案有難以解決的瓶頸而致使返工，不過分是指不要沉迷於完美的前期設計。只要方案可以解決問題，實現可接受的性能和可擴展性，就能夠開始投入了。

• 數據庫設計中，根據業務目標肯定業務實體及其關聯、數據模型，設計正確的數據庫表，或增長合適的字段。

• 若是業務功能須要多個子系統協做完成，則須要總體佈局能力，明晰和合理分配每一個子系統的責任。　　

• 投入開發以前，制定開發計劃和進度表是值得嘗試的。自主地有效管理本身的開發活動，儘量接近於可控時間範圍內按時按質完成任務。對本身的管理能力也是很好的挑戰和磨鍊。

• 開發的基本方法是「拆分」與「鏈接」。不管多麼複雜的邏輯，總能夠拆分爲一系列的邏輯小塊；而後，將邏輯小塊鏈接起來，從而使得系統可以ＲＵＮ起來。能夠採用意圖導航編程法。不急於寫實現，首先編寫一系列空方法，在方法的註釋中表達其意圖，還能夠增添開發評估時間，而後依次實現這些意圖。能夠有效地簡化複雜邏輯的開發，亦便於後續的測試和維護。

• 測試方面，單元測試儘量粒度小、覆蓋全；接口測試必須對重要的、典型的、常見異常的三類場景充分測試。後臺服務的測試儘量自動化，標準化測試環境，採用併發提高執行性能，下降測試時間成本。　

• 考慮子系統交互及部署結構；

• 在項目開發過程當中，或者已經上線後，　積極聽取反饋意見和持續改進，撰寫文檔持久化存儲從中所學到的知識。也是很是重要的一個環節。程序員不只要會寫代碼，也要善於表達本身的觀點和思考。只有寫下來才能真正理解所知所學。口說無憑。

實際開發技巧

業務處理模式

1. 檢測權限與可訪問性、日誌記錄（切面）；
2. 讀取請求，檢測參數有效性；業務處理邏輯、格式化處理結果並輸出；
   
   

代碼模式

1. 從數據庫或緩存中讀取資源記錄並檢測是否存在或是否合法；
2. 對底層系統或第三方系統發送指令， 作實際的業務處理；
3. 根據指令結果更新資源記錄。

• 總的來講： a. 拷貝數據； b. 使用規則檢測數據； c. 　聚合數據，使之符合使系統可以 RUN 起來的規則。
  
  

錯誤處理

• 暫時先「忽略」那些錯誤檢測，　肯定使得功能可用的基本核心的充要條件。當咱們發現使得系統運做起來的有效規則和充要條件後，　就很容易梳理那些錯誤條件了：　若是缺乏 X 數據會怎樣？　若是 Y 狀態不對會怎樣？　這些錯誤條件就變成系統中的各類檢測， 可以及早發現錯誤並返回，或者適當地糾正和提醒用戶。接着， 就須要考慮一些異常狀況了：　若是網絡中斷了會怎樣？　若是數據庫訪問超時了怎麼辦？　

• 設計階段：探索、挖掘和肯定使得系統運做起來的充要條件　 ＝> 　梳理錯誤條件，　肯定各類檢測條件　＝> 　考慮異常處理

• 編碼階段：編寫主流程代碼，　不考慮任何錯誤和異常　　　 ＝> 添加錯誤檢測，　分離到單獨的函數　＝> 進行異常捕獲
  
  

嚴謹測試

• 如今互聯網知名企業都逐漸在推行研發測試融合，「信任」開發可以也應該寫出合格的測試。

• 開發的測試主要包括單元測試和單接口測試。單元測試包括數據庫訪問層測試和業務邏輯中新增方法的測試；單接口測試主要是對系統公開的單個服務接口( http, dubbo ) 進行測試確保接口服務是OK的；固然，進一步有時還須要接口組合測試，即測試用例。
  
  

應牢記： 「開發軟件的本質是爲了幫助他人」。若是所開發的系統已經可以知足人們的須要，即便它是不完美的，也是足夠有價值的；反之，若是系統不能知足人們的須要，沒法幫助到人們，即便它看上去很ＣＯＯＬ，也是沒有價值的。即便不編程，也能夠經過其餘方式去幫忙人們。