莊周夢(mèng)蝶

    寫這篇文章的想法產(chǎn)生在昨天晚上讀《面向?qū)ο蠓治雠c設(shè)計(jì)》的時(shí)候，我漸漸發(fā)現(xiàn)我們這個(gè)小組不知不覺地貫徹了很多非常有價(jià)值的實(shí)踐經(jīng)驗(yàn)，這些點(diǎn)點(diǎn)滴滴都對(duì)我們的最終的產(chǎn)品質(zhì)量產(chǎn)生了或大或小的影響，保證我們的系統(tǒng)不會(huì)出現(xiàn)重大的故障。我想有必要將這些“隱性知識(shí)”稍微總結(jié)一下，以供參考和記錄。

   從過程的連續(xù)光譜來看，我們大概處于中間位置偏左的位置，更偏向一個(gè)輕量級(jí)團(tuán)隊(duì)的敏捷過程，但是也包含計(jì)劃驅(qū)動(dòng)過程中的因素。我們的小組是自管理的，沒有專門的QA和SA，我們自己去想出最好的工作方法，但是在執(zhí)行中我們的計(jì)劃還是相對(duì)確定的，每個(gè)季度做什么都會(huì)有一個(gè)比較明確的計(jì)劃和里程碑，并且對(duì)問題領(lǐng)域都相對(duì)熟悉；我們的過程是迭代式，一般一個(gè)季度至少會(huì)交付一個(gè)穩(wěn)定可執(zhí)行的新版本，我們?cè)谖臋n上做的不是特別好，很多都依賴于團(tuán)隊(duì)成員之間的“隱性知識(shí)”；同時(shí)我們對(duì)問題的改進(jìn)基本還是有一個(gè)流程和機(jī)制，會(huì)持續(xù)的跟蹤問題并改進(jìn)。

   下面分階段總結(jié)下我們的一些實(shí)踐經(jīng)驗(yàn)。

一、分析和設(shè)計(jì)階段

1、在這個(gè)階段，我們會(huì)明確準(zhǔn)備做什么，界定問題的邊界，對(duì)功能進(jìn)行一個(gè)取舍。一般在一個(gè)版本完成之后會(huì)馬上開始這個(gè)過程。大家都想一想接下來做什么，經(jīng)過幾輪PK后確定重要緊急的事情優(yōu)先做，定義下一個(gè)版本的功能列表。

2、功能列表出來之后，我們會(huì)針對(duì)每個(gè)功能提出各種方案做比較，在此期間，我們會(huì)邀請(qǐng)更大團(tuán)隊(duì)范圍內(nèi)的專家參與方案和設(shè)計(jì)的評(píng)審，剔除不切實(shí)際以及明顯有缺陷的方案，針對(duì)一些風(fēng)險(xiǎn)點(diǎn)提出改進(jìn)建議和防范措施。

3、在設(shè)計(jì)方案出來之后，我們會(huì)分配功能的開發(fā)任務(wù)，根據(jù)每個(gè)開發(fā)人員熟悉的領(lǐng)域，自主領(lǐng)取或者被動(dòng)分配任務(wù)。這個(gè)過程不是一成不變的，考慮到團(tuán)隊(duì)內(nèi)部知識(shí)交流的必要性，也可能讓不熟悉某個(gè)領(lǐng)域的人去做他不熟悉的事情。

二、構(gòu)造階段

1、整個(gè)系統(tǒng)已經(jīng)有一個(gè)關(guān)鍵的抽象機(jī)制，針對(duì)我們的服務(wù)器有一個(gè)核心的pipeline機(jī)制，針對(duì)我們的客戶端，有一個(gè)核心的發(fā)送消息流程。將所有的功能模塊組織在這個(gè)關(guān)鍵機(jī)制周圍，形成一個(gè)強(qiáng)有力的整體。

2、開發(fā)完成不僅僅意味著功能代碼的完成，還包括測(cè)試代碼：?jiǎn)卧獪y(cè)試和集成測(cè)試。如果你沒辦法做到全面的覆蓋，那就要求必須覆蓋運(yùn)行的關(guān)鍵路徑和極端場(chǎng)景。

3、單元測(cè)試我們使用JUnit，適當(dāng)使用Mock可以簡(jiǎn)化測(cè)試。但是Mock對(duì)象如果太多，也許會(huì)失去測(cè)試的價(jià)值，這里有一個(gè)權(quán)衡。

4、在整個(gè)構(gòu)造過程中，我們貫徹每日構(gòu)建、持續(xù)集成的原則。使用hudson做持續(xù)集成，時(shí)刻關(guān)注測(cè)試狀況，有問題及時(shí)反饋給開發(fā)者。

5、有一個(gè)功能強(qiáng)大的集成測(cè)試框架，模擬實(shí)際環(huán)境做各種測(cè)試，它的目的是盡量在接近真實(shí)狀況下去執(zhí)行系統(tǒng)并盡早暴露問題。

6、每個(gè)功能完成之后，立即發(fā)起review，請(qǐng)同事和你一起復(fù)審代碼。復(fù)審代碼的作用不僅是發(fā)現(xiàn)bug，改良設(shè)計(jì)，也是一個(gè)知識(shí)交流的最佳途徑。我們經(jīng)常能通過代碼審查發(fā)現(xiàn)一些設(shè)計(jì)上的缺陷，以及功能實(shí)現(xiàn)上的BUG。我們團(tuán)隊(duì)?wèi)?yīng)該說是非常看重代碼審查的作用。

7、使用findbugs和clover等工具，分析代碼質(zhì)量并改進(jìn)。

8、在發(fā)布之前，做一次集中的代碼review，每個(gè)人介紹下自己的功能實(shí)現(xiàn)代碼和設(shè)計(jì)，一般我們會(huì)申請(qǐng)一個(gè)會(huì)議室和投影儀，并邀請(qǐng)團(tuán)隊(duì)之外的人加入review。

9、在發(fā)布之前，有一個(gè)系統(tǒng)的壓測(cè)流程，針對(duì)每個(gè)版本更新壓測(cè)方案，并預(yù)留一到兩周的時(shí)間做性能壓測(cè)。壓測(cè)不僅能盡早暴露性能隱患，還可以發(fā)現(xiàn)系統(tǒng)在特殊情況下的一些BUG。壓測(cè)除了關(guān)注系統(tǒng)的吞吐量、GC情況之外，還應(yīng)該關(guān)注硬件的性能指標(biāo)。

三、發(fā)布和總結(jié)
1、發(fā)布之前，最好讓使用我們系統(tǒng)的用戶使用新版本做一個(gè)回歸測(cè)試，一方面是測(cè)試兼容性，一方面也可以及早發(fā)現(xiàn)BUG。

2、我們的發(fā)布流程：線下、beta、線上。每個(gè)階段通常都持續(xù)一到兩周，才會(huì)進(jìn)行到下一階段。并且是從相對(duì)不重要的系統(tǒng)，到關(guān)鍵系統(tǒng)的順序進(jìn)行發(fā)布。

3、發(fā)布之后，通過日志、運(yùn)行時(shí)監(jiān)控、用戶反饋等方式收集系統(tǒng)運(yùn)行狀況，發(fā)現(xiàn)BUG，修正BUG，補(bǔ)充測(cè)試，測(cè)試通過，重新發(fā)布。

4、每個(gè)版本發(fā)布后，需要總結(jié)下本次發(fā)布過程中遇到的所有BUG以及經(jīng)驗(yàn)教訓(xùn)，并提出可能的改進(jìn)建議。

5、需要一個(gè)跟蹤線上問題的BUG跟蹤系統(tǒng)，可以用JIRA之類的trace軟件。跟蹤不僅是記錄，最好列出解決的時(shí)間點(diǎn)，在哪個(gè)版本確定解決，甚至確定交給誰(shuí)去解決，并持續(xù)跟進(jìn)。