再寫一些吧，之前一段時間發現我過分的想要使用重構的技術，保證自己的代碼是優雅的、易於維護的，但有時候是不適合重構的。
之前看<重構>的時候，覺得有好多地方都可以重構，但後來發現每當自己重構的時候，就會給自己惹來一大堆麻煩，就好像《effective java》裏面提倡的，不要輕易使用繼承一樣。程序猿總會根據自己的習慣使用自己認爲最舒服的方法，就像大家都喜歡繼承，但其實裏面有很多風險。
《重構》裏面寫了很多種代碼的壞味道，但我能區分的不多，突然想起來之前的一個自己把自己坑的了事情就記一下吧。
大量的複製代碼，這算是我實習以來做過的最多的錯誤的事情，很多朋友也開玩笑說我們是代碼的搬運工。然而並不應該這樣，並且這一問題在我做一個接口項目的時候得到了真實的懲罰。《重構》中的觀點是，當你發現一段代碼不止一個地方可以使用的情況下，就應該把他提煉出來，使得更多類可以使用。如果你發現一個方法，只有一個地方可以使用，那麼就把它並回原來的方法。
我以前覺得這就是單純的爲了代碼整潔，後來才意識到，如果不這樣做會坑了自己。我最近的一個項目趕工期，我偷懶的把一段代碼複製到了4套邏輯裏面，因爲他們都需要鏈接FTP 做類似的文件IO處理。但是我從來沒有整合。一開始沒有任何問題，客戶說修改文件規則的時候，我才發現我需要更改四遍，而這不是單純修改四遍，因爲這四套邏輯已經不是一回事了，我必須按照四種情況去挨個修改。這個時候似乎應該把共同的功能提到對應的工具類中，這樣起碼修改FTP文件名可以調一個同樣的方法，但我還是偷了個懶~~！沒有提煉，因爲這樣快一點。
結果最倒黴的事來了，３月份上線的時候，突然發現協議不問題不能用ＦＴＰ的方式了，我簡直要崩潰了，我需要把四套鏈接ＦＴＰ的邏輯全部改成接口的。這是個巨大的折磨。。。。所以我突然想起來要寫這個文章，代碼一開始的設計要精心考慮每一種可能，就像efectiv java裏面說的許多細節，你應該保證這些規則的存在，這樣你的代碼纔是可以拓展的。而當你後期發現你的代碼是存在問題的，一定要用最根本的方式去解決，該提煉的的提煉，該解耦的解耦，有時候不重構真的會玩死自己。