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

看板Soft_Job作者 (高個子)時間13年前 (2011/08/17 02:51), 編輯推噓5(5推 0噓 41→)
留言46則, 12人參與, 最新討論串5/18 (看更多)
Code review? 別鬧了吧. 一家公司有能力做code review的有幾個? 好啦, 即使有人可以review, 並review出問題了, 有能力改嗎? 不可能吧. 就是因為經驗不足才會有這種狀況啊! 光是提出問題, 就能讓程度不夠的人立刻升級嗎? 不可能啊! 許多經驗不足, 但覺得自己很強的高手(通常是寫code不到十年的), 雖然寫code速度快, 博學多聞, 資料結構一把罩, 說起架構, design patterns 也是頭頭是道. 但寫起code來, 總是code架構不佳, 不好maintain. 這不是懂的多不多的問題, 也不是努力不努力的問題, 純綷是歷練的問題. 有些能力, 特別是code的架構安排,沒有長時間的體會, 就是不會到達那個火喉. 不服氣的人, 回去看看你去年寫的code, 如果你覺得去年寫的code讓 自己很驚艷, 那你就算是有經驗的programmer. 如果覺得自己程度明明很好, 但怎麼寫的code普普通通, 我說, 你就是經驗還不足. (我沒說未來無法達到這程度喔) 這麼說好了, code review之所以知易行難的原因是: review所出現的問題中, 無法處理的問題, 都是code的架構問題, 這些東西和programmer的經驗有關. 無法透過短期/長期教育來提升. 所以, 有能力改的人, 不用review, 自己也會在過程中修正. 沒能力改的人, 也不用改了. 多改只是create愈多問題. 至於那些像 SQL injection 要改成 bind variables, lookup table 用array, naming styles 不一致, code 亂成一團, 常常有超大method/class, copy-paste code一堆這些東西等問題. 如果到了要處理的程度, 那麼在處理之前, 先fire寫這些code的人吧. 唉...要被噓暴了. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 203.69.151.170
推
08/17 02:53, , 1F
好像有道理喔
08/17 02:53, 1F
→
08/17 03:41, , 2F
怎麼覺得你把code review想成很高級 大部份的其實就防呆而已
08/17 03:41, 2F
這是處理問題的角度問題. 如果A,B,C,D,E等人, 寫code常常出一些"呆呆"的包. 加法思考: 1. 使用甲計劃來防呆. 2. 甲計劃如果再有漏洞, 那再出乙計晝來防止甲計劃出包. 3. 乙計劃如果再有漏洞, 就再出丙計晝來防止乙計劃出包. 4. loop 直到大家都有做不完的事, 然後再請F,G,H,I,J,K等人來執行防呆計劃. 減法思考: 1. 砍掉A,B,C,D,E等人, 換甲,乙,丙,丁,戊來寫code. 2. 甲,乙,丙,丁,戊還是出"呆呆"的包. 再砍甲,乙,丙,丁,戊, 請請一批人 3. loop直到因為一直換人, 沒人做事, 垮掉了. 所以, 制度解決不了問題. 於是, 問題就簡單了, 回到原點: 找對的人, 做對的事. 做研發的工作, 依靠對的人, 永遠比依靠制度要保險. ※ 編輯: yy938559 來自: 203.69.151.170 (08/17 04:47)
→
08/17 04:47, , 3F
programmer 的歷練有關，但是教育還是很有效的吧。
08/17 04:47, 3F
→
08/17 04:47, , 4F
有些真的很弱的人是真的應該fire掉沒錯，但有 code review也
08/17 04:47, 4F
→
08/17 04:48, , 5F
能幫助你更快得讓那些有能力的人早一點站上高位。
08/17 04:48, 5F
→
08/17 04:48, , 6F
我知道有些人是認為那些人應該自己站到頂端，某個角度上我也
08/17 04:48, 6F
→
08/17 04:48, , 7F
很認同這件事。但是捫心自問你我，有多少的經驗是透過提問跟
08/17 04:48, 7F
→
08/17 04:48, , 8F
前輩求解而快速獲得自己原本久試不得的問題？
08/17 04:48, 8F
→
08/17 04:49, , 9F
這種經驗不需要多，但每碰上一次都是可以大幅提昇很多的。
08/17 04:49, 9F
→
08/17 04:49, , 10F
code review 本身就是一個促發這件事情的媒介。
08/17 04:49, 10F
→
08/17 04:50, , 11F
即使我們都知道該被淘汰的人遠比有能力者多很多，但目前應該
08/17 04:50, 11F
→
08/17 04:51, , 12F
一邊進行人才的篩選，另一邊進行人才的培養，雙管齊下才是。
08/17 04:51, 12F
→
08/17 04:54, , 13F
另外，也有很多地方根本找不到對的人。理由很多。
08/17 04:54, 13F
→
08/17 04:56, , 14F
這其實也是個值得討論的話題，一起討論好了。:)
08/17 04:56, 14F
老闆們不做code review原因如下: 1. 雖然不了解code, 被工程師騙去做code review很多次了, 再也不相信狼來了. 你有聽說過被寫爛的code被救成好code嗎? 寫過code的人都知道... 這不可能發生嘛! 2. 同上, 老闆早就知道爛code不可能改成好code. 又不是沒被騙過, 當然不review啊. 結論, 不是老闆的人, 才會想做code review啊. 這樣說有道理嗎? ※ 編輯: yy938559 來自: 203.69.151.170 (08/17 05:08)
→
08/17 06:18, , 15F
照你的推論 也不會有製造公司做品管才對
08/17 06:18, 15F
→
08/17 07:04, , 16F
品管? 好奇怪的類比
08/17 07:04, 16F
推
08/17 07:38, , 17F
品管的效果看得到 (畢竟就是bug不給過吧), code review
08/17 07:38, 17F
→
08/17 07:39, , 18F
的效果看不到 (結構改了有好嗎? 可能連負責改的人也
08/17 07:39, 18F
→
08/17 07:39, , 19F
說不上) :P
08/17 07:39, 19F
→
08/17 07:41, , 20F
看看Vista rewrite當時有多少人在說是錯誤的決定吧...
08/17 07:41, 20F
→
08/17 07:54, , 21F
code review效果不會看不到吧 反映在bug count一定有的
08/17 07:54, 21F
→
08/17 07:54, , 22F
這就跟生產線上加工後馬上做驗證一樣,都會反映在下游成果的
08/17 07:54, 22F
→
08/17 08:34, , 23F
爛code當然可能改成好code。
08/17 08:34, 23F
→
08/17 09:06, , 24F
所謂的品管只是規格已經訂出來，然後看有沒有符合標準
08/17 09:06, 24F
→
08/17 09:07, , 25F
至於有沒有符合標準與產品能不能用是兩個獨立事件
08/17 09:07, 25F
→
08/17 09:07, , 26F
品管無法判斷產品好壞
08/17 09:07, 26F
→
08/17 09:08, , 27F
review最難之處應該是無法定質或定量的心證吧
08/17 09:08, 27F
→
08/17 09:09, , 28F
或者若要達成共識可能要耗費不少時間跟精力來溝通
08/17 09:09, 28F
推
08/17 10:11, , 29F
在敝公司內，老大說"請你review這段code"的意思就是
08/17 10:11, 29F
→
08/17 10:11, , 30F
1.給你學習的機會 2.這東西以後你也要維護
08/17 10:11, 30F
→
08/17 11:16, , 31F
爛code當然可能改成好code+1 我就常改寫code= =
08/17 11:16, 31F
→
08/17 11:17, , 32F
畢竟很少有code是寫好之後一輩子不會改的 隨著客戶的無理(?)
08/17 11:17, 32F
→
08/17 11:18, , 33F
要求 一定會要去動寫好的東西 也常常改別人寫的code
08/17 11:18, 33F
推
08/17 16:25, , 34F
我不確定 code review 對原 po 有沒有用
08/17 16:25, 34F
→
08/17 16:25, , 35F
我可以確定的是我絕對不想跟原 po 當同事..
08/17 16:25, 35F
→
08/17 16:26, , 36F
真的是一堆鬼話..
08/17 16:26, 36F
→
08/17 20:13, , 37F
雖然我經驗很嫩，但我覺得原po的說法比較像還沒做就先
08/17 20:13, 37F
→
08/17 20:14, , 38F
說做了絕對失敗...用這種想法做當然也不可能會成功呀
08/17 20:14, 38F
→
08/17 21:27, , 39F
5年,10年,15年和20經驗對code review的觀感會不一樣.
08/17 21:27, 39F
→
08/17 21:28, , 40F
以我的經驗來看,code review就是理論派,浪費時間的動作.
08/17 21:28, 40F
→
08/17 21:29, , 41F
不過,我這種lkk的人的看法, 一點都不具意義,大家笑笑就好
08/17 21:29, 41F
→
08/18 01:52, , 42F
別鬧了,code review不是在處理code的架構好不好的問題,
08/18 01:52, 42F
→
08/18 01:54, , 43F
而是針對一些寫code中細節的邏輯部份,自己看自己寫的code都
08/18 01:54, 43F
→
08/18 01:55, , 44F
會有一些邏輯判斷的盲點,尤別人從另外的觀點來找出這些盲點.
08/18 01:55, 44F
→
08/18 01:56, , 45F
通常這些盲點,十之八九都是未來會發生bug的原因...
08/18 01:56, 45F
推
08/19 12:58, , 46F
照這樣說，我該高興了，十年來寫的 code 都讓我很驚豔
08/19 12:58, 46F
‣ 更多 yy938559 的文章
文章代碼(AID): #1EIhmmI2 (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 5 之 18 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共18篇)
‣ 更多 yy938559 的文章
文章代碼(AID): #1EIhmmI2 (Soft_Job)