Code Review 大家都應該做的事情 4

作者: ledia (下班後才下棋) 看板: Soft_Job
標題: Re: [轉錄] Code Review: 大家都應該做的事情
時間: Sat Aug 20 15:19:50 2011

  實行 Code Review 是為了增進程式碼的品質
  但是增進程式碼的品質, Code Review 只是其中一種方式
  其他可以作的太多了

  比如說導入自動測試: 單元測試, 整合測試
  比如說自動偵測程式碼: 靜態程式碼分析, 動態程式碼分析,
                        coding style 檢驗, dependency check
  比如說 QA 測試, alpha, beta 測試
  比如說 Design Review, Interface review 等等

  不僅只於上述的這些項目, 都可以診斷出有問題的程式碼

  但也因為要做的事太多了, 不太可能所有的流程都走完
  所以得要有人去定義各種測試或 review 的守備範圍在哪
  這並不容易

  比如說如果沒有自動化的 coding style 檢驗
  code review 是不是也要檢查 coding style ?
  比如說如果沒有寫 unit test 的習慣
  code review 是不是也要人工去初步驗證每個函式都大概是對的 ?

  如果沒有 code review, 也沒有 unit test
  那是不是問題都要到 integration test / QA 才找得到 ?
  這樣對於解決單一問題需要的時間總是會拉長許多

  所以我認為 code review 是不能單獨拿出來講的
  對於不同的公司, 不同的環境, 不同的人力素質, 甚至是不同的制度
  都可能會需要有不同的 scope

  再舉個例子, 比如說如果我們規定程式碼在 commit 之前
  一定要有至少一個 senior engineer 等級以上的人 review 過
  那麼我們在公司制度中, 能夠升上 senior engineer 的條件
  也就應該得要有 "有能力做出什麼程度的 code review" 的規範
  這甚至跟公司的升遷制度是習習相關的

  沒有一家公司或團隊能在一開始就找到最適合自己的方式
  但是隨著軟體開發, 這是個可以不斷改進的過程
   code review 的守備範圍永遠是可以被討論或調整的

  至於我自己喜歡的 code review, 綜合前面回文的人的看法
  我認為 code review 需要作到的是:

   1. 確定寫程式的人, 真的寫出了所有他宣稱的功能
   2. 知識分享, 有時候資深的人拿一些關鍵的改動給資淺的人 review
      也是一種知識分享
   3. 知道有人會要看自己的程式, 也就不會花招亂出
   4. 可讀性, 這是可以有一些多數決的準則的

  至於 coding style 能夠用程式自動做完的, 就讓程式來作
  至於 unit test, 不是十萬火急的情況, 預設都要做, 會節省未來很多時間的
  至於架構上的問題, 早在 design review 就應該要解決, 後期改 design 的痛苦之大.....

  再完善的制度都會有適用上的問題, 也會有人的問題
  如果公司裡的員工先入為主的觀念抵制這些制度
  又或者是上下交相賊, 沒看過 code, 也能通過 review
  那也不可能推行的順利

  人的問題, 也許就是經營團隊需要傷腦筋的地方了

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.112.30.49
※ 編輯: ledia           來自: 140.112.30.49        (08/20 15:23)
推 TonyQ:Agree. 不管到哪, 人的管理幾乎都是第一要素.                08/20 16:12
→ remmurds:同意這篇                                               08/20 17:32
推 loveme00835:                                                    08/20 19:53
推 screaming:推，code review到底在review什麼，是重點！             08/21 10:37