作者：James.Ying
來源：https://www.cnblogs.com/inday/p/re-architecting-first.html
你有沒有試過，當你踏入一個新的公司，看到了幾千幾萬幾十萬代碼的時候，那種崩潰的感覺？
代碼多不可怕，怕的是代碼的可讀性、維護性、擴展性是如此之差，這時候該怎麼辦呢？
當我進入了新的公司，利用了一個星期去熟悉代碼，也知道了各個開發的編程習慣，在一個大公司里，沒有一個規範的編程寶典，出來的就是這種大雜燴，但作為另一個開發的我，該怎麼做呢？順著他們的開發思路繼續寫這種代碼？
No，It’s Not My Style！
該如何進行慢慢重構，等到一定階段去跟領導說呢？
1、把現在的hard code統統整理一下，這種小改動，相信任何一個LEADER都不會反對的吧。
針對不同的hardcode要有不同的解決方案，如果hard code僅對本類的話，請在本類中使用private const,如果跨越多個類的，請不要怕麻煩，添加一個類，把這些都設置進去，當然，儘量把這些硬編碼的使用歸類。
2、超過50行的方法，進行小重構。超過50行就另外建個方法，相信這個也不會反對吧。
3、儘量不改變原來方法的結構，參數、命名儘量不改動，除非很有爭議性。
原有的一些方法分布的不是很合理，比如View層做了邏輯操作，Controller做了數據操作等，遇到這種就重新建一個項目或者建一個類，按照更合理的方式來進行，保持原有方法不改動，只是通過它再去call一下自己的方法。如果遇到一些重複操作，這樣有便於以後的維護。
第三步你是不是覺得多餘呢？如果這麼覺得，那是你還沒有經歷過恐怖的項目而已，而且你這種提煉，為以後的維護、改版、更新都會有幫助，這裡要注意一點，千萬別直接去掉原先的方法參數，因為你不知道有多少地方調用了它，等你的提煉穩定了，試著去改變原先的方法或者去除。
以上只是代碼的小改動，相信不難，如果要重新構建一個完全新的系統，這事情還是要多多考慮的，肯定不能一蹴而就的，等完成了上面三步，相信你的領導已經對你刮目相看了，接下來的事情就好辦了。
4、統一wcf、webservices、webapi等接口，儘量使用統一方式，方便調用。
如果調用的時候用的是自動更新方式，那就統統使用這種方式，如果是手動編寫的，千萬別放在一個類里（博主已經崩潰中）
剛接觸項目的時候，我一直覺得他們是直接引用，然後手動右鍵獲取更新，誰知道他們是把增量代碼手動複製到Reference.cs中，著實讓我吃驚不少，what a fuck day!
遇到這個問題，我真心沒法修改，動一動把命送，因為merge的都是外國人，英語也不好，只能先暫時跟著他們的思路走，等英語好了再說吧。
5、把項目中的緩存用統一的方式。
編寫一個ICache接口，項目中所有使用到緩存的地方都修改掉，為了避免有多個緩存方式，可以寫一個CacheFactory或者CacheStrategy，這樣方便你在內存方式還是其他方式緩存進行切換。
這個是一個非常有必要的做法，不管你是重構、新建，都一定要注意這點，否則後期你維護或者更換的話會讓你痛不欲生。
Add，Save，Delete對應原先的Cache方法，這個大家應該都知道，Retrieval是一個檢索方法，如果緩存中沒有這個cache，那將執行func委託，得到的結果緩存起來並返回。CacheManagerDict是對緩存的一個管理，有些時候我們需要手動清除某一個緩存，如果你用的HttpCache，那可以不使用這個屬性，但如果你是其他方式緩存，或者是分布式的話，建議加一個管理dict，方便你進行管理。
重構之路任重道遠，暫時只能進行小改動，大的改動真心不太敢弄，牽涉的東西太多了，但我們如果盡力能做到以上幾點，相信對以後的維護、擴展還是有幫助的。