最近兩周一直在忙于重構以前的一段代碼。代碼是一個很復雜的算法，總共有4個主要的方法，代碼行數之和大概有4千多行。這個算法以前不是我寫的是一位已經離職人員的大作，剛開始接受的時候我看的頭都大了。現在想想造成這種情況主要原因主要有：
1 因為這是一個很復雜的算法，需求文檔寫的也不是很詳細，導致理解起來很費力，最后是通過不斷和測試人員不斷交流，才了解了整個算法的大概。
2 看代碼最可怕的事情是什么？結構不好、變量命名不規則、實現思路不符合常規。都不是，最可怕的是沒有注釋，我所要面對的是我可以自由發揮想象的代碼，可是 一個算法不是我可以隨意定的。剛接手代碼時的主要工作就是，給代碼添加注釋，一邊看一邊補注釋，最后可能達到每5行代碼就可能有一行注釋，就這樣才把代碼 的實現絲路搞得差不多了。
3 方法過長 4個方法，4千多行代碼，平均每個1千行，但最大的那個方法有2千多行，看著無注釋的兩千行代碼，我暈。
4 重復功能的代碼 接受別人的代碼，如果感覺是重復的代碼，自己也不敢給立刻改造，需要把兩段代碼仔細的比較，生怕有紕漏，導致一些更可怕的問題，畢竟當時對代碼和算法不熟悉
5 龐大的if else、for while 循環，看代碼的時候需要對那些{},眼暈，代碼太長了，如果你想了解一段代碼的功能，難了。
6 數據類的命名 那位老兄懶點，有些后來添加的屬性，他懶得添加代碼，就用原來的方法，看看代碼就給帶溝里去了。
7 很多無用的變量充斥其中，讓你四處查找該變量在哪用的，最后發現，沒用，氣瘋了

    痛苦的經歷，當時看這些代碼辭職的心都有，型號當時在外面做項目，可以慢慢的消化，如果在公司，問題日清，恐怕我也要被清理走了。
下面說說我重構的過程，主要是針對上面提到的幾點：
1 不用說了，理解算法，才能作出正確的實現，也才能保證修改的代碼減少出錯的機率。
2 注釋以前添加了很多，現在在回頭再仔細看，當時有些理解是不正確的，修正那些注釋，同時把自己最新的理解添加到程序上。添加注釋時對于實現長點的代碼可以 用一些特殊的符號 象＃$等一些特殊的符號分隔開，注釋里說明這段代碼實現的功能，同時在開始和結束的注釋上 添加一個簡單的start、end，看起來舒服多了
3 方法過大，沒有其他的解決辦法，拆方法，但拆方法的時候要考慮變量的作用域，盡量確保一個變量的作用域在一個方法中，這樣可以減少代碼的出錯的可能性，是在不行的就通過返回數據的方式，給變量重新賦值
4 對于重復的代碼，沒其他的辦法，抽象出一個新的方法，讓后在主方法中調用。但這種修改可能會造成一個不太好的現象，就是代碼調用層次太多，調試起來也很麻煩，這問題只能等以后在做大的重構的時候，對實現思路的重構了
5 對于if else ,或者循環，看看是否可以通過continue、break 來減少嵌套層次
6 數據命名，這是每個程序員進入新公司的必修課，如果沒人管，那只能說管理有問題。可以通過一些重構工具來修改變量、方法的名稱、相應的工具會修改引用的名稱，減少出錯的可能性
7 多余變量已經要堅決刪除，不是考慮什么效率問題，知識考慮代碼的可讀性。現在地很多開發工具可以表示出沒有引用的變量，刪除、重新編譯看看有沒有引起相關的錯誤

本來前些時剛看完設計模式，想用用呢，因為算法中有很多相對的算法可以通過策略模式解決，可是最后犯懶，以后再說吧。
一點感受，希望能和大家交流：）