作者purin88 (原来我是愤怒的乡民)
看板Soft_Job
标题[讨论] 主管不认同书本的知识，说我没学好程设
时间Sat May 7 20:18:49 2016
code review时，主管说暂存变数可省记忆体，不用一直建立变数占记忆体，我就说＂重
构＂这本书作
者建议别这样做，我就拿下面这个＂重构＂作者的网址
https://sourcemaking.com/refactoring/split-temporary-variable
他就说这个作者有问题，说我跟他写一样出去别人
会笑我
接着，我程式有用简单工厂模式，就像head first design patten的内容一样建立pizza
店的工厂，他又
说为什麽要建立抽象的pizza店，建立A pizza加盟店，B pizza加盟店，我说每间pizza店
产生pizza囗味，方法不同，他又说建立A pizza店，B pizza店
产生物件浪费记忆体，为何不用switch case判定
是A或B，直接写各店pizza的作法及口味，产生pizza的作法何必封
装在A pizza物件，或B物件中，全写在pizza这个程式中，写一个类别静态方法回传pizza
一样的，他没看过design patten，也觉得四人帮在乱写一通，建立物件是浪费记忆体
https://rongli.gitbooks.io/design-pattern/content/chapter1.html
https://dotblogs.com.tw/joysdw12/archive/2013/06/23/design-pattern-simple-fact
ory-pattern.aspx
然後谈到建立物件，我是用set get的方式设置参数，他就觉得为什麽不用建构子把好几
个参数丢进去，我一样拿出
https://sourcemaking.com/refactoring/smells/long-parameter-list
http://teddy-chen-tw.blogspot.tw/2014/04/3long-parameter-list-divergent-change
.html?m=1
重构的作者是建议参数不用丢太多，建立一个物件，
设定物件的值，把物件丢进建构子，或方法参数中，然後我这样跟我主管说，他又说我没
脑袋吗
没办法判定这个作者有问题
参数本来就全丢给建构子，让建构子去塞，即便
参数很多也没关系，说我物件导向没学好
反正一直在对我人身攻击，即使我提到重构
设计模式，对他来说就是烂书，作者乱写
请问我该如何是好？
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.241.90.24
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1462623535.A.DC8.html
※ 编辑: purin88 (111.241.90.24), 05/07/2016 20:24:21
1F：推 Clangpp: 换部门?? XD 05/07 20:24
2F：→ testPtt: 注重记忆体有他的写法 一般DP重点在好懂好改 05/07 20:25
3F：推 Clangpp: 四人帮是乱写一通?? 科科 05/07 20:26
4F：推 mithuang: 又要Code Review又不接受新知识的主管真另人头疼 05/07 20:27
5F：推 chuegou: code维护的频率高吗？还是写完之後几乎不会动？ 05/07 20:28
6F：推 leicheong: 有很多程设习惯并不适用於硬体资源受限如embedded 05/07 20:28
7F：→ mithuang: 现在PC都强到不行,为了那一滴滴滴效能牺牲维护性,划不来 05/07 20:28
8F：→ leicheong: 的情况? 05/07 20:29
9F：推 Sirctal: 很难说主管是对是错... 要看立足点 只是如同 mithuang大 05/07 20:30
10F：→ YSimpson: 把程式贴出来才知道问题在哪里 05/07 20:30
11F：→ Sirctal: 说的 为了一点效能牺牲维护性... 05/07 20:30
12F：推 BignoZe: 要看看你要解决什麽问题才看看要不要用设计模式 过度设计 05/07 20:32
13F：→ vi000246: 这种时候就听主管的 出事他负责 05/07 20:33
14F：推 leicheong: 好像以前盛行了十数年的Frame Pointer Omission现在也 05/07 20:33
15F：→ BignoZe: 造成的成本可能比缺乏设计还要高 看你们要追求的是开发速 05/07 20:34
16F：→ leicheong: 为了方便除错时做stack trace而预设关闭了. 05/07 20:34
17F：→ BignoZe: 度还是效能 才能决定用哪种作法 05/07 20:34
18F：→ Newtype: 自己的作品这样写就好了 上班就不要跟主管争了 05/07 20:34
19F：→ BignoZe: 主管也是个不好学的人 设计模式和重构算是基本的东西了 05/07 20:35
20F：→ BignoZe: 不过你也不必看了什麽书就觉得那本书的方法好棒棒一定要 05/07 20:36
21F：→ BignoZe: 用 学东西是为了面对未来的挑战而学的 有一天你公司的东 05/07 20:37
22F：→ BignoZe: 西需要好的架构 这些设计模式就会派上用场了 05/07 20:37
23F：推 NCUking: 你的主管可能是以前是搞韧体之类的 05/07 20:38
24F：推 biboSnake: 你不是在工作吗？他是你主管 你还想说什 05/07 20:38
25F：→ biboSnake: 麽 05/07 20:38
26F：推 Hikkiaholic: 作者对你的影响力 没有主管的万分之一 05/07 20:38
27F：→ Hikkiaholic: 对你而言 主管比贾伯斯比尔盖兹耶稣上帝天王老子 更 05/07 20:40
28F：→ purin88: 唉，我就只是难过被人身攻击 05/07 20:40
29F：→ Hikkiaholic: 大 主管怎做就怎做 好坏不重要 05/07 20:40
30F：→ Hikkiaholic: 违背他 做烂就算 做好他更气 表示你比他厉害 05/07 20:41
31F：推 Deltaguita: 以他说的为主，不然就是分析优劣给他看 05/07 20:42
32F：推 biboSnake: 推楼上 05/07 20:43
33F：推 Ekmund: 什麽都塞建构 就祈祷这物件不会被当样板大量衍生 05/07 21:01
34F：→ sayya2311: 你要的是这公司的$还是自己的竞争力,2选1 05/07 21:03
35F：推 littlebau: 照他说的写。比较好的方法本来就万百种。不是吗？ 05/07 21:03
36F：→ Ekmund: 等着见识超肥大档案载着几十种规则诞生 05/07 21:03
37F：推 CRPKT: 换公司 05/07 21:04
38F：推 Yshuan: 换吧 反正台湾写程式钱都差不多少 05/07 21:06
39F：推 sing10407: 沟通有问题，说服不应该一直丢书丢连结；再者主管坚持 05/07 21:10
40F：→ sing10407: 应该就直接用主管的方法，毕竟出事是主管直接被定 05/07 21:10
41F：推 iamshiao: 真的是出来混才知道守旧又自负的人比想像中多很多，人家 05/07 21:15
42F：→ iamshiao: 一句以前都这样做还不是好好的，你只能摸摸鼻子，毕竟 05/07 21:15
43F：→ iamshiao: 那也是事实，不行就换工作吧 05/07 21:15
44F：推 giantwinter: 离职 05/07 21:16
45F：→ james732: 不过像用在嵌入式系统的程式似乎确实要斤斤计较？ 05/07 21:19
46F：→ james732: 我觉得要看原PO的使用情境？ 05/07 21:19
47F：→ james732: 以效能与memory来说，应该可以分析产生数据来说明？ 05/07 21:20
48F：推 ticks: 拿compiler课本，翻到dataflow analysis和SSA的章节呛他 05/07 21:23
49F：推 popcorny: 单方说词..建议请你主管出来辩论 (先等我买鸡排..) 05/07 21:32
50F：推 longlongint: 那就 跟他说好然後 改code给他看 05/07 21:32
51F：→ longlongint: 然後编译自己的code 05/07 21:32
52F：推 coronach: 你的主管很明显是早期写C出身的人，但是现在新的compile 05/07 22:08
53F：→ coronach: r很强，就算embedded 都不一定要那麽麻烦了... 05/07 22:08
54F：→ fridayjason: 时代不同 以前系统规格差的时後 只能省则省硬干 05/07 22:14
55F：→ fridayjason: code写得丑难维护 换个角度其实是让自己不易被取代 05/07 22:15
56F：推 ns1234: 录音 换公司? 05/07 22:16
57F：推 comesuck: 他不明白stack heap gc的运作吧 05/07 22:34
58F：推 comesuck: function传入值十几个还不宣告class包起来真的很有事 05/07 22:37
59F：→ tsairay: 文人相轻 05/07 22:37
60F：推 steven11329: 切入的角度不同吧…我觉得没有对错 05/07 22:50
61F：→ steven11329: 而且尽信书不如无书，书上说的不一定都要遵循啊！ 05/07 22:52
62F：推 zelda123: 从叙述来看我看不出有哪里人身攻击 05/07 23:06
63F：→ ah7675: 这是典型刚出社会的人的毛病，丢网址给别人看更是蠢 05/07 23:48
64F：→ ah7675: 对解决问题一点帮助也没有 而且只想着对与错 也不考虑 05/07 23:49
65F：→ ah7675: 背景、场合 什麽平台 开发周期长短及产品导向也不清楚 05/07 23:51
66F：→ ah7675: 只因为自己学了认为对的东西就战无不胜 这个主管可能很烂 05/07 23:52
67F：推 ADYex: 你需要看Clean Code的番外篇 专业程式设 05/07 23:53
68F：→ ADYex: 计师的自处之道 05/07 23:53
69F：→ ah7675: 但你用的方式就算证明你是对的又如何？ 05/07 23:53
70F：推 ADYex: 不过我想你还是快逃吧 05/07 23:57
71F：→ ripple0129: 虽然觉得是看案例，不过看文章推测该主管没提出原因， 05/08 00:19
72F：→ ripple0129: 单纯说DP作者在乱写就知道素质了 05/08 00:19
73F：推 realbout: 其实和学校教授一样，用嘴写的一手好程式 05/08 00:27
74F：→ poloball: 我觉得直接丢书本或丢网址有点强迫逼人接受的感觉 05/08 00:29
75F：推 justben: 找些软体 实测啊 用数据说话 05/08 00:30
76F：→ poloball: 自己活用书中知识 以你们的案例为例解释可能较好 05/08 00:30
77F：→ justben: 不过 review 不是为了这个吧 又不是要写书 05/08 00:30
78F：→ poloball: 直接丢个书名或网址 好像网路上在笔战 05/08 00:31
79F：→ realbout: 就像房子乱盖也是挺快的 05/08 00:32
80F：→ carbopon: 你能说出这个case，为什麽用这写法比较好吗? 05/08 01:59
81F：推 WolfLord: 软体猪就是种种主张弄出来的，然後一堆自以为管理很优 05/08 02:06
82F：→ WolfLord: 的笨蛋交出更多笨蛋，以光速抵销摩尔定律的进步。让计算 05/08 02:07
83F：→ WolfLord: 机性能永远不够快...想想8088跑DOS的算PI速度为什麽 05/08 02:08
84F：→ WolfLord: 比WINDOWS+i7+32GRAM还快? 05/08 02:09
85F：推 Gaogaigar: 说不定你拿去实测後，你的code会比较快 05/08 02:29
86F：→ Gaogaigar: 不过从你这文没解释清楚来看，你沟通上对 05/08 02:31
87F：→ Gaogaigar: 主管制造的困扰可以不少 05/08 02:31
88F：推 jl40: 程式员相轻? 05/08 03:25
89F：推 valen720918: 要说出为什麽要这样写，不是一昧说某大神怎麽都怎麽 05/08 08:44
90F：→ valen720918: 写 05/08 08:44
91F：→ valen720918: 何况，2个方案都可以 work ，要说明挑哪一个优劣 05/08 08:46
92F：→ yourinfo: 主管让你怎麽写就怎麽写，只要没有什麽後遣症就好 05/08 09:30
93F：→ yourinfo: 等swtich case不好维护时再来重构，到时不是更好说明 05/08 09:34
94F：→ yourinfo: 变数怎用，参数怎传，就都不是那麽重要，习惯问题罢了 05/08 09:34
95F：→ wens: 说起来这个 case 其实编译器可能会最佳化掉 05/08 10:15
96F：→ siriusu: 同valen的意见 05/08 10:23
98F：→ liddle: 你的举例太空泛，很难判断。DP是累积归纳出的解题结构。专 05/08 11:11
99F：→ liddle: 对付OO会遇上的问题。 05/08 11:11
100F：推 tsairay: 有时候某些写法,是程式架构大才有利,程式架构小反而会 05/08 12:23
101F：→ tsairay: 显得累赘 05/08 12:24
102F：推 tsairay: 像是switch case如果只有三个,而且也不会再增加,你就 05/08 12:40
103F：→ tsairay: 没必要写得那麽"厚工",除非case的数目会一直膨胀,你才需 05/08 12:40
104F：→ tsairay: 要一开始就把架构弄好 05/08 12:41
105F：推 LiloHuang: 如果主管在意性能或记忆体用量，那就是去做实际的量测 05/08 12:43
106F：→ LiloHuang: 若程式码更好维护，也没有耗用更多记忆体或者变慢 05/08 12:45
107F：→ LiloHuang: 可省记忆体是省了多少，快了多少都要用科学的方法量测 05/08 12:46
108F：→ LiloHuang: 如此一来才能有双赢的局面。 05/08 12:47
109F：→ badyy: 小鲁只会用profiler跑数据,用眼睛跑功力不够还真不行XD 05/08 13:27
110F：推 tloy1966: Clean code 看一下 05/08 13:37
111F：推 Argos: 出来混个性别太硬 公司要你怎麽写 你就怎麽写 东西出来就好 05/08 14:09
112F：→ Argos: 如果觉得公司怎麽都叫我写些垃圾 好极了 这代表你根本不该 05/08 14:10
113F：→ Argos: 待在这种鬼地方 太埋没你的才能了 05/08 14:10
114F：→ Argos: 工作就完成主管交办事务 想写自己理想中的东西 就在自己的 05/08 14:12
115F：→ Argos: side project爱怎麽玩就怎麽玩吧！ 05/08 14:12
116F：嘘 kenwufederer: 只觉得主管人身攻击就不对 05/08 15:21
117F：推 leoloveivy: 有技术 处事这种态度 你就慢慢等你的柏乐吧 05/08 15:25
118F：嘘 oread168: 嘘人身攻击 05/08 16:08
119F：→ ECMA: 不用辩 实力累积够了就跳 很多主管都不容别人质疑 05/08 22:13
120F：→ y3k: 文人相轻而已 这种要说对错要把全部的情境需求厘清才知道 05/09 09:00
121F：→ y3k: 拿建构子来说 我自己也是会尽可能让建构子完成大部分参数 05/09 09:02
122F：→ y3k: 的带入 在有多型需求的时候才会用.with或.put给值@@ 05/09 09:03
123F：→ y3k: 你们的沟通有问题 而且看起来你没有弄很清楚为何书上那样教 05/09 09:05
124F：→ y3k: 所以不太有办法拿出强大说服力 如果都到那个程度主管还是不听 05/09 09:06
125F：→ y3k: 那就是他不愿意沟通 你们就自求多福吧XDD 05/09 09:06
126F：→ leacks: 看怎样用，跟怎样的组译器，不觉得你主管说的全然是错 05/09 09:20
127F：推 f124: 主管说的都是对的 Yes Your Highness! 这样回就对了 干嘛辩 05/09 10:05
128F：推 Luos: 主管想法有点旧 05/09 11:12
129F：→ Lordaeron: 果然是毛语录一出，红卫兵们都说好。 05/09 11:26
130F：嘘 abola921: 书本里说的就一定对？书本里的情境跟你的团队相同？ 05/09 14:24
131F：→ abola921: 情愿相信外国的13道金牌，也不相信在战场上拼战的人？ 05/09 14:26
132F：→ abola921: 团队合作求的是一致性，或许你比其它人强，但不代表别人 05/09 14:27
133F：→ abola921: 也必需要跟上你的脚步，脚步一致才能一起做事 05/09 14:28
134F：推 abola921: 再来是接下来怎麽办，如果你还是想拼技术，那就得离开 05/09 14:30
135F：→ abola921: 朝向假DevOpt真统包工程师的路，很可能是走孤狼路线 05/09 14:32
136F：→ abola921: 不然就是要学习如何与团队相处，特别是怎样表达想法 05/09 14:34
137F：推 doranako: by case啦，记忆体多当然用物件，记忆体不够只好用传统 05/09 19:00
138F：→ doranako: 写法但难维护 05/09 19:00
139F：推 b510336: 我觉得我完全可以理解你的心情... 05/09 23:04
140F：推 thinklu: 你老板怎麽会这麽不求上进...用procedure programming写 05/10 14:54
141F：→ thinklu: 写code写得这麽丑又难扩展跟debug真的有比较好? 这种人感 05/10 14:55
142F：→ thinklu: 觉大概就这样了... 05/10 14:56
143F：→ thinklu: 他可能没看过真的写得很好的程式 只能说原po加油！ 05/10 14:58
144F：→ feeya: 老板说省记忆体 你就得省记忆体 不然哩 05/10 15:27
145F：→ feeya: 你应该要找出更能省记忆体的方法阿 05/10 15:29
146F：→ lensuper: 就说不要搞嵌入式了，难学，薪水又低 05/10 19:01
147F：推 Killercat: 语言？是否embedded? embedded有自己特殊的policy 05/11 15:36
148F：→ Killercat: 另外design pattern基本上只会用更多记忆体 很少有反例 05/11 15:37
149F：→ Killercat: 因为他重点在於好修改好扩充 而非好效能跟节省资源 05/11 15:37
150F：→ Killercat: 在resource critical的环境加上错误语言下 DP只是找事 05/11 15:38
151F：→ Killercat: 把整个环境摊开看一下比较好讨论 05/11 15:38
152F：→ prpure: 第一个例子不都是区域变数吗,应该没省到吧 05/13 00:21
153F：→ prpure: 用temp有时就真的是temp,或懒得想名称 05/13 00:23
154F：推 DWR: 结果写甚麽code没说 有些就是resource有限 05/13 23:20
155F：→ liangyiiiii: 不应在职场抛书包 主管不是被你教导的 没有对错 只 05/20 22:09
156F：→ liangyiiiii: 有他说了算 05/20 22:09