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

看板Soft_Job作者 (dk)時間12年前 (2011/08/20 09:28), 編輯推噓4(4020)
留言24則, 9人參與, 最新討論串16/18 (看更多)
前文恕刪 我覺得 code review 是有用處的, 首先是人難免會寫些蠢 code, 例如 if (a == b) return true; else return false; 或者 if (b) { // just do nothing } else { do something... } 蠢不蠢? 實在真的有夠蠢, 蠢到我講給別人聽自己都會笑個不停, 但是沒辦法, 有時一段 code 修來改去就是會變這樣, 我也沒辦法確保自己未來不會再寫出這類 code, 因為當下真的很難意識得到 也不一定只有強的能 review 比較不強的, 前不久我就看到一段多餘邏輯, 寫的人是二三十年老經驗, 我也認為他很強, 但還是發生了, 大概像底下 if (b) { if (a) do something } if (!b) { if (a) do something } 這不是強弱問題, 不是經驗多少問題, 只是智者千慮必有一失, 廢材腦袋空空做白日夢還是會偶有一得, 不考慮上面的部份, 另一個角度來說這也關係到壓力及生產力, 這部份就需要一個高手來 review 底下菜鳥, 假若流程是寫完 code 直接上線跑測試的話, 那對菜鳥來說壓力其實是大的, 因為沒有人把關, 要全靠自己, 反應下去就是效率會是低的, 因為菜鳥要花數十到上百倍的時間, 才有辦法寫出跟高手一樣水準的東西, 假若流程是寫完 code 後會經由高手 code review 再修改過, 對菜鳥來說他可以放心大膽的寫一個比較粗糙的原型, 再由高手花一點點時間將它精緻, 菜鳥也順便學習, 對高手來說, 可以省去做原型中苦工的部份, 只做最後精緻及調整的部份, 也能順便接收一些菜鳥花功夫整理過的資料, 這邊有個前提是要有一定的規範及標準, 菜鳥寫也不是隨便亂寫, 仍然要符合一定的架構原則及風格, 高手來看才不會反而更費功夫, 工作內容也應該訂清楚, 把苦工做到哪裡, 什麼情況該反應等等 這其實是對菜鳥和高手都有好處, 菜鳥可以吸收一些高手的歷練, 高手可以省去一些不太花腦但是耗時費工的苦工, 當然菜鳥不可能立刻能提昇多少, 但即使每次只有一點點小進步, 累積一兩年後也是很可觀的 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.224.46.251

08/20 09:43, , 1F
if (b) do nothing else do something 不好嗎?
08/20 09:43, 1F

08/20 09:44, , 2F
它是說那可以直接寫成 if(!b){ /* do something */ } 吧
08/20 09:44, 2F

08/20 09:44, , 3F
不過我最近看到的範例是
08/20 09:44, 3F

08/20 09:45, , 4F
String token = "hi" ; if("token".equals("hi")){ /*..*/ }
08/20 09:45, 4F

08/20 09:45, , 5F
爬commit log時候看到的,第一眼只覺得怪怪的但說不出哪怪XD
08/20 09:45, 5F

08/20 09:45, , 6F
也許他一開始是想把狀況先列出來?
08/20 09:45, 6F

08/20 09:58, , 7F
這樣的code只是style跟你不同, 沒甚麼不好
08/20 09:58, 7F

08/20 09:59, , 8F
return (a>b) ? a:b; 這種code對大師級的人來說,才像話
08/20 09:59, 8F

08/20 09:59, , 9F
的確是,原文的條件判斷這其實可以歸類到coding style去。
08/20 09:59, 9F

08/20 10:00, , 10F
像一般工程師通常比較重debug,trace
08/20 10:00, 10F

08/20 10:00, , 11F
三元運算子有個兩層 (a > b ) ? (c > d ) ? k1 : k2 :k3 ;
08/20 10:00, 11F

08/20 10:00, , 12F
看到就笑不出來了 XD
08/20 10:00, 12F

08/20 10:01, , 13F
if(condtion) return a; else return b;
08/20 10:01, 13F

08/20 10:01, , 14F
@phire 答案同2樓 @Phoenix 前兩段是我自己寫的 自己都覺
08/20 10:01, 14F

08/20 10:02, , 15F
得蠢 有沒有不好則是看語言及環境而定 Time/Space 限制嚴
08/20 10:02, 15F

08/20 10:03, , 16F
格的話就不太好
08/20 10:03, 16F

08/20 10:04, , 17F
if(a){} if(b){} if(c){} if(d){} if(e) {/*do s.t.*/}
08/20 10:04, 17F

08/20 10:05, , 18F
這是蠢度放大版 XD
08/20 10:05, 18F

08/20 10:10, , 19F
XD ...
08/20 10:10, 19F

08/20 10:25, , 20F
De morgan's law 很有用,當你需要卡諾圖時就是寫爛了
08/20 10:25, 20F

08/21 12:15, , 21F
我覺得多層三元把判斷式放在false比較好閱讀
08/21 12:15, 21F

08/21 12:19, , 22F
(a<=b)?k3:(c>d)?k1:k2
08/21 12:19, 22F

08/23 00:05, , 23F
別太急著說蠢 有時候我也會把可以精簡的判斷邏輯放大
08/23 00:05, 23F

08/23 00:07, , 24F
因為我自己預知會在某處需要補code 這樣寫方便快速認出
08/23 00:07, 24F
文章代碼(AID): #1EJmsavp (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文
完整討論串 (本文為第 16 之 18 篇):
文章代碼(AID): #1EJmsavp (Soft_Job)