作者ADYex (寵物狼音樹)
看板Soft_Job
標題Re: [討論] 主管不認同書本的知識,說我沒學好程設
時間Sun May 8 01:00:22 2016
推薦你看這本書,或許會對你有幫助:
無瑕的程式碼 番外篇:專業程式設計師的生存之道
http://www.books.com.tw/products/0010598217
裡面大概是在講身為一個Clean Coder,
在職場中如何處理「人」方面的問題。
---
從你的文章看起來,你對於所受到的質疑,
處理的方式好像是將參考資料直接丟給對方,
說服的理由上則是「因為大師們這麼建議」。
但Martin Fowler與Joshua Kerievsky,兩本重構著作的作者,
他們在書中大量提到的是「程式碼的壞味道」及其帶來的可能壞影響,
同時也提到不要過度設計、以及什麼樣的重構手法會帶來哪方面的trade-off。
有個很重要的觀念是,要根據你的程式、自己判斷是否真的適合某個重構手法。
以下分享我看重構相關書籍的一些心得,
並不是說你就有這些問題(因為文章中也看不完全),
只是一些相關的心得分享~
① Inline Temp
暫時變數並不是個絕對要移除、或是絕對要保留的東西,
Martin Fowler在書中並沒建議你別用暫時變數,
而是「當你發現它妨礙你的其他重構手法時,則該移除它」。
暫時變數的問題在於,當你需要Extract Method時,
會因為它的存在而需要把它透過參數傳遞,
因而導致壞味道「過長的參數列」。
如果沒有這個問題(或其他的問題),暫時變數並不是壞事。
適當的暫時變數,可以透過命名,提升程式碼的可讀性。
見Introduce Explaining Variable一章。
在這個場合下,引入暫時變數反而是比較好的做法,
有時甚至需要先Inline Temp、再Extract Method,最後再把Temp Extract回來。
至於記憶體議題要看場合,
以現在的硬體來說、應該大多都不需要擔心這個問題。
如果profiler的效能剖析真的指出效能瓶頸在這方面再來處理即可。
② 工廠模式
head first design patten這本書就跟許多的設計模式書籍一樣,
容易看了之後就染上模式癖,忽略了有時可以用更簡單的解法處理問題。
在重構--向範式前進(Joshua Kerievsky)一書中,
就提到了如何透過許多重構手法往設計模式前進、但不過度設計的作法。
你主管說的作法,在某些情況下的確有可能是更好的作法。
工廠模式的優點在於程式碼分屬各自的class中、未來容易擴展,
但是也為程式帶來額外的複雜度。
如果某個地方的物件創造,未來不太會出現太多的類型變種,
的確是透過switch case+Creation Methods搞定就好了。
不需要特別引入工廠模式,帶來額外的複雜度。
③ Introduce Parameter Object
「過長的參數列」的確是個明顯的壞味道,
這個壞味道在重構與Clean Code(Martin, Robert C.)兩本書中都有提到。
這個壞味道主要的問題在於:
1. 可閱讀性降低
2. 未來維護參數/Method不易
我看不太懂你文中的set get是什麼意思,
如果是以下寫法的話,在語意上會有點不一樣:
User user = new User("Jack");
User user = new User();
user.setName("Jack");
後面這種寫法雖然可以減少1個建構式參數,
但是語意上比較偏向是「將原本沒有名字的使用者改名為Jack」。
這方面比較見仁見智,只是稍微說一下可能會有這樣子的理解。
要消除過長的參數列這個壞味道,
手法在書中大概有提到了4個,包括:
1. Replace Parameter with Explicit Methods.
2. Replace Parameter with Method.
3. Introduce Parameter Object.
4. Preserve Whole Object.
你的文中最有著墨的Parameter Object與34比較有關,
也並不一定就是「建立一個物件」,
而是「將各自相關聯的參數以物件包裝起來」。
例如,假設在一個租書店的程式中有以下程式碼:
BookPreservation bookPreservation = new BookPreservation(
"Jack", "1433717", "2016/5/8", "2016/8/8");
其中4個參數分別為 userName, userId, startTime, endTime,
比較好的作法是將各自相關聯的參數各自包裝,變成:
BookPreservation bookPreservation = new BookPreservation(
new User("Jack", "1433717"), new TimePeriod("2016/5/8", "2016/8/8"));
這個重構手法能帶來的好處如下:
1. 提升可讀性
2. 未來維護簡單
3. 容易因此將相關功能移入新造的class中,改善程式碼分工
試著像這樣將原作法的壞處與新作法的好處跟主管說看看吧。或是塊陶。
※ 引述《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
: 重構的作者是建議參數不用丟太多,建立一個物件,
: 設定物件的值,把物件丟進建構子,或方法參數中,然後我這樣跟我主管說,他又說我沒
: 腦袋嗎
: 沒辦法判定這個作者有問題
: 參數本來就全丟給建構子,讓建構子去塞,即便
: 參數很多也沒關係,說我物件導向沒學好
: 反正一直在對我人身攻擊,即使我提到重構
: 設計模式,對他來說就是爛書,作者亂寫
: 請問我該如何是好?
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.166.119
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1462640428.A.59D.html
1F:推 wddx: 謝謝大大分享 05/08 01:32
2F:推 abc0922001: 感謝,學習了 05/08 02:06
3F:推 kwpn: 第三個案例也可選擇使用builder pattern 05/08 03:40
4F:推 jyhfang: 感謝分享心得 05/08 03:46
5F:推 pest: 推認真 真的也要看code才知道 05/08 04:50
6F:推 popcorny: 這篇認真.. 給推! 05/08 07:23
7F:推 ccas: 推 ~ 05/08 07:59
8F:推 laputaflutin: 這篇吊出許多好文 05/08 09:29
9F:推 yotsuba1022: 謝謝 05/08 09:43
10F:推 frank11118: 推,好文,感謝大大分享 05/08 10:00
11F:推 wildli0422: 謝謝大大教學 又上了一課了 05/08 10:00
12F:推 siriusu: 推推推 05/08 10:28
13F:推 wentzwu: 很棒的分享, 推~ 05/08 10:44
14F:推 littlethe: 把書的知識應用在現實中的好例子 05/08 11:02
15F:推 icbruce: 感謝分享!有實例好懂好多 05/08 12:24
16F:推 wildpeanut: 推這篇,程式碼的重構目標應該是可讀性優先,程式碼本 05/08 13:10
17F:→ wildpeanut: 來就是寫給人看的,因此大家都看的懂比較重要 05/08 13:10
18F:推 silveriii: 05/08 14:30
19F:推 wxywxywxy: 推~ 05/08 14:51
20F:推 orange7986: 推 05/09 01:00
21F:推 kkk003: 沒想到過第三點這種語意的問題 05/09 02:30
22F:推 Csongs: 快陶XD 05/09 09:07
23F:推 storm654321: 早上看到原PO推薦的書籍~真是本好書 05/09 17:15
24F:→ storm654321: 對於擁有不擅交際、孤僻個性的我很有幫助 05/09 17:16
25F:→ psliurt: 老實說,那樣的主管,還會看這些大師的書嗎? 05/10 12:54
26F:→ psliurt: 甚至有可能他連design pattern都沒聽過呢! 05/10 12:55
27F:推 lainhot0114: 程式寫久了大多不是技術瓶頸,而是心態瓶頸 05/10 23:24
28F:推 iamian: 推 05/21 19:43