[討論] 主管不認同書本的知識,說我沒學好程設

作者: 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