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

作者: Pjack (pjack) 看板: Soft_Job
標題: Re: [轉錄] Code Review: 大家都應該做的事情
時間: Thu Aug 18 03:24:33 2011



我覺得 Code review 之於軟體, 就和品管之於硬體一樣
只是因為硬體的標準很明顯, 很容易定, 所以品管也就很容易幫助品質增加
相對的, 因為軟體的標準是不容易定的, 也就造成大家覺得 Code review
經常是白費功夫, 我自己並沒有專研過這方面的理論
但看過很多 Open Source 的專案都一定有這道手續,
難道這些人比台灣人笨, 所以才傻傻的做 Code review ??
我怎麼想都不覺得是這麼一回事, 我反而會覺得是因為台灣的軟體工程
還沒了解 "該怎麼做 Code review 才有效益", 所以才會覺得這是沒有用的

舉一個例子 Open Source 的案子
https://blueprints.launchpad.net/nova/diablo


再來是台灣企業多半是硬體起家, 公司內的軟體人材都在做 driver
driver 在大部份的狀況是要求會動, 下個產品和這個產品未必會有關係
所以也造就了 "只要求會動就好" Code review 有很重要嗎? 一點也不重要
為了一個三個月就要做出來的案子, 之後再也不用maintain, 也不用擴充
還特地派一個人去看你的 code, 真的值得嗎?
我的意思並不是說 driver 很好寫, 而是主要在說明很多軟體的生命週期很短
所以 code review 相對下就不是那麼必要,
而台灣也在這樣的環境下, 老闆們才會認為 code review 不值得

但當你的軟體生命週期很長時, 以及在大型軟體專案的狀況下
Code review 就變的很重要了, 如果沒有這樣的動作,
到了要整合, 或是要進版/加新功能時, 都會讓整個專案很難進行
老實說, 我也實在無法清楚的定義 Code review 該做什麼,
因為我不是專家, 我只能舉一些過去自己的經驗,
剩下還希望有軟體工程的專家出來補強

1. 看架構對不對?

   這裡並不是看你的設計有沒有問題, 設計有沒有問題早在初期 Design Review
   就要發現, 這裡是看你是否有按照設計在做, 有些人非常有意思
   設計時講的非常棒, 但實作時又完全不按照設計做
   有些偏好理論研究者, 就常會做這種事
   (這讓我想到, 理論很強者, 實作不一定很強, 反之亦然)

2. 是否按照 Spec 實作介面 ? 以及介面是否符合一般常理?

   和第一點很像, 但這個比較簡易, 就是單純檢查和當初定的有沒有一致

3. 大型專案會規定 Coding Style, 或是 Coding Convention
   檢查是否有符合這些規定, 減少接手的人還要習慣各種不同的
   coding style, 也可以幫助新手養成正確的好習慣

4. 是否有按照開發指南來開發? 有些指南是老手留下來的重要資訊
   按照這樣的方式來實作, 可以得到比較好的 Performance
   或是其實這樣才是當初設計這個 framework 的預設用法

   ex: Android Dev Guide
   http://developer.android.com/guide/index.html

5. 是否有明顯漏掉的流程, 或是 Bug
   除了人工檢查外, 也有工具可以幫助檢查, 像是 Eclipse Plugin -- FindBugs
   或是要錢的 Klocwork, 人工的部份主要是看大方向的 bug,
   ex: 應該跑A流程, 但跑了 B 流程
   至於 memory leak 這種事就交給工具去找吧!

6. 其它

   a. 程式是否夠模組化, 未來要擴充功能時, 是否又需要大改?
   b. Memory 使用是否合理

暫時想到這些, 還請多指教 :)



提外話, 我覺得軟體是要靠大量的累績及不斷的重覆使用下才能進步的
如果台灣的軟體產老是留在 "每次都重頭做起"
或是留在 "拿別人寫好的東西來改一改就交差"
那我們就永遠都只能做別人剩下不做的東西, 那又何必要 code review?
反正又不能重覆使用, 也不需要擴充, code 寫的再好看又如何?

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.167.241.196
※ 編輯: Pjack           來自: 218.167.241.196      (08/18 03:26)
※ 編輯: Pjack           來自: 218.167.241.196      (08/18 03:32)