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