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

看板Soft_Job作者 (眠月)時間13年前 (2011/08/18 11:19), 編輯推噓20(20推 0噓 289→)
留言309則, 18人參與, 最新討論串10/18 (看更多)
※ 引述《yy938559 (高個子)》之銘言： 實在看不下去。 首先一間公司如果能作 code review 的人沒幾個，這種公司不待也罷。 因為 code review 並不難，如果一間公司沒幾人能作 code review， 那除非整間公司都是白痴。 程式碼的架構，絕對可以靠訓練達成， 短期有短期訓練，長期有長期的體驗， 《Solid Code》《Code Complete》《Code Craft》《Design Pattern》 都是可以在短時間裡面提昇程式碼品質的訓練， 我還沒見過哪一個人唸過這些東西以後程式碼品質沒有提昇的， 寫出來的東西就是漂亮、架構好、又容易 maintain， 除非你帶過的人都是白痴，因為我的同事都是有唸有吸收。 而這些東西除了可以靠自己唸， 也可以靠內部訓練的時候同事們彼此交流。 但是你說的沒錯，這些東西無法靠 code review 完成，為什麼？ 「因為 code review 根本不該看這些」 另外 god class, naming style 的問題，這也不是 code review 該做的， 都已經什麼年代了，這種東西用 tool 掃一次就好了， 沒通過的根本不用被 review 也不能 check in，打回去寫到對為止。 誰叫你 code review 去看架構跟 coding style 的？ 你弄錯 code review 的意義，然後說 code review 沒有用， 這很像你拿著 AK47 然後說 AK47 不能用來炒菜一樣。 講真的我無法跟你訴說 code review 有什麼好處， 就像你無法告訴一個沒體驗過高潮的人你射精的瞬間有多爽一樣。 這就罷了， 就算你真的在 code review 的時候檢討架構好了，也保證有用， 除非你的同事們根本沒有心想聽，那不管作什麼都沒用， 但是有很多人不是不想、不是不能，他們只是不知道可以這麼作。 code review 不看架構不看 style，看的是盲點跟一格洞， 程式設計師寫程式就會有盲點，就會有沒想到的東西， 有的東西，程度再強的程式設計師也無法自己修正， 因為所謂的盲點就是自己看不到的東西， 那行程式碼自己看一百次也看不出來有錯， 但是旁邊的新人一眼就知道錯了。 如果你真的如你所說寫了二十年的程式， 那你應該知道我在講啥。 code review 明明就是實務的東西， 你怎麼會以為他是學院派，實在令人很無言。 你看過哪個大學生寫作業的時候還在 code review 的嗎？ 如果真的寫了幾十年還覺得 code review 沒用， 只有兩種可能性，一種就是你超強，然後你的同事都是豬， 所以他們既無法 review 你的 code，也無法吸收你給他們的建議。 另外一種是公司根本不重視長期的軟體品質，所以東西怎麼寫都沒關係。 ※ 引述《yy938559 (高個子)》之銘言： : 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的人吧. : 唉...要被噓暴了. -- To iterate is human, to recurse, divine. 遞迴只應天上有, 凡人該當用迴圈. 　 L. Peter Deutsch -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.160.104.36
推
08/18 11:40, , 1F
好直接~~~給推~~~不是不想，不是不能，而是不知道呀~~~~
08/18 11:40, 1F
推
08/18 11:45, , 2F
吾心有戚戚焉
08/18 11:45, 2F
推
08/18 12:50, , 3F
"公司根本不重視長期的軟體品質"<<如此而已>> 電話接不完
08/18 12:50, 3F
推
08/18 13:43, , 4F
然後你會發覺白痴也是能賺很多錢的 XD
08/18 13:43, 4F
→
08/18 22:35, , 5F
不太同意唸完Design Pattern就能設計出好的架構~看過很多
08/18 22:35, 5F
→
08/18 22:36, , 6F
根本連領域的知識都沒搞懂就胡亂照著客戶的需求下去做~一
08/18 22:36, 6F
→
08/18 22:37, , 7F
開始可能很漂亮~但是到後來會發覺設計錯誤~重構的功更大..
08/18 22:37, 7F
→
08/18 22:39, , 8F
另外就算有工具可以檢查coding style~但永遠就是會有人鑽
08/18 22:39, 8F
→
08/18 22:40, , 9F
漏洞~check完很漂亮的過了~打開來一看卻會想罵髒話...
08/18 22:40, 9F
→
08/18 22:45, , 10F
當然你說得對,因為領域知識是正交的另外一軸
08/18 22:45, 10F
→
08/18 22:47, , 11F
而且這就是為什麼該有 code/design review
08/18 22:47, 11F
→
08/18 22:48, , 12F
你講的錯誤應該在 design review 的時候就被抓出來
08/18 22:48, 12F
→
08/18 22:48, , 13F
之前面試的某公司, 就會用好幾個月的時間 review design
08/18 22:48, 13F
→
08/18 22:51, , 14F
跟領域相關的設計，是在實做之前就已經決定好的
08/18 22:51, 14F
→
08/18 22:51, , 15F
這個階段跟 Design Pattern 無關, DP 是在實做的時候用的
08/18 22:51, 15F
→
08/18 22:52, , 16F
且,如果另外三本都唸過,還能寫出爛code,那也是天賦過人XD
08/18 22:52, 16F
推
08/18 22:58, , 17F
請問，Solid Code是指Writing Solid Code這本書嗎？
08/18 22:58, 17F
推
08/18 23:01, , 18F
請問大大推得這幾本書, 中文版推薦嗎?
08/18 23:01, 18F
→
08/18 23:10, , 19F
讀完書就會的話, 台灣絕對是全球天才最多的國度了,
08/18 23:10, 19F
→
08/18 23:11, , 20F
想看完哪幾本書就變高手, 真是想太多了
08/18 23:11, 20F
→
08/18 23:11, , 21F
台灣搞了三十年都沒搞出像樣的汽車engine, 哪些念電機
08/18 23:11, 21F
→
08/18 23:11, , 22F
機械的, 照這遍的邏輯全都是白痴就是了.
08/18 23:11, 22F
→
08/18 23:13, , 23F
差點忘了, 台灣最大的例子, 中信當初的彩券系統
08/18 23:13, 23F
→
08/18 23:13, , 24F
都有code review 哦, 結果呢? 不知的人去查新聞吧.
08/18 23:13, 24F
推
08/18 23:18, , 25F
不用變高手, 但起碼程度會提升吧
08/18 23:18, 25F
推
08/18 23:26, , 26F
通常不是沒人"能"code review 而是"沒人"可以review
08/18 23:26, 26F
→
08/18 23:26, , 27F
台灣公司嘛能省一個人力是一個 大家顧自己code都沒時間了
08/18 23:26, 27F
→
08/18 23:27, , 28F
目前為止看到的文章都告訴我 要嘛不要訂時程 要嘛RD訂
08/18 23:27, 28F
→
08/18 23:27, , 29F
結果台灣都是PM跟主管隨便挑個時間就訂了...
08/18 23:27, 29F
→
08/18 23:28, , 30F
那RD能怎麼辦，隨便寫寫會動就好啊~
08/18 23:28, 30F
→
08/18 23:47, , 31F
08/18 23:47, 31F
→
08/18 23:47, , 32F
Lordaeron 所以勒？然後勒？
08/18 23:47, 32F
→
08/19 00:47, , 33F
所以就是, 你講的話是屁話.design pattern呢
08/19 00:47, 33F
→
08/19 00:47, , 34F
writing solid code 還是microsoft 出品的呢.
08/19 00:47, 34F
→
08/19 00:48, , 35F
要提升哦, 套句哪位老兄的話, 你回頭看看你寫過的
08/19 00:48, 35F
→
08/19 00:49, , 36F
design pattern 的code 吧, 有沒有提升吧
08/19 00:49, 36F
→
08/19 00:49, , 37F
要看完XXX 就可以變高手, 哪麼絕對輪不到台灣人了
08/19 00:49, 37F
→
08/19 00:49, , 38F
書都是英文的呢.
08/19 00:49, 38F
→
08/19 00:50, , 39F
Code Review? 先想清楚, for What? 別將問題腦殘化,簡化
08/19 00:50, 39F
還有 230 則推文
→
08/20 09:10, , 270F
會列入考慮，在有生之年會想辦法生一篇詳細的介紹的。:P
08/20 09:10, 270F
→
08/20 09:12, , 271F
不過我覺得聰明人從我前面的描述應該就看得懂了。
08/20 09:12, 271F
→
08/20 09:13, , 272F
至於從前面還看不懂的，只好慢慢等詳細的介紹了。
08/20 09:13, 272F
→
08/20 09:14, , 273F
我並不喜歡因人廢言，但是我更不喜歡浪費時間。L你就別浪費
08/20 09:14, 273F
→
08/20 09:14, , 274F
你我時間了，你的質疑在我眼裡是雞蛋裡挑骨頭。:P
08/20 09:14, 274F
→
08/20 09:15, , 275F
我已經不想回你了，你高興就盡量推文說你的開心理念吧。
08/20 09:15, 275F
→
08/20 09:15, , 276F
至於code review的實例是會整理的，不過不是現在，這講起來
08/20 09:15, 276F
→
08/20 09:16, , 277F
需要做蠻多資料蒐集跟準備的，可不是幾句話帶過就可以了。:P
08/20 09:16, 277F
→
08/20 10:34, , 278F
是你沒待過很多公司, 而自以為code review 是每間必做
08/20 10:34, 278F
推
08/20 10:44, , 279F
不是為贊成而贊成, 而是看完正方反方以後, 覺得反方毫無立
08/20 10:44, 279F
→
08/20 10:45, , 280F
論根基, 只會拿特例來說嘴. 正方: Code Review 可以更快提
08/20 10:45, 280F
→
08/20 10:46, , 281F
升新人的程度; 反方: 哪有人看幾本書就變高手
08/20 10:46, 281F
→
08/20 10:46, , 282F
反方一直用這種牛頭不對馬嘴的方式振振有詞...讓我懷疑反
08/20 10:46, 282F
→
08/20 10:46, , 283F
方無法認同code review 說不定是本身邏輯程度不夠
08/20 10:46, 283F
→
08/20 11:17, , 284F
哈...特例? 中信一家就多少個案子在同時go 了,原來
08/20 11:17, 284F
→
08/20 11:18, , 285F
這叫特例哦, tonyQ一家公司, 一個產品, 原來叫通例
08/20 11:18, 285F
→
08/20 11:20, , 286F
另外, 我針對的是1. 正方說看完書就會code 漂亮,架構好
08/20 11:20, 286F
→
08/20 11:20, , 287F
維護好, 不知你這位自認邏輯好但看來閱讀力不好的有沒有
08/20 11:20, 287F
→
08/20 11:21, , 288F
看清楚呢? 再來, code review 可以快速(相對自己寫)新人
08/20 11:21, 288F
→
08/20 11:21, , 289F
的能力? 有沒有前題? 你要不要去sourceforge 抓套會計系
08/20 11:21, 289F
→
08/20 11:22, , 290F
統回來review 一下, 看你有沒有本事去了解會計的流程.
08/20 11:22, 290F
→
08/20 11:23, , 291F
有人review 只看coding style, 有人說要看架構, 有人說
08/20 11:23, 291F
→
08/20 11:23, , 292F
為debug, 更cool 的是可以提昇新人的水準. 請問你code
08/20 11:23, 292F
→
08/20 11:24, , 293F
review 是如何review? 丟給你code 加上spec 自己k?
08/20 11:24, 293F
→
08/20 11:24, , 294F
這樣子給新人學什麼?
08/20 11:24, 294F
→
08/20 11:24, , 295F
還是, 找個高手(看完書的也算)來review, tunning code?
08/20 11:24, 295F
→
08/20 11:24, , 296F
tunning style?
08/20 11:24, 296F
→
08/20 11:26, , 297F
有理解能力否? 是不是為讚成而讚成, 顯然易見.
08/20 11:26, 297F
推
08/20 14:34, , 298F
囧.. 他是說看完書品質會有提升,而不是看完書就會code 漂
08/20 14:34, 298F
→
08/20 14:35, , 299F
亮,架構好維護好吧.... Orz..
08/20 14:35, 299F
→
08/20 16:06, , 300F
好好好，我是為贊成而贊成，醬你高興了吧。XD
08/20 16:06, 300F
→
08/20 16:11, , 301F
你說什麼都對，不過拜託不要再浪費時間了。XD
08/20 16:11, 301F
→
08/20 23:41, , 302F
聊起來了吶..
08/20 23:41, 302F
→
08/20 23:42, , 303F
想做的人,會找到一個方法;不想做的,會找到一個藉口
08/20 23:42, 303F
→
08/22 09:23, , 304F
哇, 文字就寫在上了, 能拗的呢.
08/22 09:23, 304F
→
08/22 09:24, , 305F
咦,tonyQ 你對號入座了? 幾號呢? 你講的方法我有反對?
08/22 09:24, 305F
→
08/22 09:26, , 306F
講得好, 想做的人,會找到一個方法;-->換老闆囉
08/22 09:26, 306F
推
08/22 14:27, , 307F
再回去看那三行,的確如 L 大所說.. 那一段的確跳有點快
08/22 14:27, 307F
→
08/22 14:29, , 308F
不過看yoco大的系列文的文意說的確是屬於漸進式的提升
08/22 14:29, 308F
→
08/22 14:29, , 309F
總之就別鑽牛角尖了吧!!
08/22 14:29, 309F
‣ 更多 yoco315 的文章
文章代碼(AID): #1EJ8JCY8 (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 10 之 18 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共18篇)
‣ 更多 yoco315 的文章
文章代碼(AID): #1EJ8JCY8 (Soft_Job)