項目過程分解
通過一次消息中間件系統(tǒng)的全程參與芍碧，對于軟件項目從無到有的生產(chǎn)過程有了較深入的了解，尤其對于架構(gòu)設(shè)計的決策過程和依據(jù)号俐，有了全面的認(rèn)識泌豆。整個項目過程從無到有依次可以分解為九個過程，下面一一道來吏饿。
1. 背景分析
主要是要分析清楚三個問題：
1. 這個項目的訴求是在什么業(yè)務(wù)現(xiàn)狀下產(chǎn)生的踪危？
2. 最終要解決什么問題？
3. 有什么價值猪落？
為什么要做背景分析呢贞远？
1. 更透徹的分析需求
所有的需求分析過程都要圍繞上述三個問題來，不能偏離笨忌。
2. 更主動的做事蓝仲；
當(dāng)你做一件事情的時候，如果不理解為什么要做官疲，只是單純的做事的時候袱结，其實是缺少主動性的
3. 獲得上級的支持。
有了上級的資源（人力途凫、時間）支持垢夹，項目能夠更加的順利。
2. 需求收集和分析
需求分為兩類：
1. 功能性需求
功能性需求一般是項目組內(nèi)分析得出的該系統(tǒng)需要具備的一些必備特性维费。對于消息中間件系統(tǒng)來說果元，如：發(fā)布消息、拉取消息犀盟、訂閱……
2. 業(yè)務(wù)性需求
業(yè)務(wù)性需求一般是從潛在的系統(tǒ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ù)特性都能夠同時滿足缓熟。
3. 業(yè)界方案研究
基于背景分析和需求收集分析累魔，收集類似的實現(xiàn)或方案。通過對這些實現(xiàn)或方案的研究够滑，了解其關(guān)鍵特性和主要適用場景垦写。最終決定是自研，還是在某個業(yè)界實現(xiàn)上做二次定制開發(fā)彰触。
4. 架構(gòu)設(shè)計
架構(gòu)設(shè)計就是是一系列的系統(tǒng)關(guān)鍵環(huán)節(jié)的技術(shù)決策梯投。如：
通信協(xié)議
通信協(xié)議使用TCP還是HTTP？傳輸格式采用JSON還是XML况毅？
持久化
數(shù)據(jù)存儲使用MySQL分蓖、SQLite還是Redis？數(shù)據(jù)存儲是否需要支持多種持久化方案尔许？
交互方式
客戶端和服務(wù)端采用同步交互還異步交互么鹤？采用消息推送還是消息拉取模式？
日志方案
是否記錄Binlog味廊？Binlog是否實現(xiàn)主從同步蒸甜？
每一個架構(gòu)設(shè)計決策之間是互相影響甚至可能是互斥的關(guān)系，這個時候要有取舍毡们，取舍的標(biāo)準(zhǔn)就是先看對與錯迅皇，后看好與壞。對與錯取決于方案的功能屬性衙熔，好與壞取決于方案的質(zhì)量屬性登颓。
方案的功能屬性是指其基本功能點；而方案的質(zhì)量屬性是指：
1. 性能2. 成本（硬件成本）3. 可擴(kuò)展性/可伸縮性4. 可靠性5. 復(fù)雜性6. 運(yùn)維7. 其他 如：合規(guī)性红氯、安全性……
很多架構(gòu)設(shè)計決策在后續(xù)的項目環(huán)節(jié)要進(jìn)行驗證和實現(xiàn)框咙，經(jīng)過進(jìn)一步的驗證和分析，很可能推翻之前的決策痢甘。
5. 需求管理
分析需求的優(yōu)先級和依賴關(guān)系喇嘱，規(guī)劃版本，確定時間點塞栅。最好使用需求管理工具者铜，便于跟蹤。
6.?功能設(shè)計和開發(fā)
理清楚各個功能之間的邏輯關(guān)系，設(shè)計功能的關(guān)鍵邏輯作烟，編寫代碼實現(xiàn)愉粤，最后自測驗證。
對外提供的API要特別注意其易用性拿撩，對外暴露的越少越好衣厘，否則內(nèi)部變動很容易影響使用方。
7. 功能測試
白盒+黑盒压恒，無需贅言影暴！
8. 性能測試
要特別重視性能測試，通過性能測試能夠發(fā)現(xiàn)很多我們程序的關(guān)鍵Bug探赫。
9. 資料編寫
包括系統(tǒng)設(shè)計的關(guān)鍵決策過程型宙、開發(fā)指南、部署指南期吓、配置說明以及技術(shù)沉淀總結(jié)早歇。
資料編寫的過程也是重新審視整個項目的過程。
改進(jìn)和提升
做得不錯
1. 簡短的項目晨會讨勤，卻能夠很清晰的反映項目組成員的工作進(jìn)度和遇到的難題，及早暴露問題晨另。2. 每周一個沖刺版本潭千，這樣小版本迭代能夠快速試錯，也保證了開發(fā)和測試的同步進(jìn)行借尿，提升了效率刨晴。3. 需求依賴分析和優(yōu)先級分類，能夠保證我們開發(fā)出來的版本總是一個可用的版本路翻。4. 每個沖刺版本的代碼Review和評審會議效果非常好狈癞，不但能夠讓其他項目組成員熟悉代碼，關(guān)鍵時刻快速補(bǔ)位茂契；而且能夠避免由于對架構(gòu)設(shè)計的理解不一致蝶桶，導(dǎo)致功能邏輯問題。5. 發(fā)布版本的FMEA評估效果也非常好掉冶，能夠發(fā)現(xiàn)很多異常場景下的邏輯漏洞真竖，對于提升版本質(zhì)量很有幫助。
后續(xù)改進(jìn)
1. 對于每次項目會議厌小，最好都有專人負(fù)責(zé)會議記錄恢共，避免一些關(guān)鍵決策過程遺失。2. 項目組最好都是用統(tǒng)一的代碼模板璧亚，這樣看代碼效率能提升不少讨韭。3. 對于廢棄的代碼，堅決刪除，避免保留和注釋透硝，這樣能保證代碼的清晰吉嚣。4. 在項目設(shè)計和開發(fā)之前，就要做好框架的知識儲備蹬铺，否則很容易因為不熟悉開發(fā)框架而延遲開發(fā)進(jìn)度尝哆。本次項目就因為對于Netty沒有提前熟悉，導(dǎo)致SDK第一個沖刺版本延遲甜攀。5. 在設(shè)計和開發(fā)過程中秋泄，對于一些關(guān)鍵決策最好和項目組其他成員討論評審一下，否則很容易返工规阀。6. 自測聯(lián)調(diào)時恒序，不能只關(guān)注是否調(diào)用成功，還需要檢查數(shù)據(jù)有效性和業(yè)務(wù)邏輯性谁撼，否則會浪費(fèi)測試人員時間歧胁，導(dǎo)致重新打包。7. 性能測試要做好測試計劃厉碟，提前熟悉測試工具喊巍，避免做很多無用測試。8. 項目管理工具UAPD最好能夠提供需求任務(wù)列表箍鼓，能夠讓開發(fā)人員一眼看到自己負(fù)責(zé)的任務(wù)和完成時間崭参。9. 對外API在設(shè)計接口時，最好先和業(yè)務(wù)使用方進(jìn)行溝通款咖，盡量滿足其使用場景何暮；如果實在無法滿足某個場景，可以采用高層接口和底層接口相結(jié)合的方式铐殃，即：高層接口更加便利海洼，但是只滿足部分場景；底層接口能夠支持更加靈活的定制富腊，使用起來相對麻煩一點坏逢。
