項(xiàng)目過程分解
通過本次消息中間件系統(tǒng)的全程參與，對于軟件項(xiàng)目從無到有的生產(chǎn)過程有了較深入的了解这溅，尤其對于架構(gòu)設(shè)計(jì)的決策過程和依據(jù)，有了全面的認(rèn)識。整個項(xiàng)目過程從無到有依次可以分解為九個過程工扎，下面一一道來。
（一）背景分析
主要是要分析清楚三個問題：
1. 這個項(xiàng)目的訴求是在什么業(yè)務(wù)現(xiàn)狀下產(chǎn)生的衔蹲？
2. 最終要解決什么問題肢娘？
3. 有什么價值？為什么要做背景分析呢舆驶？
1. 更透徹的分析需求
所有的需求分析過程都要圍繞這上述三個問題來橱健，不能偏離。
2. 更主動的做事沙廉；
當(dāng)你做一件事情的時候拘荡，如果不理解為什么要做，只是單純的做事的時候撬陵，其實(shí)是缺少主動性的
3. 獲得上級的支持俱病。
有了上級的資源（人力、時間）支持袱结，項(xiàng)目能夠更加的順利亮隙。
（二）需求收集和分析
需求分為兩類：
1. 功能性需求
功能性需求一般是項(xiàng)目組內(nèi)分析得出的該系統(tǒng)需要具備的一些必備特性。對于消息中間件系統(tǒng)來說垢夹，如：發(fā)布消息溢吻、拉取消息、訂閱……
2. 業(yè)務(wù)性需求
業(yè)務(wù)性需求一般是從潛在的系統(tǒng)用戶（周邊項(xiàng)目組）那收集到的一些業(yè)務(wù)特性和使用習(xí)慣，針對這些業(yè)務(wù)特性和使用習(xí)慣促王，分析我們的系統(tǒng)是否能滿足犀盟。對于消息中間件系統(tǒng)來說，如：業(yè)務(wù)系統(tǒng)習(xí)慣主動推送消息蝇狼，不希望拉取消息阅畴；業(yè)務(wù)系統(tǒng)熟悉MySQL，希望底層存儲使用MySQL迅耘；業(yè)務(wù)系統(tǒng)現(xiàn)有方案的數(shù)據(jù)格式是JSON贱枣，不希望換數(shù)據(jù)格式。對于業(yè)務(wù)性的需求颤专，我們要有所區(qū)分和取舍纽哥，不一定所有的業(yè)務(wù)特性都能夠同時滿足。
（三）業(yè)界方案研究
基于背景分析和需求收集分析栖秕，收集類似的實(shí)現(xiàn)或方案春塌。通過對這些實(shí)現(xiàn)或方案的研究，了解其關(guān)鍵特性和主要適用場景簇捍。最終決定是自研，還是在某個業(yè)界實(shí)現(xiàn)上做二次定制開發(fā)吼句。
（四）架構(gòu)設(shè)計(jì)
架構(gòu)設(shè)計(jì)就是是一系列的系統(tǒng)關(guān)鍵環(huán)節(jié)的技術(shù)決策梯投。如：
- 通信協(xié)議
通信協(xié)議使用TCP還是HTTP命辖？
傳輸格式采用JSON還是XML分蓖？- 持久化
數(shù)據(jù)存儲使用MySQL、SQLite還是Redis蒸甜？
數(shù)據(jù)存儲是否需要支持多種持久化方案？- 交互方式
客戶端和服務(wù)端采用同步交互還異步交互恨憎？
采用消息推送還是消息拉取模式瓤荔？- 日志方案
是否記錄Binlog？
Binlog是否實(shí)現(xiàn)主從同步点把？每一個架構(gòu)設(shè)計(jì)決策之間是互相影響甚至可能是互斥的關(guān)系，這個時候要有取舍衣厘，取舍的標(biāo)準(zhǔn)就是先看對與錯，后看好與壞型宙。對與錯取決于方案的功能屬性，好與壞取決于方案的質(zhì)量屬性。
方案的功能屬性是指其基本功能點(diǎn)腺逛；而方案的質(zhì)量屬性是指：
1. 性能
2. 成本（硬件成本）
3. 可擴(kuò)展性/可伸縮性
4. 可靠性
5. 復(fù)雜性
6. 運(yùn)維
7. 其他 如：合規(guī)性、安全性……很多架構(gòu)設(shè)計(jì)決策在后續(xù)的項(xiàng)目環(huán)節(jié)要進(jìn)行驗(yàn)證和實(shí)現(xiàn)，經(jīng)過進(jìn)一步的驗(yàn)證和分析茁帽，很可能推翻之前的決策厌小。
（五）需求管理
分析需求的優(yōu)先級和依賴關(guān)系，規(guī)劃版本，確定時間點(diǎn)疯搅。最好使用需求管理工具，便于跟蹤。
（六）功能設(shè)計(jì)和開發(fā)
理清楚各個功能之間的邏輯關(guān)系浴井，設(shè)計(jì)功能的關(guān)鍵邏輯，編寫代碼實(shí)現(xiàn)徒坡，最后自測驗(yàn)證款咖。
對外提供的API要特別注意其易用性海洼，對外暴露的越少越好富腊，否則內(nèi)部變動很容易影響使用方坏逢。
（七）功能測試
（八）性能測試
要特別重視性能測試，通過性能測試能夠發(fā)現(xiàn)很多我們程序的關(guān)鍵Bug。
（九）資料編寫
包括系統(tǒng)設(shè)計(jì)的關(guān)鍵決策過程、開發(fā)指南浮入、部署指南、配置說明以及技術(shù)沉淀總結(jié)。
資料編寫的過程也是重新審視整個項(xiàng)目的過程睹欲。
改進(jìn)和提升
本次項(xiàng)目開發(fā)過程采用敏捷流程考余，從實(shí)踐效果來看疫蔓，總體效果不錯。
1. 簡短的項(xiàng)目晨會身冬，卻能夠很清晰的反映項(xiàng)目組成員的工作進(jìn)度和遇到的難題，及早暴露問題滚躯。
2. 每周一個沖刺版本，這樣小版本迭代能夠快速試錯嘿歌，也保證了開發(fā)和測試的同步進(jìn)行掸掏，提升了效率。
3. 需求依賴分析和優(yōu)先級分類宙帝，能夠保證我們開發(fā)出來的版本總是一個可用的版本丧凤。
4. 每個沖刺版本的代碼Review和評審會議效果非常好，不但能夠讓其他項(xiàng)目組成員熟悉代碼步脓，關(guān)鍵時刻快速補(bǔ)位愿待；而且能夠避免由于對架構(gòu)設(shè)計(jì)的理解不一致浩螺，導(dǎo)致功能邏輯問題。
5. 發(fā)布版本的FMEA評估效果也非常好仍侥，能夠發(fā)現(xiàn)很多異常場景下的邏輯漏洞要出，對于提升版本質(zhì)量很有幫助。
改進(jìn)點(diǎn)：
1. 對于每次項(xiàng)目會議农渊，最好都有專人負(fù)責(zé)會議記錄厨幻，避免一些關(guān)鍵決策過程遺失。
2. 項(xiàng)目組最好都是用統(tǒng)一的代碼模板腿时，這樣看代碼效率能提升不少况脆。
3. 對于廢棄的代碼，堅(jiān)決刪除批糟，避免保留和注釋格了，這樣能保證代碼的清晰。
4. 在項(xiàng)目設(shè)計(jì)和開發(fā)之前徽鼎，就要做好框架的知識儲備盛末，否則很容易因?yàn)椴皇煜ら_發(fā)框架而延遲開發(fā)進(jìn)度。本次項(xiàng)目就因?yàn)閷τ贜etty沒有提前熟悉否淤，導(dǎo)致SDK第一個沖刺版本延遲悄但。
5. 在設(shè)計(jì)和開發(fā)過程中，對于一些關(guān)鍵決策最好和項(xiàng)目組其他成員討論評審一下石抡，否則很容易返工檐嚣。
6. 自測聯(lián)調(diào)時，不能只關(guān)注是否調(diào)用成功啰扛，還需要檢查數(shù)據(jù)有效性和業(yè)務(wù)邏輯性嚎京，否則會浪費(fèi)測試人員時間，導(dǎo)致重新打包隐解。
7. 性能測試要做好測試計(jì)劃鞍帝，提前熟悉測試工具，避免做很多無用測試煞茫。
8. 項(xiàng)目管理工具UAPD最好能夠提供需求任務(wù)列表帕涌，能夠讓開發(fā)人員一眼看到自己負(fù)責(zé)的任務(wù)和完成時間。
9. 對外API在設(shè)計(jì)接口時续徽，最好先和業(yè)務(wù)使用方進(jìn)行溝通蚓曼，盡量滿足其使用場景；如果實(shí)在無法滿足某個場景炸宵，可以采用高層接口和底層接口相結(jié)合的方式辟躏，即：高層接口更加便利谷扣，但是只滿足部分場景土全；底層接口能夠支持更加靈活的定制捎琐，使用起來相對麻煩一點(diǎn)。
