我也是比较认同你做法,
不过说实话,code review本来就会出现这种状况,
很多人在code review时,
是抱着去批评别人的态度在做的,
想着我比你利害,我方法比你好,你要改成我方法,
什么写法比较好其实已经不是问题了,
问题是你们这样已经失去了code revew的意义,
搞到你们关系也会影响到,
现在电脑跑够快了,
为了计较省内存或参数要怎么丢而伤和气这非常的傻,
等于是把小小且没什么影向的技术问题搞成人的问题,
你主管一直对你人身攻击这个是不好的,
但你其实也不用太和主管硬碰硬,
尤其是这种小事....
在座大家很多人的工作经验都很多,
遇过"不合理"的要求的经验也很多人有吧,
你这个争议点真的算很小了,
我随便说说我遇过不合理的要求:
1.美术不想切图,就要程式去切图
2.连数据库时,不准用sp和暂存表,一定要在client端把sql拼出来送,而且join只能用left
3.变量命名要求用a1,a2,a3...
至于被人身攻击的经验,
也多到我数不完,
最常被人身攻击的点,
我相信90%的工程师也这样被攻击过,
那就是被批评为不懂使用者,
你主管的用词我看是还好,
有人用词更难听,国骂都出来了,
所以看开点囉,
不要去在意这种小事,
因为有更多大事值得注意,
也不要和主管唱反调,
如果主管没逼你一定要改成他写法的话,
你就听听就好吧,
如果你主管逼你改的话,
你就听你主管改看看,
改了有问题,影响到你做事的效率的话,
那么就看你这公司想不想待,
不想待,忍不了的话就离开,好聚好散吧,
只是你可能要做好心理准备,
搞不好下个主管会更没sense,
其实事情就是这么简单,
加油吧,别被小事打击到,
你会写这些,会想这些,你己经赢过很多人了,
也记得以后,
你当主管时,
要对别人code review时,也千万不要去人身攻击,
就算你觉得对方写得很烂,也要保持尊重
※ 引述《purin88 (原来我是愤怒的乡民)》之铭言：
: 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
: 重构的作者是建议参数不用丢太多，建立一个物件，
: 设定物件的值，把物件丢进建构子，或方法参数中，然后我这样跟我主管说，他又说我没
: 脑袋吗
: 没办法判定这个作者有问题
: 参数本来就全丢给建构子，让建构子去塞，即便
: 参数很多也没关系，说我物件导向没学好
: 反正一直在对我人身攻击，即使我提到重构
: 设计模式，对他来说就是烂书，作者乱写
: 请问我该如何是好？