敏捷軟件開發實踐-Code Review Process

介紹：

在敏捷軟件開發中，從代碼的產生速度上來看，要比傳統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)對于新來項目組的成員來說，用調試模式單步走的策略，只抓住核心流程，從而以最快的速度把握項目核心流程。