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

看板Soft_Job作者ADYex (寵物狼音樹)時間8年前 (2016/05/08 01:00)推噓24(24推 0噓 4→)

留言28則, 25人參與討論串5/14 (看更多)

推薦你看這本書，或許會對你有幫助：無瑕的程式碼番外篇：專業程式設計師的生存之道 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://www.ptt.cc/bbs/Soft_Job/M.1462640428.A.59D.html

推

wddx

05/08 01:32, , 1^F

05/08 01:32, 1^F

推

abc0922001

05/08 02:06, , 2^F

05/08 02:06, 2^F

推

kwpn

05/08 03:40, , 3^F

05/08 03:40, 3^F