想請問各位大大，關於各位在公司 code review 的時間點
會問這個問題是因為目前小弟在公司中因為開發時間較快，所以遇到需要 code review 時會跟其他工程師說一聲需要 code review，不過這樣會導致常常思考到一半會被打斷，所以想知道各位大大在公司上班時，會預留時間做 code review，然後其他時間專心開發，還是一樣會打斷對方，然後請其他工程師幫忙 code review 呢？又或是都沒有在 code review 呢？
已邀請的邦友 {{ invite_list.length }}/5
看了您底下回覆版友的內容,我比較好奇的是您們怎麼作Code Review?
三個人是互相Review嗎?每個人的程度又各是如何?
千萬不要是因為有規定要作Code Review而在作Review,這樣真的沒意義,三個人的小團隊應該不會有溝通問題吧~~
您好，目前團隊的確是三人互相review，至於程度部分，大家都有約一年半左右的工作經驗，然後您講到重點了:千萬不要是因為有規定要作Code Review而在作Review，這也是我最近在考慮廢除code review的一個原因，因為慢慢有感受有些團員其實就只是隨便看看，所以感覺也沒有review的必要了
我的意思不是要您們不作Code Review,而是希望您們去找出最適合您們團隊的工作方式。
我試推以下幾種情境,您們參考下:
三個人雖然都一年半工作經驗,但我相信Coding的功力還是有差別的?這個您們應該自己心裡有數。
情境一
如果功力差不多,三個人互相檢查是OK的,只要大家談好,每天固定的時間段作交叉的Review,一~三個月左右換人Review,這樣大家都能熟悉彼此的撰寫程式的風格,截長補短,久而久之大家風格會趨於一致,大家共同進步
情境二
如果是其中一位(A)比較厲害,另兩位差不多,則建議A降低Coding工作量,其他兩位(B、C)的程式碼都由A Review,A的程式碼由B、C看是分攤來Review當作學習
情境三
如果是A>B>C,則建議C給B Review,B給A Review,A給C Review
總之,Code Review不只是在預防個人盲點寫出Bug,也有在建立團隊開發風格及讓大家相互進步的動力,千萬不可以廢!!
喔喔，我誤會您的意思了！目前的情況應該是屬於情境二，至於之後的 Review 方式，我會參考一下您給的建議，看能不能降低A的工作量，然後去幫B,C Review(現在A的工作量算是團隊中最重的)
通常會抓個時間，cycle就是
需求>開發>local 測試>code reivew>apply pull request
平常可能各自還有任務，有的沒的會議要開
所以通常會講好XX天XX時有PR就看一下，沒有就散會
除非很緊急的那種是例外
每家公司可能會有不同的流程和規定，但通常會有專門的時間點或者階段來進行 code review，而不是在開發過程中隨時進行。
這樣可以避免打斷其他人的工作，也可以專注地進行 code review。
如果有需要在開發過程中進行 code review，可能會和其他工程師事先約好時間，避免相互影響。
建議你可以和你的主管先溝通建立團隊的規章，並根據實際情況進行調整。
通常來說 code review 會交由團隊主管去做
其他開發人員反而是自己開發、測試完後
通知團隊主管進行檢視，這樣才不會耽誤開發時程
除非開發人員有空，否則不應該在急忙中幫別人 code review
我們是一季一CodeReview，比較沒有什麼緊急問題
確認CodeReivew時程後，也比較好整理好自己的部分
要執行Review以及被Code Review的都清楚時間，就不會有你的問題了
iThome鐵人賽
看影片追技術