業務系統的開發經驗小談

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

對業務有整體而深入的理解，才能設計出更好的系統架構來容納業務的有效處理和擴充套件。

業務抽象

業務可抽象為：1. 需求層面：使用者故事與需求； 2. 語義層面：實體、關聯、約束； 3. 實現層面：流程、規則與資料。

資料基礎

評估量級

通過對使用者故事的提煉和梳理，預估業務量級，可以在架構設計層面做出更好的決策，降低實現和運維成本。比如，限定時間範圍搜尋，限定某些篩選條件搜尋，減少需要考慮的活動業務量，就可以減少分庫分片的需要，同樣達到相同的目標。

概覽**組織結構

通讀配置檔案

熟悉使用的技術及框架

熟悉子系統之間的互動

從重要業務操作及**著手

熟悉系統的整體設計、主要技術棧以及執行部署；

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

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

制定開發計畫和進度表；拆分任務，作出todo列表；

開發/測試/持續改進的交替進行；嚴格測試，保證 ut, ft 和測試用例通過。

細緻周全地處理異常。

反饋、維護、改進和文件化。

細則業務處理模式

檢測許可權與可訪問性、日誌記錄（切面）；

讀取請求，檢測引數有效性；業務處理邏輯、格式化處理結果並輸出；

**模式

從資料庫或快取中讀取資源記錄並檢測是否存在或是否合法；

對底層系統或第三方系統傳送指令，做實際的業務處理；

根據指令結果更新資源記錄。

錯誤處理應牢記：「開發軟體的本質是為了幫助他人」。如果所開發的系統已經能夠滿足人們的需要，即使它是不完美的，也是足夠有價值的；反之，如果系統不能滿足人們的需要，無法幫助到人們，即使它看上去很ｃｏｏｌ，也是沒有價值的。即使不程式設計，也可以通過其他方式去幫忙人們。