敏捷式軟體開發 (Agile Software Development)實踐-Code Review Process

介紹：

在敏捷式軟體開發 (Agile Software Development)中，從代碼的產生速度上來看，要比傳統Waterfall產生速度高很多。因為我們把時間安排的更加緊湊了。那麼這麼多的代碼，如何能保證這些代碼品質呢？很多人可能直接想到靜態代碼偵查工具。沒錯，那些是可以定義一個代碼檢查規則來確保代碼的品質，但是那個僅僅是從語言角度，那麼邏輯是否已經最佳化了？可重用性是否已經最佳化到極致了？這些是靜態代碼工具不能完成的，所以我們需要Code Review

實現方式：

對於已經在項目組很久的人來說：

雖然傳統的code review就是把代碼從倉庫checkout出來，然後看下，但是對於大項目來說，那樣的代碼審查沒有任何的效果，因為你除了看到代碼還是代碼，就像你在大海中看到的除了水就是天，很快就會迷失方向的。我們團隊的經驗，一般是採用crucible工具來進行代碼審查，這個工具我以前部落格已經有過介紹了：http://supercharles888.blog.51cto.com/609344/1229660

因為我們代碼提交每次都有產生一個uuid,而我們提交更多是以子功能為單位，所以我們在crucible中也以提交為單位建立事件，可以很明確的知道對於具體某個功能，其實現的效果如何。

代碼我們也採用了傳統的peer review,因為自己看自己代碼很難看出問題，但是用批判的眼光看別人的代碼就很容易看出問題，所以我們結對的進行code review, 前端的人相互review,後端的人相互review.

對於剛來項目組的人：

剛來項目組的人，因為對商務邏輯不熟悉，直接讓他去以提交為單位進行審查代碼是沒有任何意義的，他們最重要的是熟悉代碼從而可以很快的上手項目，這時候，我就不主張他們用code review工具了，而是直接把代碼全部簽下來整體看，我的經驗是：用偵錯模式啟動伺服器，然後在關鍵的行打上斷點（後端代碼斷點），然後在前端你用Firefox 開啟，開啟FireBug，在關鍵js檔案相應行也打上斷點（前端代碼斷點），然後完全用單步走的方式，一步步走過來，同時watch關鍵的變數的值的變化，這樣走一遍雖然很慢，但是你會對代碼邏輯流程非常熟悉而且印象深刻。而且一個項目來說，雖然代碼很多，但是關鍵流程並不多（判斷依據就是這些流程是否最後要做Regression,如果要做Regression,那麼就算關鍵流程），如果把握了關鍵流程，就是等於抓住了主要矛盾。這是最好的上手項目的習慣。按照我們團隊的經驗，一般一個senior engineer水平，2-3天就能上手項目並且開始接任務做了。

總結：

(1)對於項目組的老人來說，用代碼審查工具來code review,從而可以從功能模組角度審查代碼的實現

(2)對於新來項目組的成員來說，用偵錯模式單步走的策略，只抓住核心流程，從而以最快的速度把握項目核心流程。

本文出自 “平行線的凝聚” 部落格，請務必保留此出處http://supercharles888.blog.51cto.com/609344/1262016