[讨论] 主管不认同书本的知识,说我没学好程设

楼主: purin88 (原来我是愤怒的乡民)   2016-05-07 20:18:49
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
重构的作者是建议参数不用丢太多,建立一个物件,
设定物件的值,把物件丢进建构子,或方法参数中,然后我这样跟我主管说,他又说我没
脑袋吗
没办法判定这个作者有问题
参数本来就全丢给建构子,让建构子去塞,即便
参数很多也没关系,说我物件导向没学好
反正一直在对我人身攻击,即使我提到重构
设计模式,对他来说就是烂书,作者乱写
请问我该如何是好?
作者: Clangpp (Clang++)   2016-05-07 20:24:00
换部门?? XD
作者: testPtt (测试)   2016-05-07 20:25:00
注重内存有他的写法 一般DP重点在好懂好改
作者: Clangpp (Clang++)   2016-05-07 20:26:00
四人帮是乱写一通?? 科科
作者: mithuang (阿明)   2016-05-07 20:27:00
又要Code Review又不接受新知识的主管真另人头疼
作者: chuegou (chuegou)   2016-05-07 20:28:00
code维护的频率高吗?还是写完之后几乎不会动?
作者: leicheong (睡魔)   2016-05-07 20:28:00
有很多程设习惯并不适用于硬件资源受限如embedded
作者: mithuang (阿明)   2016-05-07 20:28:00
现在PC都强到不行,为了那一滴滴滴效能牺牲维护性,划不来
作者: leicheong (睡魔)   2016-05-07 20:29:00
的情况?
作者: Sirctal (母猪母猪 夜里哭哭)   2016-05-07 20:30:00
很难说主管是对是错... 要看立足点 只是如同 mithuang大
作者: YSimpson (Simpson)   2016-05-07 20:30:00
把程式贴出来才知道问题在哪里
作者: BignoZe (BignoZe)   2016-05-07 20:32:00
要看看你要解决什么问题才看看要不要用设计模式 过度设计
作者: vi000246 (Vi)   2016-05-07 20:33:00
这种时候就听主管的 出事他负责
作者: leicheong (睡魔)   2016-05-07 20:33:00
好像以前盛行了十数年的Frame Pointer Omission现在也
作者: BignoZe (BignoZe)   2016-05-07 20:34:00
造成的成本可能比缺乏设计还要高 看你们要追求的是开发速
作者: leicheong (睡魔)   2016-05-07 20:34:00
为了方便除错时做stack trace而默认关闭了.
作者: Newtype (你快乐所以我快乐)   2016-05-07 20:34:00
自己的作品这样写就好了 上班就不要跟主管争了
作者: BignoZe (BignoZe)   2016-05-07 20:35:00
主管也是个不好学的人 设计模式和重构算是基本的东西了不过你也不必看了什么书就觉得那本书的方法好棒棒一定要用 学东西是为了面对未来的挑战而学的 有一天你公司的东西需要好的架构 这些设计模式就会派上用场了
作者: NCUking (中大王)   2016-05-07 20:38:00
你的主管可能是以前是搞韧体之类的
作者: biboSnake (snake)   2016-05-07 20:38:00
你不是在工作吗?他是你主管 你还想说什么
作者: Hikkiaholic (= =a)   2016-05-07 20:38:00
作者对你的影响力 没有主管的万分之一对你而言 主管比贾伯斯比尔盖兹耶稣上帝天王老子 更
楼主: purin88 (原来我是愤怒的乡民)   2016-05-07 20:40:00
唉,我就只是难过被人身攻击
作者: Hikkiaholic (= =a)   2016-05-07 20:40:00
大 主管怎做就怎做 好坏不重要违背他 做烂就算 做好他更气 表示你比他厉害
作者: Deltaguita (伯利兹)   2016-05-07 20:42:00
以他说的为主,不然就是分析优劣给他看
作者: biboSnake (snake)   2016-05-07 20:43:00
推楼上
作者: Ekmund (是一只小叔)   2016-05-07 21:01:00
什么都塞建构 就祈祷这物件不会被当样板大量衍生
作者: sayya2311 (ya)   2016-05-07 21:03:00
你要的是这公司的$还是自己的竞争力,2选1
作者: littlebau (小宝)   2016-05-07 21:03:00
照他说的写。比较好的方法本来就万百种。不是吗?
作者: Ekmund (是一只小叔)   2016-05-07 21:03:00
等著见识超肥大档案载着几十种规则诞生
作者: CRPKT (crpkt)   2016-05-07 21:04:00
换公司
作者: Yshuan (倚絃)   2016-05-07 21:06:00
换吧 反正台湾写程式钱都差不多少
作者: sing10407 (阿U)   2016-05-07 21:10:00
沟通有问题,说服不应该一直丢书丢连结;再者主管坚持应该就直接用主管的方法,毕竟出事是主管直接被定
作者: iamshiao (CircleHsiao)   2016-05-07 21:15:00
真的是出来混才知道守旧又自负的人比想像中多很多,人家一句以前都这样做还不是好好的,你只能摸摸鼻子,毕竟那也是事实,不行就换工作吧
作者: giantwinter   2016-05-07 21:16:00
离职
作者: james732 (好人超)   2016-05-07 21:19:00
不过像用在嵌入式系统的程式似乎确实要斤斤计较?我觉得要看原PO的使用情境?以效能与memory来说,应该可以分析产生数据来说明?
作者: ticks (ticks)   2016-05-07 21:23:00
拿compiler课本,翻到dataflow analysis和SSA的章节呛他
作者: popcorny (毕业了..@@")   2016-05-07 21:32:00
单方说词..建议请你主管出来辩论 (先等我买鸡排..)
作者: longlongint (华哥尔)   2016-05-07 21:32:00
那就 跟他说好然后 改code给他看然后编译自己的code
作者: coronach (...)   2016-05-07 22:08:00
你的主管很明显是早期写C出身的人,但是现在新的compiler很强,就算embedded 都不一定要那么麻烦了...
作者: fridayjason (I'm not Beloved)   2016-05-07 22:14:00
时代不同 以前系统规格差的时后 只能省则省硬干code写得丑难维护 换个角度其实是让自己不易被取代
作者: ns1234 (FAR)   2016-05-07 22:16:00
录音 换公司?
作者: comesuck (艾米德)   2016-05-07 22:34:00
他不明白stack heap gc的运作吧function传入值十几个还不宣告class包起来真的很有事
作者: tsairay (火の红宝石)   2016-05-07 22:37:00
文人相轻
作者: steven11329 (清新柳橙)   2016-05-07 22:50:00
切入的角度不同吧…我觉得没有对错而且尽信书不如无书,书上说的不一定都要遵循啊!
作者: zelda123 (丸子)   2016-05-07 23:06:00
从叙述来看我看不出有哪里人身攻击
作者: ah7675 (阿毛)   2016-05-07 23:48:00
这是典型刚出社会的人的毛病,丢网址给别人看更是蠢对解决问题一点帮助也没有 而且只想着对与错 也不考虑背景、场合 什么平台 开发周期长短及产品导向也不清楚只因为自己学了认为对的东西就战无不胜 这个主管可能很烂
作者: ADYex (寵物狼音樹)   2016-05-07 23:53:00
你需要看Clean Code的番外篇 专业程式设计师的自处之道
作者: ah7675 (阿毛)   2016-05-07 23:53:00
但你用的方式就算证明你是对的又如何?
作者: ADYex (寵物狼音樹)   2016-05-07 23:57:00
不过我想你还是快逃吧
作者: ripple0129 (perry tsai)   2016-05-08 00:19:00
虽然觉得是看案例,不过看文章推测该主管没提出原因,单纯说DP作者在乱写就知道素质了
作者: realbout (萨摩诃)   2016-05-08 00:27:00
其实和学校教授一样,用嘴写的一手好程式
作者: poloball (吃不胖真无奈…)   2016-05-08 00:29:00
我觉得直接丢书本或丢网址有点强迫逼人接受的感觉
作者: justben (BEN)   2016-05-08 00:30:00
找些软件 实测啊 用数据说话
作者: poloball (吃不胖真无奈…)   2016-05-08 00:30:00
自己活用书中知识 以你们的案例为例解释可能较好
作者: poloball (吃不胖真无奈…)   2016-05-08 00:31:00
直接丢个书名或网址 好像网络上在笔战
作者: realbout (萨摩诃)   2016-05-08 00:32:00
就像房子乱盖也是挺快的
作者: carbopon   2016-05-08 01:59:00
你能说出这个case,为什么用这写法比较好吗?
作者: WolfLord (呆呆小狼￾ ￾ N￾ ￾ )   2016-05-08 02:06:00
软件猪就是种种主张弄出来的,然后一堆自以为管理很优的笨蛋交出更多笨蛋,以光速抵销摩尔定律的进步。让计算机性能永远不够快...想想8088跑DOS的算PI速度为什么比WINDOWS+i7+32GRAM还快?
作者: Gaogaigar   2016-05-08 02:29:00
说不定你拿去实测后,你的code会比较快不过从你这文没解释清楚来看,你沟通上对主管制造的困扰可以不少
作者: jl40 (jl)   2016-05-08 03:25:00
程式员相轻?
作者: valen720918   2016-05-08 08:44:00
要说出为什么要这样写,不是一昧说某大神怎么都怎么写何况,2个方案都可以 work ,要说明挑哪一个优劣
作者: yourinfo (...)   2016-05-08 09:30:00
主管让你怎么写就怎么写,只要没有什么后遣症就好等swtich case不好维护时再来重构,到时不是更好说明变量怎用,参数怎传,就都不是那么重要,习惯问题罢了
作者: wens (文思)   2016-05-08 10:15:00
说起来这个 case 其实编译器可能会最佳化掉
作者: siriusu (かがみは俺の嫁。)   2016-05-08 10:23:00
同valen的意见
作者: libery (我只是一个过客)   2016-05-08 10:42:00
作者: liddle (Guderian)   2016-05-08 11:11:00
你的举例太空泛,很难判断。DP是累积归纳出的解题结构。专对付OO会遇上的问题。
作者: tsairay (火の红宝石)   2016-05-08 12:23:00
有时候某些写法,是程式架构大才有利,程式架构小反而会显得累赘像是switch case如果只有三个,而且也不会再增加,你就没必要写得那么"厚工",除非case的数目会一直膨胀,你才需要一开始就把架构弄好
作者: LiloHuang (十年一刻)   2016-05-08 12:43:00
如果主管在意性能或内存用量,那就是去做实际的量测若程式码更好维护,也没有耗用更多内存或者变慢可省内存是省了多少,快了多少都要用科学的方法量测如此一来才能有双赢的局面。
作者: badyy (nick)   2016-05-08 13:27:00
小鲁只会用profiler跑数据,用眼睛跑功力不够还真不行XD
作者: tloy1966 (JJspeaking)   2016-05-08 13:37:00
Clean code 看一下
作者: Argos (Big doge is watching u)   2016-05-08 14:09:00
出来混个性别太硬 公司要你怎么写 你就怎么写 东西出来就好如果觉得公司怎么都叫我写些垃圾 好极了 这代表你根本不该待在这种鬼地方 太埋没你的才能了工作就完成主管交办事务 想写自己理想中的东西 就在自己的side project爱怎么玩就怎么玩吧!
作者: kenwufederer (Nash)   2016-05-08 15:21:00
只觉得主管人身攻击就不对
作者: leoloveivy (cried)   2016-05-08 15:25:00
有技术 处事这种态度 你就慢慢等你的柏乐吧
作者: oread168 (大地的精靈R)   2016-05-08 16:08:00
嘘人身攻击
作者: ECMA   2016-05-08 22:13:00
不用辩 实力累积够了就跳 很多主管都不容别人质疑
作者: y3k (激流を制するは静水)   2016-05-09 09:00:00
文人相轻而已 这种要说对错要把全部的情境需求厘清才知道拿建构子来说 我自己也是会尽可能让建构子完成大部分参数的带入 在有多型需求的时候才会用.with或.put给值@@你们的沟通有问题 而且看起来你没有弄很清楚为何书上那样教所以不太有办法拿出强大说服力 如果都到那个程度主管还是不听那就是他不愿意沟通 你们就自求多福吧XDD
作者: leacks (天行者)   2016-05-09 09:20:00
看怎样用,跟怎样的组译器,不觉得你主管说的全然是错
作者: f124 (....)   2016-05-09 10:05:00
主管说的都是对的 Yes Your Highness! 这样回就对了 干嘛辩
作者: Luos (Soul)   2016-05-09 11:12:00
主管想法有点旧
作者: Lordaeron (Terry)   2016-05-09 11:26:00
果然是毛语录一出,红卫兵们都说好。
作者: abola921 (南港金城武)   2016-05-09 14:24:00
书本里说的就一定对?书本里的情境跟你的团队相同?情愿相信外国的13道金牌,也不相信在战场上拼战的人?团队合作求的是一致性,或许你比其它人强,但不代表别人也必需要跟上你的脚步,脚步一致才能一起做事再来是接下来怎么办,如果你还是想拼技术,那就得离开朝向假DevOpt真统包工程师的路,很可能是走孤狼路线不然就是要学习如何与团队相处,特别是怎样表达想法
作者: doranako (真爱无限)   2016-05-09 19:00:00
by case啦,内存多当然用物件,内存不够只好用传统写法但难维护
作者: b510336 (风的细语)   2016-05-09 23:04:00
我觉得我完全可以理解你的心情...
作者: thinklu   2016-05-10 14:54:00
你老板怎么会这么不求上进...用procedure programming写写code写得这么丑又难扩展跟debug真的有比较好? 这种人感觉大概就这样了...他可能没看过真的写得很好的程式 只能说原po加油!
作者: feeya (24 August 升格为乡民)   2016-05-10 15:27:00
老板说省内存 你就得省内存 不然哩你应该要找出更能省内存的方法阿
作者: lensuper (莫三)   2016-05-10 19:01:00
就说不要搞嵌入式了,难学,薪水又低
作者: Killercat (杀人猫™)   2016-05-11 15:36:00
语言?是否embedded? embedded有自己特殊的policy另外design pattern基本上只会用更多内存 很少有反例因为他重点在于好修改好扩充 而非好效能跟节省资源在resource critical的环境加上错误语言下 DP只是找事把整个环境摊开看一下比较好讨论
作者: prpure (风速)   2016-05-13 00:21:00
第一个例子不都是区域变量吗,应该没省到吧用temp有时就真的是temp,或懒得想名称
作者: DWR (罗杰)   2016-05-13 23:20:00
结果写什么code没说 有些就是resource有限
作者: liangyiiiii   2016-05-20 22:09:00
不应在职场抛书包 主管不是被你教导的 没有对错 只有他说了算

Links booklink

Contact Us: admin [ a t ] ucptt.com