我也是比較認同你做法,
不過說實話,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
: 重構的作者是建議參數不用丟太多，建立一個物件，
: 設定物件的值，把物件丟進建構子，或方法參數中，然後我這樣跟我主管說，他又說我沒
: 腦袋嗎
: 沒辦法判定這個作者有問題
: 參數本來就全丟給建構子，讓建構子去塞，即便
: 參數很多也沒關係，說我物件導向沒學好
: 反正一直在對我人身攻擊，即使我提到重構
: 設計模式，對他來說就是爛書，作者亂寫
: 請問我該如何是好？