推荐你看这本书，或许会对你有帮助： 无瑕的程式码 番外篇：专业程式设计师的生存之道 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/cn.aspx?n=bbs/Soft_Job/M.1462640428.A.59D.html