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