Re: [轉錄] Code Review: 大家都應該做的事情

看板Soft_Job作者 (沉默是金。)時間13年前 (2011/08/02 01:17), 編輯推噓5(5推 0噓 40→)
留言45則, 10人參與, 最新討論串2/18 (看更多)
※ 引述《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
推
08/02 01:22, , 1F
其實還有一種狀況大家會不喜歡做 code review，每個人負責
08/02 01:22, 1F
→
08/02 01:22, , 2F
的業務各自不同但又很複雜，要理解三行程式可能得先花三天
08/02 01:22, 2F
→
08/02 01:23, , 3F
搞清楚對方的業務的時候。雖然彼此之間有個照應是好，但這
08/02 01:23, 3F
→
08/02 01:23, , 4F
門檻會比較高一點...
08/02 01:23, 4F
→
08/02 01:34, , 5F
這其實可以被我的1,2 兩個條件cover掉 XD
08/02 01:34, 5F
推
08/02 01:36, , 6F
呵呵，真正的理講得很貼近啊。
08/02 01:36, 6F
→
08/02 01:54, , 7F
我想知道要怎麼跟業務範圍不同的同事做pair ._. /
08/02 01:54, 7F
→
08/02 01:58, , 8F
我的作法是我什麼都學一點 這樣就可以跟他們pair了 XD
08/02 01:58, 8F
→
08/02 01:58, , 9F
我們公司有作Eclipse plug-in 的，有作元件的，有作webapp的
08/02 01:58, 9F
→
08/02 01:59, , 10F
基本上我都可以作到一定程度的支援跟pair，雖然比不上專任。
08/02 01:59, 10F
→
08/02 01:59, , 11F
當然這樣的作法是有點暴力就是了。:p
08/02 01:59, 11F
→
08/02 02:00, , 12F
如果說你們的領域已經切到只有一個人會 另一個人完全幫不上
08/02 02:00, 12F
→
08/02 02:00, , 13F
忙，那當然是沒啥好review的，叫寫java的去review寫c++的...
08/02 02:00, 13F
→
08/02 02:00, , 14F
那自然是沒轍 囧rz
08/02 02:00, 14F
→
08/02 02:02, , 15F
能力不重要的前提是有常識 XD
08/02 02:02, 15F
→
08/02 02:07, , 16F
你說的是技術面的,我說的是同技術但是domain knowledge不同
08/02 02:07, 16F
→
08/02 02:07, , 17F
可能光是說明來龍去脈就滿頭大汗的這種情況..也是沒輒囉?
08/02 02:07, 17F
→
08/02 02:08, , 18F
嗯 比方說 table 怎麼 join , 怎麼弄 , 基本上這種domain
08/02 02:08, 18F
→
08/02 02:08, , 19F
沒辦法有張白板半小時內解決的話，那就沒轍。
08/02 02:08, 19F
→
08/02 02:08, , 20F
通常我們在討論這個level的問題都會抽象來看solution，
08/02 02:08, 20F
→
08/02 02:08, , 21F
用小圈圈跟箭頭的方式來跑思維，對思維作review。
08/02 02:08, 21F
→
08/02 02:11, , 22F
或者強一點的就是api切清楚 只討論input / output
08/02 02:11, 22F
→
08/02 02:11, , 23F
一次只review一小段 這樣就只需要解釋一個method
08/02 02:11, 23F
→
08/02 02:12, , 24F
盡可能去涵蓋覆蓋率啦。 :P
08/02 02:12, 24F
推
08/02 23:08, , 25F
你還是可以 review code style 和基本實作啊
08/02 23:08, 25F
→
08/02 23:09, , 26F
沒有完美的 code review, code review 本來就是希望
08/02 23:09, 26F
→
08/02 23:09, , 27F
多 20% 投入以增加 80% 的守備, 為了 review 去 K 演算法
08/02 23:09, 27F
→
08/02 23:10, , 28F
反而不見得有利, 個人意見
08/02 23:10, 28F
→
08/03 00:48, , 29F
我總覺得去review 別人的摳style最容易引戰
08/03 00:48, 29F
→
08/03 02:30, , 30F
所以我說 同事的感情很重要～
08/03 02:30, 30F
→
08/03 06:42, , 31F
最近聽到一句蠻經典的話：只要解釋得出來為什麼這樣寫~那
08/03 06:42, 31F
→
08/03 06:44, , 32F
就可以接受~只要不是一昧的說"我就是不要"這樣就好了...
08/03 06:44, 32F
→
08/03 14:49, , 33F
有些programer會有"以你的程度我很難解釋"的心理障礙XD
08/03 14:49, 33F
推
08/03 14:57, , 34F
單兵作戰如何實行Code Review?
08/03 14:57, 34F
→
08/03 15:18, , 35F
單兵作戰 （只有一個人） 的情況下沒辦法review XD
08/03 15:18, 35F
→
08/03 21:15, , 36F
要先練成影分身
08/03 21:15, 36F
推
08/03 21:32, , 37F
1.時程很趕,程式寫完都沒時間測試了..
08/03 21:32, 37F
→
08/03 21:33, , 38F
2.有時間有空間自然是做到好Debug到一定的要求
08/03 21:33, 38F
→
08/03 21:34, , 39F
3.通常是看到有些人的寫法就囧了...
08/03 21:34, 39F
→
08/04 01:24, , 40F
[問]有人method裡,用到三層巢狀是基本款,要怎麼提點才好?
08/04 01:24, 40F
→
08/04 01:27, , 41F
我對method的態度一向都是看method再不在主幹
08/04 01:27, 41F
→
08/04 01:27, , 42F
如果是private method 牽連又不多 又沒有static field的話
08/04 01:27, 42F
→
08/04 01:27, , 43F
不一定需要處理。
08/04 01:27, 43F
→
08/04 01:50, , 44F
我很少用層次分的 我都是看一眼掃過去好不好讀
08/04 01:50, 44F
→
08/04 01:56, , 45F
那public,一個if裡面有3層, 總共200+行以上在這if裡
08/04 01:56, 45F
‣ 更多 TonyQ 的文章
文章代碼(AID): #1EDj_6II (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 18 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共18篇)
‣ 更多 TonyQ 的文章
文章代碼(AID): #1EDj_6II (Soft_Job)