寫這篇文章的想法產(chǎn)生在昨天晚上讀《面向?qū)ο蠓治雠c設計》的時候，我漸漸發(fā)現(xiàn)我們這個小組不知不覺地貫徹了很多非常有價值的實踐經(jīng)驗，這些點點滴滴都對我 們的最終的產(chǎn)品質(zhì)量產(chǎn)生了或大或小的影響，保證我們的系統(tǒng)不會出現(xiàn)重大的故障。我想有必要將這些“隱性知識”稍微總結(jié)一下，以供參考和記錄。
從過程的連續(xù)光譜來看，我們大概處于中間位置偏左的位置，更偏向一個輕量級團隊的敏捷過程，但是也包含計劃驅(qū)動過程中的因素。我們的小組是自管理的，沒有 專門的QA和SA，我們自己去想出最好的工作方法，但是在執(zhí)行中我們的計劃還是相對確定的，每個季度做什么都會有一個比較明確的計劃和里程碑，并且對問題 領域都相對熟悉；我們的過程是迭代式，一般一個季度至少會交付一個穩(wěn)定可執(zhí)行的新版本，我們在文檔上做的不是特別好，很多都依賴于團隊成員之間的“隱性知 識”；同時我們對問題的改進基本還是有一個流程和機制，會持續(xù)的跟蹤問題并改進。
下面分階段總結(jié)下我們的一些實踐經(jīng)驗。
一、分析和設計階段
1、在這個階段，我們會明確準備做什么，界定問題的邊界，對功能進行一個取舍。一般在一個版本完成之后會馬上開始這個過程。大家都想一想接下來做什么，經(jīng)過幾輪PK后確定重要緊急的事情優(yōu)先做，定義下一個版本的功能列表 。
2、功能列表出來之后，我們會針對每個功能提出各種方案做比較，在此期間，我們會邀請更大團隊范圍內(nèi)的專家參與方案和設計的評審 ，剔除不切實際以及明顯有缺陷的方案，針對一些風險點提出改進建議和防范措施。
3、在設計方案出來之后，我們會分配功能的開發(fā)任務，根據(jù)每個開發(fā)人員熟悉的領域，自主領取或者被動分配任務 。這個過程不是一成不變的，考慮到團隊內(nèi)部知識交流的必要性，也可能讓不熟悉某個領域的人去做他不熟悉的事情。
二、構(gòu)造階段
1、整個系統(tǒng)已經(jīng)有一個關鍵的抽象機制 ，針對我們的服務器有一個核心的pipeline機制，針對我們的客戶端，有一個核心的發(fā)送消息流程。將所有的功能模塊組織在這個關鍵機制周圍，形成一個強有力的整體。
2、開發(fā)完成不僅僅意味著功能代碼的完成，還包括測試代碼 ：單元測試和集成測試。如果你沒辦法做到全面的覆蓋，那就要求必須覆蓋運行的關鍵路徑和極端場景。
3、單元測試我們使用JUnit，適當使用Mock可以簡化測試。但是Mock對象如果太多，也許會失去測試的價值，這里有一個權(quán)衡。
4、在整個構(gòu)造過程中，我們貫徹每日構(gòu)建、持續(xù)集成的原則。使用hudson做持續(xù)集成，時刻關注測試狀況 ，有問題及時反饋給開發(fā)者。
5、有一個功能強大的集成測試框架，模擬實際環(huán)境做各種測試，它的目的是盡量在接近真實狀況下去執(zhí)行系統(tǒng)并盡早暴露問題。
6、每個功能完成之后，立即發(fā)起review，請同事和你一起復審代碼。復審代碼的作用不僅是發(fā)現(xiàn)bug，改良設計，也是一個知識交流的最佳途徑。我們經(jīng)常能通過代碼審查 發(fā)現(xiàn)一些設計上的缺陷，以及功能實現(xiàn)上的BUG。我們團隊應該說是非?？粗卮a審查的作用。
7、使用findbugs和clover等工具 ，分析代碼質(zhì)量并改進。
8、在發(fā)布之前，做一次集中的代碼review ，每個人介紹下自己的功能實現(xiàn)代碼和設計，一般我們會申請一個會議室和投影儀，并邀請團隊之外的人加入review。
9、在發(fā)布之前，有一個系統(tǒng)的壓測流程 ，針對每個版本更新壓測方案，并預留一到兩周的時間做性能壓測。壓測不僅能盡早暴露性能隱患，還可以發(fā)現(xiàn)系統(tǒng)在特殊情況下的一些BUG。壓測除了關注系統(tǒng)的吞吐量、GC情況之外，還應該關注硬件的性能指標。
三、發(fā)布和總結(jié)
1、發(fā)布之前，最好讓使用我們系統(tǒng)的用戶使用新版本做一個回歸測試 ，一方面是測試兼容性，一方面也可以及早發(fā)現(xiàn)BUG。
2、我們的發(fā)布流程：線下、beta、線上。每個階段通常都持續(xù)一到兩周，才會進行到下一階段。并且是從相對不重要的系統(tǒng)，到關鍵系統(tǒng)的順序進行發(fā)布。
3、發(fā)布之后，通過日志、運行時監(jiān)控、用戶反饋等方式收集系統(tǒng)運行狀況，發(fā)現(xiàn)BUG，修正BUG，補充測試，測試通過，重新發(fā)布。
4、每個版本發(fā)布后，需要總結(jié)下本次發(fā)布過程中遇到的所有BUG以及經(jīng)驗教訓，并提出可能的改進建議。
5、需要一個跟蹤線上問題的BUG跟蹤系統(tǒng)，可以用JIRA之類的trace軟件。跟蹤不僅是記錄，最好列出解決的時間點，在哪個版本確定解決，甚至確定交給誰去解決，并持續(xù)跟進。