項目過程分解
通過本次消息中間件系統的全程參與，對於軟件項目從無到有的生產過程有了較深入的瞭解，尤其對於架構設計的決策過程和依據，有了全面的認識。整個項目過程從無到有依次可以分解爲九個過程，下面一一道來。
（一）背景分析
主要是要分析清楚三個問題：
1. 這個項目的訴求是在什麼業務現狀下產生的？
2. 最終要解決什麼問題？
3. 有什麼價值？爲什麼要做背景分析呢？
1. 更透徹的分析需求
所有的需求分析過程都要圍繞這上述三個問題來，不能偏離。
2. 更主動的做事；
當你做一件事情的時候，如果不理解爲什麼要做，只是單純的做事的時候，其實是缺少主動性的
3. 獲得上級的支持。
有了上級的資源（人力、時間）支持，項目能夠更加的順利。
（二）需求收集和分析
需求分爲兩類：
1. 功能性需求
功能性需求一般是項目組內分析得出的該系統需要具備的一些必備特性。對於消息中間件系統來說，如：發佈消息、拉取消息、訂閱……
2. 業務性需求
業務性需求一般是從潛在的系統用戶（周邊項目組）那收集到的一些業務特性和使用習慣，針對這些業務特性和使用習慣，分析我們的系統是否能滿足。對於消息中間件系統來說，如：業務系統習慣主動推送消息，不希望拉取消息；業務系統熟悉MySQL，希望底層存儲使用MySQL；業務系統現有方案的數據格式是JSON，不希望換數據格式。對於業務性的需求，我們要有所區分和取捨，不一定所有的業務特性都能夠同時滿足。
（三）業界方案研究
基於背景分析和需求收集分析，收集類似的實現或方案。通過對這些實現或方案的研究，瞭解其關鍵特性和主要適用場景。最終決定是自研，還是在某個業界實現上做二次定製開發。
（四）架構設計
架構設計就是是一系列的系統關鍵環節的技術決策。如：
- 通信協議
通信協議使用TCP還是HTTP？
傳輸格式採用JSON還是XML？
- 持久化
數據存儲使用MySQL、SQLite還是Redis？
數據存儲是否需要支持多種持久化方案？
- 交互方式
客戶端和服務端採用同步交互還異步交互？
採用消息推送還是消息拉取模式？
- 日誌方案
是否記錄Binlog？
Binlog是否實現主從同步？每一個架構設計決策之間是互相影響甚至可能是互斥的關係，這個時候要有取捨，取捨的標準就是先看對與錯，後看好與壞。對與錯取決於方案的功能屬性，好與壞取決於方案的質量屬性。
方案的功能屬性是指其基本功能點；而方案的質量屬性是指：
1. 性能
2. 成本（硬件成本）
3. 可擴展性/可伸縮性
4. 可靠性
5. 複雜性
6. 運維
7. 其他 如：合規性、安全性……很多架構設計決策在後續的項目環節要進行驗證和實現，經過進一步的驗證和分析，很可能推翻之前的決策。
（五）需求管理
分析需求的優先級和依賴關係，規劃版本，確定時間點。最好使用需求管理工具，便於跟蹤。
（六）功能設計和開發
理清楚各個功能之間的邏輯關係，設計功能的關鍵邏輯，編寫代碼實現，最後自測驗證。
對外提供的API要特別注意其易用性，對外暴露的越少越好，否則內部變動很容易影響使用方。
（七）功能測試
（八）性能測試
要特別重視性能測試，通過性能測試能夠發現很多我們程序的關鍵Bug。
（九）資料編寫
包括系統設計的關鍵決策過程、開發指南、部署指南、配置說明以及技術沉澱總結。
資料編寫的過程也是重新審視整個項目的過程。
改進和提升
本次項目開發過程採用敏捷流程，從實踐效果來看，總體效果不錯。
1. 簡短的項目晨會，卻能夠很清晰的反映項目組成員的工作進度和遇到的難題，及早暴露問題。
2. 每週一個衝刺版本，這樣小版本迭代能夠快速試錯，也保證了開發和測試的同步進行，提升了效率。
3. 需求依賴分析和優先級分類，能夠保證我們開發出來的版本總是一個可用的版本。
4. 每個衝刺版本的代碼Review和評審會議效果非常好，不但能夠讓其他項目組成員熟悉代碼，關鍵時刻快速補位；而且能夠避免由於對架構設計的理解不一致，導致功能邏輯問題。
5. 發佈版本的FMEA評估效果也非常好，能夠發現很多異常場景下的邏輯漏洞，對於提升版本質量很有幫助。
改進點：
1. 對於每次項目會議，最好都有專人負責會議記錄，避免一些關鍵決策過程遺失。
2. 項目組最好都是用統一的代碼模板，這樣看代碼效率能提升不少。
3. 對於廢棄的代碼，堅決刪除，避免保留和註釋，這樣能保證代碼的清晰。
4. 在項目設計和開發之前，就要做好框架的知識儲備，否則很容易因爲不熟悉開發框架而延遲開發進度。本次項目就因爲對於Netty沒有提前熟悉，導致SDK第一個衝刺版本延遲。
5. 在設計和開發過程中，對於一些關鍵決策最好和項目組其他成員討論評審一下，否則很容易返工。
6. 自測聯調時，不能只關注是否調用成功，還需要檢查數據有效性和業務邏輯性，否則會浪費測試人員時間，導致重新打包。
7. 性能測試要做好測試計劃，提前熟悉測試工具，避免做很多無用測試。
8. 項目管理工具UAPD最好能夠提供需求任務列表，能夠讓開發人員一眼看到自己負責的任務和完成時間。
9. 對外API在設計接口時，最好先和業務使用方進行溝通，儘量滿足其使用場景；如果實在無法滿足某個場景，可以採用高層接口和底層接口相結合的方式，即：高層接口更加便利，但是隻滿足部分場景；底層接口能夠支持更加靈活的定製，使用起來相對麻煩一點。