高質量軟體，從點點滴滴做起

從過程的連續光譜來看，我們大概處於中間位置偏左的位置，更偏向一個輕量級團隊的敏捷過程，但是也包含計劃驅動過程中的因素。我們的小組是自管理的，沒有專門的QA和SA，我們自己去想出最好的工作方法，但是在執行中我們的計劃還是相對確定的，每個季度做什麼都會有一個比較明確的計劃和里程碑，並且對問題領域都相對熟悉；我們的過程是迭代式，一般一個季度至少會交付一個穩定可執行的新版本，我們在文件上做的不是特別好，很多都依賴於團隊成員之間的“隱性知識”；同時我們對問題的改進基本還是有一個流程和機制，會持續的跟蹤問題並改進。

下面分階段總結下我們的一些實踐經驗。

一、分析和設計階段

1、在這個階段，我們會明確準備做什麼，界定問題的邊界，對功能進行一個取捨。一般在一個版本完成之後會馬上開始這個過程。大家都想一想接下來做什麼，經過幾輪PK後確定重要緊急的事情優先做，定義下一個版本的功能列表。

2、功能列表出來之後，我們會針對每個功能提出各種方案做比較，在此期間，我們會邀請更大團隊範圍內的專家參與方案和設計的評審，剔除不切實際以及明顯有缺陷的方案，針對一些風險點提出改進建議和防範措施。

3、在設計方案出來之後，我們會分配功能的開發任務，根據每個開發人員熟悉的領域，自主領取或者被動分配任務。這個過程不是一成不變的，考慮到團隊內部知識交流的必要性，也可能讓不熟悉某個領域的人去做他不熟悉的事情。

二、構造階段

1、整個系統已經有一個關鍵的抽象機制，針對我們的伺服器有一個核心的pipeline機制，針對我們的客戶端，有一個核心的傳送訊息流程。將所有的功能模組組織在這個關鍵機制周圍，形成一個強有力的整體。

2、開發完成不僅僅意味著功能程式碼的完成，還包括測試程式碼：單元測試和整合測試。如果你沒辦法做到全面的覆蓋，那就要求必須覆蓋執行的關鍵路徑和極端場景。

3、單元測試我們使用JUnit，適當使用Mock可以簡化測試。但是Mock物件如果太多，也許會失去測試的價值，這裡有一個權衡。

4、在整個構造過程中，我們貫徹每日構建、持續整合的原則。使用hudson做持續整合，時刻關注測試狀況，有問題及時反饋給開發者。

5、有一個功能強大的整合測試框架，模擬實際環境做各種測試，它的目的是儘量在接近真實狀況下去執行系統並儘早暴露問題。

6、每個功能完成之後，立即發起review，請同事和你一起復審程式碼。複審程式碼的作用不僅是發現bug，改良設計，也是一個知識交流的最佳途徑。我們經常能通過程式碼審查發現一些設計上的缺陷，以及功能實現上的BUG。我們團隊應該說是非常看重程式碼審查的作用。

7、使用findbugs和clover等工具，分析程式碼質量並改進。

8、在釋出之前，做一次集中的程式碼review，每個人介紹下自己的功能實現程式碼和設計，一般我們會申請一個會議室和投影儀，並邀請團隊之外的人加入review。

9、在釋出之前，有一個系統的壓測流程，針對每個版本更新壓測方案，並預留一到兩週的時間做效能壓測。壓測不僅能儘早暴露效能隱患，還可以發現系統在特殊情況下的一些BUG。壓測除了關注系統的吞吐量、GC情況之外，還應該關注硬體的效能指標。

三、釋出和總結
1、釋出之前，最好讓使用我們系統的使用者使用新版本做一個迴歸測試，一方面是測試相容性，一方面也可以及早發現BUG。

2、我們的釋出流程：線下、beta、線上。每個階段通常都持續一到兩週，才會進行到下一階段。並且是從相對不重要的系統，到關鍵系統的順序進行釋出。

3、釋出之後，通過日誌、執行時監控、使用者反饋等方式收集系統執行狀況，發現BUG，修正BUG，補充測試，測試通過，重新發布。

4、每個版本釋出後，需要總結下本次釋出過程中遇到的所有BUG以及經驗教訓，並提出可能的改進建議。

5、需要一個跟蹤線上問題的BUG跟蹤系統，可以用JIRA之類的trace軟體。跟蹤不僅是記錄，最好列出解決的時間點，在哪個版本確定解決，甚至確定交給誰去解決，並持續跟進。

本文來源於”阿里中介軟體團隊播客”,原文發表時間”  2010-12-30″