Code Review的癥結點

Code Review的癥結點

有多認真?(要檢查到什麼程度?)

  1. 標準嚴格了,被Review的人好一點覺得很沮喪,差一點覺得被找碴。
  2. 標準鬆了,問題沒有解決,根本就是得過且過,上下交相賊,橡皮圖章,真的浪費工時。更徒然傷害到那些認真Review的人。
  3. Review一次,改完上傳之後要不要再來Review?(這叫Review的Review,說不定還會有Review^3)一個問題是否要無限制的完美下去?什麼叫完美?是設計的不完美?效能的不完美?風格的不完美?還是人格的不完美(就是看你不爽啦)?
  4. 其實終究到底就是Quality Assurance的問題,是不是白箱黑箱都測過了就算過?如果連規格都不清楚,規格每天在變,怎麼會有測試(總要知道終點在哪裡才知道差多少吧)。既然連測試都過不了,出貨都有問題,怎麼可能做到Code Review這一層。

誰來Review?(Review怎麼算credit?)

  1. 資淺的工程師自己寫code都有問題了,哪還有標準跟水平去Review別人的Code。這其實呼應到上述的"有多認真“。如果只是檢查命名規則,記憶體有沒有釋放,變數有沒有初值,那就簡單得多大家都能做。甚至請資工系工讀生來照表操課都可以。
  2. 資深的老手一定是負責重要的工作,自己都沒空了,還要撥時間來改考卷。同樣呼應到上述的"有多認真“。改鬆了,只是敷衍。改嚴格了還要被同僚討厭。大家都是出來混,何必要平白為了主管的政策多樹立一個敵人。
  3. 若是用一個老手配一個新手的方式,是否有足夠的老手?每個老手的風格不一樣,會不會反而用壞習慣帶壞新手?
  4. 若是採用定期開會review一個盯一個像火車一樣的方式,菜鳥釘到老手以後是不想混了是吧。若真有問題卻找不到問題,反而變成菜鳥開會被罰站的窘境(你到底有沒有認真看啊?)。
廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s