codereview(codereview什麼意思)

為什麼要Code Review

Code Review是我們項目成功的最有力的武器。下面我先談下我了解并實施的Code Review.

1. Code review的層次。

最基礎的，也是所有人都會想到到的，就是編碼規範，類，方法命名什麼的，還有代碼格式...這些是程式員的基本功底，預設選項；多年前上司要我搞個編碼規範，我說大家都熟知的規範就已經很好了啊；當然公司内部也需要這方面的規範，比如項目如何命名，包如何命名等這些。

更高一層次的，也是說的比較少的，是代碼的品質。前面能保證代碼寫的好看，大家看了都還順眼，但并不能保證代碼的可工作性，合理性，健壯性，可維護性。我們需要可以解決問題的代碼；我們需要最合理(最是相對的)的代碼；我們不希望破壞現有的架構搞特殊處理，如果架構本身不适應，那就可控制的重構；我們不希望有個工作很好的功能被破壞。

2.Code Review的好處

第一，最少有兩個人對同一段代碼深刻了解，并且認同。如果不能做到靈活要求的“結對程式設計”的味道，我們就打個折執行吧。這一點從公司正常營運上，也是有好處的。

第二，開發人員可以放心的把自己的創造性發揮出來，因為他知道他有個堅強的後盾，絕不會等到QA發現不可饒恕的錯誤，然後經理過來罵你一頓。

第三，開發人員都會盡全力寫最好的代碼；軟體開發人員都是要"face"的，不想當時就被别人找到缺陷，尤其是你身邊的同僚。再也不會隻顧今天，不管明天會怎樣；對軟體的可維護性更加盡心。

第四，極大的提高軟體品質，以及可維護性。當然這要求Review人員的責任心，以及專業精神。如果是維護性項目，經驗也是相當重要的。

3. Code Review的重要性

至此，其重要性以已經不言而喻了。個人認為某種程度上其重要性以及你改超過Unit Test.

4. Code Review不好實施的原因

Code Review如此重要，但是據我接觸的人跟公司來看，真正認真執行的并不多。其原因無非：

ü 項目時間緊，時間跟人員都不充足；如果是這種情況，建議招點人，項目計劃制定的更合理些。

ü 重視程度不夠；開發人員都覺得自己很牛，代碼不需要給别人Review。其實問題往往就是由于過分的自信造成的，需要公司高層多做宣導，并形成制度，強力執行。等過一段時間，大家都會體驗到其中的好處的。

ü 執行起來比較麻煩。這是大問題。如果你讓開發人員覺得做Code Review是件很容易的事，并且收益大于付出，大家就願意做了。我們Team大緻經曆過三個階段。

第一階段，按制定的流程，開發人員把修改的代碼用郵件發給Review者，并說明改了什麼，對系統那些功能有影響。然後負責Review的人Copy到Eclipse，對比CVS, 看代碼的改動是否合理。然後再郵件通知合格，或不合格，并說明原因(口頭或書面)。

第二階段，開發人員都覺得這樣太繁瑣，費事費力；于是我們開發了個Eclipse插件，幫助開發人員對自動生成代碼改動細節的郵件，并把改動的代碼自動放到指定的公用檔案夾中。如此一來開發人員生成一個Code Review的請求，就是分分鐘的事情了(右鍵，寫點什麼，完成)就好了。

第三階段，開發人員現在很Happy了，但是Review的人覺得還是有點麻煩，要Copy,要寫郵件。于是我們把插件又改進了下，Review的人也可以在Eclipse上一鍵把代碼copy進來；然後提供了一個Web Console供頭頭看我們Code Review的情況。

code review 怎麼使用