我觉得在台湾跟别人code review常常会有三种结果
第一种是觉得我以前这样写都没问题
干麻还要用另外一种写法
第二种是物件导向、重构、设计模式洗三小
书上的东西不能拿来现实中用
我只知道硬干一样可以解决问题啦!
第三种就是可能知道物件导向、重构、设计模式洗三小
但也没说到精通的地步
可是你一跟他讨论就一副老子就是要跟你战到赢的姿态
第一种最容易在主管身上出现
第三种最容易在还在coding阶段的工程师身上出现
第二种则是资深工程师跟资深主管最容易出现
我觉得code review除了可以知道自己程式哪里写的不好
同时也是可以知道自己哪里不足
或是还有哪些招式可以用的最好时机
因为每种解法都代表着每种不同的思维
但也许是台湾教育从小缺乏批判性的思考与自省
所以有些工程师从一开始写程式就是硬干硬干硬干
从来没考虑过是否还有更弹性更好的写法
然后只要稍微要改需求就整个崩溃
只要出现一个bug就要加班好几天
以为写程式本来就会有bug
所以硬干就对了有bug再说
然后整天靠北当软件工程师好苦天天都要加班
明明就是自己造孽的结果
一种就是我讲的还没讨论之前他就已经认为他已经是对的
遇到这种我觉得最靠北
这种人偏偏又似懂非懂
像是我遇过国内前三大资工毕业的
看到我的SQL有用join居然问我用join的效率不是很差嘛
当下我是还满想酸难道要像现在一样所有字段都用子查询
同一个talbe每一个字段要取对应的资料就全部查一次效率才好?
不过这问题太…超乎我的程度我直接转移话题懒的去澄清
有些人则是在讨论的时候狂攻击你的论点
然后你用另外一个回答反驳的时候他又继续找下一个问题攻击你
反正不管怎样他的结论就是“你错了”
这些人基本上我都能避免跟他们讨论就避免
因为除了浪费时间外
可能因为你砍站不够、不够资深就觉得你一定是错的
这种想法也是很狭隘
良性的互战可以从沟通中攻击对方论点的不足
以及被对方攻击自己的论点
尤其是自己的论点被攻击时
也代表着也许你对这事物的观念还有你似懂非懂的地方
这时就是可以进步的地方就可以让自己越战越强(误)
也可以反刍自己所学过的东西
但可惜我看到的很多还是重点不是在讨论而是怎么战赢对方
最后对方不爽
自己也没发现自己观点缺陷的地方变成双输的局面
回到原PO的问题
我相信原PO也是求道之人
也是希望程式能写的更好才会去翻那些书学那些技巧
但有的时候你真的无法跟夏虫语冰
效能跟可读性有时本来就要有所取舍
但现在硬件设备越来越强大的情况下
除非真的系统有超级高效能需求或是嵌入是系统资源少到靠北
否则还是应该要以可读性为主
纵使会牺牲一点效能(不影响使用者体验的情况)
也许你主管那时代就是对效能斤斤计较
现在他干主管了还是那一套思维
你也知道台湾一狗票人当主管后
程度、知识水平就停在他离开工程师职位的那一瞬间了甚至还倒退
这种情况下劝你还是少费唇舌说服他
因为从你的内容来看他已经有“你一定是错的”主观意识了
所以你怎样讲都没用
尤其他现在可能也不写程式了
摔坑的人也不是他
所以他更难体会可读性是三小这回事了
结论
如果你真的很在意你想的是精进自己程式功力
那就离职吧
我认为无脑的东西也不会因为你写过一万次就变得有脑
面试时其实就可以多问问公司内部开发上有没有相关的观念
没观念也没关系
至少主管不要来乱就好
※ 引述《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
: 重构的作者是建议参数不用丢太多，建立一个物件，
: 设定物件的值，把物件丢进建构子，或方法参数中，然后我这样跟我主管说，他又说我没
: 脑袋吗
: 没办法判定这个作者有问题
: 参数本来就全丢给建构子，让建构子去塞，即便
: 参数很多也没关系，说我物件导向没学好
: 反正一直在对我人身攻击，即使我提到重构
: 设计模式，对他来说就是烂书，作者乱写
: 请问我该如何是好？