Code Review 大家都應該做的事情

作者: TonyQ (沉默是金。) 看板: Soft_Job
標題: Re: [轉錄] Code Review: 大家都應該做的事情
時間: Tue Aug  2 01:17:55 2011


※ 引述《TonyQ (沉默是金。)》之銘言：
: ◆ From: 12.208.243.66
: 推 shadow0326:這又是一個大家都知道是對的 但實務上難以落實的例子QQ  08/01 10:27
: 推 jimmy701010:東西都弄不完，只能先丟上去了...要REVIEW真的...      08/01 12:18
: → TonyQ:code review 事實上心理障礙比實作障礙來得大很多            08/01 12:48
: → TonyQ:當然對於單兵作戰的單位 實作就幾乎是不可能就是             08/01 12:49
: 推 ripeSelf:code review如果沒有後續的追蹤修改等，等於就是浪費時間  08/01 21:21
: → ripeSelf:常見的情況是，新的功能做不完，就算排了code review，    08/01 21:21
: → ripeSelf:也只是講爽的而已，就算覺得哪裡需要做修改，只要目前     08/01 21:21
: → ripeSelf:可以run， 通常就不會改，放久了，當然更不會去改，接下   08/01 21:21
: → ripeSelf:來，當然就是連code review也停了。然後再過一些時間，再  08/01 21:22
: → ripeSelf:發生大bug，然後就說怎麼沒有code review，再排上去，然   08/01 21:22
: → ripeSelf:後就這樣循環。                                         08/01 21:23

        1.目前可以 run 基本上就是夠用了，日後發生的事情都是日後諸葛。
          至少不要出現typo / sql injection之類的白痴錯誤，

          是我認為 code review 的基本目的，確保程式碼的基本品質。

          這件事情「感覺」起來很像浪費時間，但其實一點也不浪費，
          至少我有機會就會跟同事作 pair ，對一些比較沒把握的部份，
          效果會非常的好。

        2.分享知識，重點在下次再寫的時候，會不會寫得更好。

          第一次一團漿糊難免，寫了十次還是一團漿糊，那就有點囧。

          越趕時間越沒資源的地方越講求單兵戰力，
          這種隨時可以跟進的教育其實也很有價值。


        你回的這些推文剛好就都是我所謂的「心裡門檻」。


        其他的心裡門檻不外乎是個掃門前雪，時程很趕...etc


        你們會時程很趕就不作smoke test嗎？（那怎麼出貨？）

        時程很趕就能夠讓客戶看到error嗎？ （那怎麼跟客戶交待？）


        既然時間很趕有些項目還是不能省的， code review 為什麼是能省的。:)


        時程很趕不是省 item 的好說法，

        真正的理由通常是

        1.同事的感情沒有好到可以互相review
        2.我不在乎程式碼的品質 出事不要燒到我就好
        3.我覺得我的程式碼已經夠好了


: → newjoy:"人人都有能力code review"的環境也很重要啦...             08/02 00:02

        其實 code review 的重點是 "信任"，不是能力，

        能不能接受別人批評，能不能接受別人意見；

        會不會因此被拿出來批鬥，會不會一直被對人不對事，

        都會影響人接受 code review的意願。


        Code review 並不是單方面的接受指導，每一個建議都需要有夠好得理由。

        被 review 的一方也不一定要接受，就像原文講得，
        code review 的時候常常都會陷入「覺得自己的寫法比較好」的困境，


        但其實 code review 只是為了確保 wrost case 有被考慮到，
        沒有離譜的 typo 或大的安全性漏洞，這樣他的價值就已經夠高了，

        更不提還外加有 training 的功能。


        最重要的是，因為有人會需要讀你的程式碼，
        所以你會想一想要怎麼讓別人讀比較讀得懂。

        Code review 是因為這些「動機/理由」而把程式碼品質變好，

        而不是說 code review 就像是程式碼清潔器一樣掃過去 code 就會自己變好，
        沒這回事，那只是不切實際的幻想。XD


--
我：一半的日子讓你說，我聽你說你的所有______________________________________
______________________________________一半的日子我想說，對你說過去的所有：我
        _______________________________________________________

        在討論中妥善扮演兼具聆聽與分享的角色，是我們一生的課題。
        _______________________________________________________

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 198.203.175.175
推 Hiigara:其實還有一種狀況大家會不喜歡做 code review，每個人負責  08/02 01:22
→ Hiigara:的業務各自不同但又很複雜，要理解三行程式可能得先花三天  08/02 01:22
→ Hiigara:搞清楚對方的業務的時候。雖然彼此之間有個照應是好，但這  08/02 01:23
→ Hiigara:門檻會比較高一點...                                     08/02 01:23
→ TonyQ:這其實可以被我的1,2 兩個條件cover掉 XD                    08/02 01:34
推 ripeSelf:呵呵，真正的理講得很貼近啊。                           08/02 01:36
→ newjoy:我想知道要怎麼跟業務範圍不同的同事做pair ._. /           08/02 01:54
→ TonyQ:我的作法是我什麼都學一點 這樣就可以跟他們pair了 XD        08/02 01:58
→ TonyQ:我們公司有作Eclipse plug-in 的，有作元件的，有作webapp的  08/02 01:58
→ TonyQ:基本上我都可以作到一定程度的支援跟pair，雖然比不上專任。  08/02 01:59
→ TonyQ:當然這樣的作法是有點暴力就是了。:p                        08/02 01:59
→ TonyQ:如果說你們的領域已經切到只有一個人會 另一個人完全幫不上   08/02 02:00
→ TonyQ:忙，那當然是沒啥好review的，叫寫java的去review寫c++的...  08/02 02:00
→ TonyQ:那自然是沒轍 囧rz                                         08/02 02:00
→ TonyQ:能力不重要的前提是有常識 XD                               08/02 02:02
→ newjoy:你說的是技術面的,我說的是同技術但是domain knowledge不同  08/02 02:07
→ newjoy:可能光是說明來龍去脈就滿頭大汗的這種情況..也是沒輒囉?    08/02 02:07
→ TonyQ:嗯 比方說 table 怎麼 join , 怎麼弄 , 基本上這種domain     08/02 02:08
→ TonyQ:沒辦法有張白板半小時內解決的話，那就沒轍。                08/02 02:08
→ TonyQ:通常我們在討論這個level的問題都會抽象來看solution，       08/02 02:08
→ TonyQ:用小圈圈跟箭頭的方式來跑思維，對思維作review。            08/02 02:08
→ TonyQ:或者強一點的就是api切清楚 只討論input / output            08/02 02:11
→ TonyQ:一次只review一小段 這樣就只需要解釋一個method             08/02 02:11
→ TonyQ:盡可能去涵蓋覆蓋率啦。 :P                                 08/02 02:12