上午我所在的項目組花了半個小時的時間完成了一個人的code review，兩天的量，因為昨天也沒有review。也就是說還有五個人的code沒有給到大家去review。
影響是啥呢？代碼壞味道的堆積。今天只review了一個人的，明天可能也只是一個人的，情況好一點是把這個人昨天的也能看完。那么到明天的這個時候實際上是9個人天的code沒有被review到，僅僅只算這兩天的，以前的還沒算進去。其實已經(jīng)失去及時改進的機會。效果不佳。當代碼堆積，一直在review以前的代碼時，人們的記憶有點模糊的，可能還要思考一會才知道為啥這么寫，review時間本身就不夠，回憶還要花掉一部分，效率明顯不高。knowledge沒有及時共享，記得前幾天和pair做卡。push代碼的時候發(fā)現(xiàn)有些重復了，如果提前知道這件事一定會去confirm，而不是還要再做一遍。另外一方面一些好的方法手段以及遇到的挑戰(zhàn)沒有及時告知給團隊，也許其他人就不會花同樣多的時間去做研究。有可能影響測試。當我們check完之后再去review代碼，去做重構工作，新提交的代碼并不能百分之百地保證對功能沒有一絲一毫的影響，假設那時候相應的功能已經(jīng)測完了，新的改動理論上應該要回歸的，同時也加大的測試的工作量，如果及時review及時重構基本上就能保證代碼的質量在團隊的所有開發(fā)人員這里是過關了的。
造成這種現(xiàn)象的原因很多。比如下午的各種各樣的會的沖突，比如沒有一個regular的時間，每次想訂的時間會議室unavailable，其實反而有一個好處，當沒有會議室的時候我們會選擇站著review，效率相對會快很多，坐著的時候都不想動彈，就想一直那么討論下去。即便retro上提過這個regular的review，也會因為要showcase繼續(xù)往后推。實際上有后悔沒有強行建議去review，即便是showcase也不應該影響review的。半個小時的時間能怎么影響showcase啊。當然重要的是還沒有成熟穩(wěn)定下來。
寫到這里我想到需要一個owner每天到點喊大家review，每次不是我就是我們tech lead，忙的時候就沒人喊了。不管有沒有誰在開會，不管是否缺少了一兩個dev，review照常進行，沒講的下次一并講了。繼續(xù)解決的代碼壞味道堆積的問題就需要跟大家強調這周必須要趕上應有的進度了。迭代剛開始，有一定的時間去做這事。
code review在交付團隊中是非常重要的環(huán)節(jié)，也是一個所有開發(fā)聚在一起討論技術細節(jié)的非常好的機會。我一直push在團隊中有一個完善的review的機制，同時我自己也矛盾，因為更想關注前端技術棧，那些看著沒有感覺的后端代碼著實沒啥吸引力?？嘤陧椖壳岸肆α勘∪?，也是無奈。
