作者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/cn.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