噓 final01: 溝通也是code review中的一環.... 05/15 20:42
→ pttworld: code review是leader把你之前解的bug抓出來，你的解法 05/15 20:53
→ pttworld: 可行，但是否為最佳解。 05/15 20:53
推 chiwa: 這就靠溝通了，並不是用了design pattern就一定是好的作法 05/15 21:46
推 sunsamy: 程度差的才會在那code review，跟人腦compiler有什麼差別 05/15 22:10
→ sunsamy: 直接TDD(software是醬講的)或testpattern(IC設計)往介面 05/15 22:12
→ sunsamy: 一打，加上formal verification跟Lint軟體就好了，什麼年 05/15 22:13
→ sunsamy: 代了還在人腦compiler 05/15 22:13
→ sunsamy: 覺得軟體這行越來越多稀奇古怪但不實用的名詞，都是炒作 05/15 22:15
→ sunsamy: 起來的，像code review, scrum, CI, CD, git flow, UML, 05/15 22:16
→ sunsamy: DevOps...等。資工這行最會炒作一些沒用且趕流行的東西了 05/15 22:18
→ sunsamy: 像敏捷文化, 沒人精確地講得出它是什麼, 工程的人也會弄 05/15 22:20
→ sunsamy: 這些不精確的東西 05/15 22:21
推 sunsamy: 跟文化部有什麼不同, 欣賞就好 05/15 22:27
推 e2755699: TDD不也依樣 0.0 05/15 22:29
→ angusyu: 五樓自表了，雖然有些講得沒錯 05/15 22:30
→ vn509942: 政治問題 05/15 22:32
→ angusyu: 給雞巴人review只是他在釋放壓力而已。說你格式錯，命名 05/15 22:37
→ angusyu: 錯，檔案放錯地方，能用簡單的做法叫你改成企業級架構 05/15 22:37
推 hidog: 以職場來講,守舊並沒有什麼不好. 05/15 22:55
→ hidog: 引入新工具,卻出包,未必是好事. 05/15 22:56
→ hidog: 我會覺得這是你跟這個主管不合,並不是誰的錯 05/15 22:57
推 fun4i0220: 我是覺得說服主管用一個新框架也是一種能力啦 05/15 23:04
→ pttworld: 敏捷開發會議，每天開始上班前集合圍成圈各自說明今天 05/15 23:06
→ pttworld: 準備進行的項目。 05/15 23:06
推 vn509942: 要推新玩具 要以他的立場 去闡述對他有什麼"好處" 05/15 23:06
推 mdkn35: Agile就是....壓榨工程師的精神 05/15 23:18
→ lazarus1121: 我也不喜歡code-riview，有時候效能跟維護便利性會 05/15 23:21
→ lazarus1121: 相衝 05/15 23:21
推 jlhc: agile沒記錯的話本意是讓開發可以快速遞代產品功能的修正 05/15 23:21
→ jlhc: 到台灣目前跑起來基本上就是把瀑布式的時間壓縮成agile區間 05/15 23:22
→ lazarus1121: 自己寫了一些能加速開發的小工具，但是卻被要求把沒 05/15 23:23
→ lazarus1121: 用到的判斷式拿掉 05/15 23:23
推 johnny4753: 呵呵，這篇讓我想到資深同事一句話:直接switch case 05/15 23:30
→ johnny4753: 不是很清楚嗎？用什麼抵賽配疼，結果在他commit過的co 05/15 23:30
→ johnny4753: de看到上千行的switch case 05/15 23:30
推 james732: 良性的code review可以經由討論讓程式碼更好吧？ 05/15 23:32
→ james732: 很多open source專案都用gerrit之類的系統在做review 05/15 23:33
→ james732: 但如果負責review的人不願意溝通覺得自己最棒就會很糟 05/15 23:34
推 chuegou: 上千行的swich case我也寫過 應該有5000行左右吧 很屎 05/15 23:36
推 sunsamy: 上千行的swich case沒什麼吧?這都是看需求,要不然你叫IC 05/15 23:41
→ sunsamy: 設計人員怎麼辦,為了要可以合成實際電路,上千行的switch 05/15 23:41
→ sunsamy: 很多,不可能用類似PolicyBasedDesign這樣來合成,因為太抽 05/15 23:42
→ sunsamy: 像了,無法合成. 你也可以想成上千行的switch case是可以 05/15 23:42
→ sunsamy: mapping到實際電路的design pattern 05/15 23:42
推 anon: 要看review的人有沒有腦吧，被合理的質疑為什麼要這樣寫很容 05/15 23:45
→ anon: 易就會發現自己的盲點 05/15 23:45
推 NCUking: code review 只適用於公司成員都有一定水準啦 05/15 23:53
→ NCUking: 矽谷大聯盟用起來當然好棒棒 鬼島草創聯盟就... 05/15 23:54
→ johnny4753: 就只是心情不好拿code來狗幹你而已 05/15 23:59
→ y3k: 我認為Code Review的成員單位很重要 有些人就算讓他進去報告 05/16 00:09
→ y3k: 也不知道要幹嘛 這種就讓他在外面等結果就好 05/16 00:10
推 james732: 各位公司的code review是什麼形式的啊？ 05/16 00:16
→ james732: 我們是上傳到自架的gerrit然後主管看完沒問題merge有問 05/16 00:17
→ james732: 題問一問修改再amend 05/16 00:17
→ y3k: 阿 上面打錯 是Scrum 05/16 00:21
推 sunsamy: 若一個團隊有好幾個強者,你去review他的code,那多半是 05/16 00:25
→ sunsamy: 幹架形式,若只有主管是可以review人的,但其它人也不會 05/16 00:25
→ sunsamy: 發聲,那代表這個團隊很弱,基本上也是及及可危 05/16 00:26
→ sunsamy: 結論：程度差的才會在那code review 05/16 00:26
推 Masakiad: review都是一個資深搭一個資淺，資深當reviwer可以提升 05/16 00:29
→ Masakiad: 資淺的code, 反之資淺可以一窺資深設計的奧秘。一個主 05/16 00:29
→ Masakiad: 管review的不如直接主管開架構寫完就好，也不用管提升 05/16 00:29
→ Masakiad: 整體團隊能力 05/16 00:29
推 vi000246: 上千行的switch弄成design pattern大概要上萬行了 05/16 00:55
推 hizuki: Google都有code review還出了gerrit 05/16 01:36
推 steve1012: Google 程度一定很差 才會code review 05/16 02:37
推 sunsamy: 這是有可能的,千萬不要有大公司的人就是強的迷思 05/16 08:17
推 sunsamy: 刷leedcode進去但不懂架構的人大有人在,我也看過facebook 05/16 08:18
→ sunsamy: 內部不公開的code,寫得跟狗啃,連排版都不排的的也是一堆 05/16 08:20
→ sunsamy: 會刷leedcode或供獻opensource有時只是為了考上或打知名 05/16 08:21
→ sunsamy: 廣告,看看linux內部的東西是什麼鬼命名：/dev = device 05/16 08:22
→ sunsamy: 有這樣命名程度,但貢獻opensource的人,算強者嗎？再舉一 05/16 08:24
→ sunsamy: 個command的命名：ls = list, linux太多這樣的東西了 05/16 08:25
推 Masakiad: 程度差的公司跟code review根本沒關係，程度差的公司就 05/16 08:27
→ Masakiad: 是人程度差，code review是提升團隊實力的工具，程度好 05/16 08:27
→ Masakiad: 與壞的團隊都需要，不要搞錯重點了 05/16 08:27
推 ripple0129: 我覺得命名的事是這幾年大家軟工觀念有起來才重視，過 05/16 08:55
→ ripple0129: 去都靠comment呀，也不能怪20年前的工程師 05/16 08:55
推 mdkn35: /etc = 設定檔 幹 etc不是其他嗎? 05/16 10:24
推 mathrew: 樓上 XD 05/16 10:39
推 codehard: 非英語系大學生寫的單字量少正常 英文這麼厲害就去教英 05/16 10:45
→ codehard: 文了誰要做碼農 05/16 10:45
推 TllDA: 推dmkn35 XDDD 05/16 10:56
→ adks3489: etc在unix最初期就是代表其他的意思阿 05/16 11:06
推 lovdkkkk: 推 mdkn35: /etc = 設定檔 幹 etc不是其他嗎? XD 05/16 11:36
推 doomleika: *nix command那些我覺得不算理由，會保留這些是因為 05/16 11:39
→ doomleika: 相容，很多script/code都寫死 05/16 11:39
推 Argos: 理想跟現實總是有差距的 但不代表追求理想不好啦 XD 05/16 11:44
→ Argos: 像code review 其實一開始用這個詞就錯了 感覺好像老師在改 05/16 11:46
→ Argos: 考卷 變成資深靠北資淺的一種形式 那你把詞換一下 變成 05/16 11:46
→ Argos: code discuss 就資深跟資淺的「一起討論」 不就好了嘛 XDDD 05/16 11:47
→ doomleika: 我自己是站在code review這方的，要求所有人停下來 05/16 11:47
→ doomleika: 看看過去的code研究怎麼修正問題對整體對code的了解 05/16 11:47
→ Argos: 工程師之間互相討論code每天都在做阿 嚴格說來也是review 05/16 11:48
→ doomleika: 跟程式的健康有正面意義 05/16 11:48
→ Argos: 重點就在用review這詞 打擊到工程師的自尊 XDDD 05/16 11:48
→ Argos: 其它東西都是公司團隊制度管理需要 也不是什麼華而不實的理 05/16 11:55
→ Argos: 論吧？重點還是看你需求 公司如果幾個人 那其實都可以不必 05/16 11:55
→ Argos: 但團隊數十人 沒制度就開始亂了 客戶如果又常亂改需求又更 05/16 11:56
→ Argos: 添亂 他們想出一堆方式就是試著去整理這一團亂的狀況而已啦 05/16 11:57
推 steve1012: Review就能傷到自尊...這 05/16 11:58
→ Argos: 命名也是為了好管理阿 或後面接手好理解而已 不然也沒差齁 05/16 11:58
→ Argos: 應該這樣說 某些人review的方式會傷人自尊 XDDDD 05/16 11:59
推 james732: 我上code給google看被打槍的時確實是有點受傷QQ 05/16 12:03
噓 kenwufederer: Code review是為了確保公司產品品質 05/16 12:19
推 Ekmund: 呃...code review不是事後補救工作 應該是事前 05/16 12:38
→ Ekmund: 而且也不是TDD可以取代的 那只能保證輸入輸出 05/16 12:39
→ Ekmund: 架構延展性 效能 潛在的side effect 還有慣性等等 05/16 12:40
→ Ekmund: 尤其是慣性 在大一點的東西裡 裡頭看起來是"一致的" 05/16 12:41
→ Ekmund: 其實蠻重要的 而這些需要對文化瞭解的經驗磨 05/16 12:42
→ zenixls2: 不review就不要有人一個檔案塞了幾萬行code結果最後沒 05/16 12:45
→ zenixls2: editor開的起來了... 05/16 12:45
推 james732: 另外就是發生bug的時候可以把reviewer拖下水(喂 05/16 12:45
→ james732: 那個●●●幫我看過也沒發現這個問題啊(無辜貌) 05/16 12:46
→ zenixls2: 另外上千行的switch case我覺得不如用gen的... 05/16 12:49
→ bcew: 上千行的switch...沒tool沒辦法eco吧，應該改架構的 05/16 13:03
推 hegemon: 只會無腦套design pattern的還是不要寫code咖厚，盡信書 05/16 13:22
→ hegemon: 不如無書 05/16 13:22
→ Ekmund: 千行switch...我會用enum tag+function pointer arr切吧 05/16 17:32
推 KeySabre: code review說成人體compiler 肯定是誤會了什麼 05/16 18:30
→ KeySabre: 團隊合作不順 個體再強都是在彼此消耗跟浪費 05/16 18:32
→ KeySabre: 主管該給予部屬自主性 排除團隊的阻礙 不要變控制狂 05/16 18:34
→ KeySabre: 但說到導入一個團隊目前沒在用的新框架或技術什麼的 要 05/16 18:36
→ KeySabre: 考量團隊是否能在後續的開發及維護上得利 05/16 18:36
→ KeySabre: 如果是設計上想法不同 想辦法說服團隊囉 05/16 18:38
推 Yshuan: 這是人的問題 結果好不好 除了方法之外 執行者爛也沒救 05/16 20:57
→ manaup: google的intern是小不拉嘰公司CTO的兩倍薪不止 05/16 21:34
→ manaup: google的code review也一定跟大家的code review不一樣的 05/16 21:35
→ Argos: 我倒覺得無腦套DP總比土炮自己亂七八糟的奇怪架構好... 05/16 23:27
推 FrozenMoment: 上千行 switch case 不一定是問題吧，好幾個類似的 05/17 07:26
→ FrozenMoment: switch case 上千行才是問題吧 05/17 07:26
→ jefflu: code review本來就要有吧... 你們到底是待過哪些爛公司得 05/17 08:17
→ jefflu: 到這樣的建議跟結論... 05/17 08:17
推 jefflu: compile 跟 fully covered test cases根本就是一定要也是 05/17 08:21
→ jefflu: 最基本的， 之後的code review再根據這個新的code跟原本 05/17 08:21
→ jefflu: 的架構來看是不是有可以改寫得更好的地方 或是說有沒被tes 05/17 08:21
→ jefflu: t case抓到的問題 05/17 08:21
→ a47135: 可能被電很慘有心靈創傷吧 05/17 12:21
推 sunsamy: jefflu講得很好，可惜不是最佳解。合格的Architect必需要 05/17 13:43
→ sunsamy: 能在介面的地方定好power、速度、gate count、test case 05/17 13:43
→ sunsamy: 、scenario的SPEC。之後讓engineer去發揮，若engineer做 05/17 13:43
→ sunsamy: 不到才來code review討論為何做不到？大概有兩個原因 05/17 13:43
→ sunsamy: 1.engineer程度差不能fit規格 2.Architect程度差訂錯規格 05/17 13:43
→ sunsamy: 結論：程度差的才會在那code review 05/17 13:44
→ sunsamy: X至於沒被test case抓而的問題本來就不在應用場景內會被 05/17 13:44
→ sunsamy: trigger到，會被應用scenario用到的就必需在test case內 05/17 13:44
→ sunsamy: 那就是2. Architect程度差訂錯規格。 05/17 13:44
→ sunsamy: 結論都是：程度差的才會在那code review 05/17 13:44
推 hidog: code review跟程度差不差沒關係吧,只是管理方式而已...= = 05/17 14:57
→ robber1234: review不外乎一行一行解釋,或是上系統給別人看一遍 05/17 15:32
→ robber1234: 就是有機八人根本不是做我這塊卻要叫我一行一行解釋 05/17 15:32
→ robber1234: 所以結論確實是太機八的人你就不要想review別人扣 05/17 15:33
→ Masakiad: 一個code review 被解釋成這樣 哥也是醉了 05/17 18:44
推 Masakiad: code review本身就可以當成是spec內的一個活動，找的問 05/17 18:46
→ Masakiad: 題跟spec根本也不同面向 05/17 18:46
推 ak2840: code review的目的不就是要打那些自以為寫得很好的人臉嗎 05/17 20:41
推 NCUking: 跟程度怎麼沒關係?有些公司官大學問大，審核的人程度爛 05/17 20:47
→ NCUking: 浪費寫程式的人許多時間「教」他基本語法 05/17 20:47
→ NCUking: 同意code review本身是好的，但遇到不對的人就.... 05/17 20:49
推 NCUking: 那些批評的人多半是遇到白癡亂搞才認為他是不好的制度 05/17 20:55
推 chiwa: 人與人之間的關係和溝通方式決定code review帶給你的印象 05/17 21:13
→ chiwa: 我一直非常喜歡我現在公司的code review的感覺，大家非常 05/17 21:13
→ chiwa: 熱衷於討論，而不是在貶低別人或是覺得別人找自己麻煩 05/17 21:13
→ chiwa: 因為大家關係好，也清楚知道團隊的目標與核心價值是什麼 05/17 21:14
→ chiwa: 這樣的code review對我來說就是很積極正面的 05/17 21:15
推 largeluluser: 感覺chiwa 大大的團隊氣氛不錯 05/17 21:33
→ Argos: 程度差的才review XD 原來國外一堆大神程度都爛到爆 長見識 05/17 23:47
推 jefflu: sunsamy 可能有點太偏激了 雖然我大概懂你想說什麼 但是一 05/18 01:07
→ jefflu: 間公司那麼多人 一個ticket指派下去 我可能會就實作的方向 05/18 01:07
→ jefflu: 跟別人討論一下 然後我們有共識 但是幾天後他的PR可能實作 05/18 01:07
→ jefflu: 細節完全有很大的改進空間 這時候code review就發揮作用了 05/18 01:07
→ jefflu: 不是嗎？ 對方或自己也能在每次討論的過程中學到些東西。 05/18 01:07
→ jefflu: 你總不能說 我們只hire最強的人或寫得爛是程度差 所以就 05/18 01:07
→ jefflu: 算了... code review就是一套機制來解決這個問題的 否則 05/18 01:07
→ jefflu: 公司那麽大 人那麽多 偏激的作法在好的公司不會是一個可以 05/18 01:07
→ jefflu: 接受的解決方案的 05/18 01:07
推 KeySabre: review只是一種方法 做好或做壞是人的問題 05/18 23:37
→ KeySabre: 解釋成人肉compiler就是沒弄清怎麼把review變成能做好的 05/18 23:39
→ KeySabre: 方法 05/18 23:39