6.咱們真的作了代碼評審

靜態代碼檢查工具StyleCode。

 

 

    上一章我說了設計評審和測試用例評審都是爲了提高產品質量問題，後來咱們又作了代碼評審，可是代碼評審比設計評審難搞多了，對於開發來講最在乎的就是本身的代碼，讓別人對本身的代碼指指點點，雖然是好的建議但也會讓人不爽。

    準備搞代碼評審以前之前就嘗試過，搞着搞着最後的結果只是變成一種形式而已，你們熱情都不高，反而給團隊增長了負面的情緒。在如今團隊中因爲代碼質量問題，減小bug的產出，在回顧會議中團隊提出能夠試一下代碼評審，是對這個解決辦法存在擔心的。咱們採用stylecode工具來作靜態代碼檢查，咱們最後作到了零問題，基本上迭代完成前開發人員都會把stylecode檢查出來的問題清理掉。靜態代碼檢查能夠保證你們代碼編寫的規範與一些基本問題，但一些深層次的業務邏輯問題是發現不了的，因此仍是得靠人來手動檢查。剛開始爲了減小團隊在代碼評審中的矛盾，鼓勵你們分享本身寫得好的代碼，而不是你們一塊兒來找茬。好比H君寫了一個公共方法你們都有可能用到，Y君在使用某個控件中碰到的一些問題等等。經過這個會議來增強開發的分享，同時咱們使用有道雲筆記創建了團隊的知識分享小組，這樣你們在碰到一個已經解決的問題能夠從中查找。

    代碼評審咱們一個迭代作兩次，第一週的週五下午2個小時，第二週的週四下午2個小時，在第一個週五的時候基本你們都有故事完成了，因此提早進行代碼評審，由於若是全拖到第二週的話，可能有些問題沒有能提前發現，致使越到後面發現的話修改的代價更大一些，還有就是所有開發完成再作的話花費的時間會更長。第二週的話基本上週四開發都已經完成本身的故事，週五上午作集成測試，下午開迭代評審會議和回顧會議。

    我通常建議你們在講本身的代碼的以前，必定要組織好本身的語言，提早過一遍或者準備幾張時序圖，這樣在講解的時候更有條理性，本身講都講不清的話，可想而知代碼的質量也只有這麼好。另外針對核心算法畫的時序圖能夠補充到以前作得設計文檔中去，完成設計文檔。還有就是一些有問題的代碼和好的代碼都會記錄下來，好的編寫知識分享，很差的記錄跟蹤，持續改進。

    咱們還嘗試過一些其餘的代碼評審方式，好比在代碼提交前由開發主管統一評審，只有評審經過後的代碼才能commit，後來發現這種方式比好執行，一下就拉下了團隊的開發速度，而後就是開發主管也沒有這麼過精力來作這件事情，因此作出來的效果也不咋的。接下來咱們想嘗試開發之間相互評審對方的代碼，這樣能更多的深刻到代碼本質，但同時也對團隊的要求更高，因此得一步一步來，持續改進。

    作這個代碼評審確實仍是給團隊好的方面，代碼的分享確實提升瞭解決問題的效率，碰到的一些技術問題，若是以前有人碰到過，那基本很快就能解決。不用本身獨自浪費時間來研究解決。再有就是對新人的幫助很大，新人會在這個會議上更好的學習框架的使用，功能代碼的實現與得到問題的詳細解答。

 

    總之，我以爲代碼評審確實能夠提高產品質量與提高團隊開發能力，可是必定要注意方法方式，不能操之過急與生搬硬套。