再写一些吧，之前一段时间发现我过分的想要使用重构的技术，保证自己的代码是优雅的、易于维护的，但有时候是不适合重构的。
之前看<重构>的时候，觉得有好多地方都可以重构，但后来发现每当自己重构的时候，就会给自己惹来一大堆麻烦，就好像《effective java》里面提倡的，不要轻易使用继承一样。程序猿总会根据自己的习惯使用自己认为最舒服的方法，就像大家都喜欢继承，但其实里面有很多风险。
《重构》里面写了很多种代码的坏味道，但我能区分的不多，突然想起来之前的一个自己把自己坑的了事情就记一下吧。
大量的复制代码，这算是我实习以来做过的最多的错误的事情，很多朋友也开玩笑说我们是代码的搬运工。然而并不应该这样，并且这一问题在我做一个接口项目的时候得到了真实的惩罚。《重构》中的观点是，当你发现一段代码不止一个地方可以使用的情况下，就应该把他提炼出来，使得更多类可以使用。如果你发现一个方法，只有一个地方可以使用，那么就把它并回原来的方法。
我以前觉得这就是单纯的为了代码整洁，后来才意识到，如果不这样做会坑了自己。我最近的一个项目赶工期，我偷懒的把一段代码复制到了4套逻辑里面，因为他们都需要链接FTP 做类似的文件IO处理。但是我从来没有整合。一开始没有任何问题，客户说修改文件规则的时候，我才发现我需要更改四遍，而这不是单纯修改四遍，因为这四套逻辑已经不是一回事了，我必须按照四种情况去挨个修改。这个时候似乎应该把共同的功能提到对应的工具类中，这样起码修改FTP文件名可以调一个同样的方法，但我还是偷了个懒~~！没有提炼，因为这样快一点。
结果最倒霉的事来了，３月份上线的时候，突然发现协议不问题不能用ＦＴＰ的方式了，我简直要崩溃了，我需要把四套链接ＦＴＰ的逻辑全部改成接口的。这是个巨大的折磨。。。。所以我突然想起来要写这个文章，代码一开始的设计要精心考虑每一种可能，就像efectiv java里面说的许多细节，你应该保证这些规则的存在，这样你的代码才是可以拓展的。而当你后期发现你的代码是存在问题的，一定要用最根本的方式去解决，该提炼的的提炼，该解耦的解耦，有时候不重构真的会玩死自己。