前言
《小酌重構系列》是我在博客園的第一個系列文章，這個系列歷時一個多月終於完成了。
完成這個系列后，心里有一些感慨想和大家分享一下。
初衷
寫這個系列的初衷是為了團隊培訓，為什么要做這個培訓呢？
是因為在項目的開發過程中，我們遭遇了一些“代碼的痛苦”。
代碼的痛苦
寫代碼是程序員的基本工作，但寫出好的代碼不是一件容易的事情。
寫不出好的代碼，就可能產生痛苦。
代碼的痛苦包含哪些方面呢？
一般來說，包括可讀性較差、不夠簡潔、缺乏可擴展性、缺乏可維護性等等。
簡單地說，就是代碼質量不高。
“代碼的痛苦”也是開發者的痛苦，低下的代碼質量可能會降低系統的穩定性。
系統最終是要交付於客戶的，系統如果不穩定，客戶用的時候會痛苦會抱怨，維護時你不僅要忍受客戶的抱怨，還要痛苦地去維護“代碼的痛苦”。
痛苦的誘因
這些痛苦並非是無根之源，痛苦的產生是多方面的，不僅和編碼有關，也和管理脫不開關系。
在這里，我僅從編碼角度去分析這些痛苦的原因。
編碼風格的差異
在項目開始前，我們是約定了一些編碼風格和規范的。
但實際做下來，由於各成員的編碼風格差異，使得有些代碼看起來“五花八門”。
為了統一項目的代碼風格，一些成員不得不返工去修改代碼，並且返工不止一次。
編碼習慣的不同
每個人已經形成了一定的思維方式和編碼習慣，即使是一些不好的習慣。
這使得一些曾經發生過的問題，在后續的開發過程中仍然反復地發生。
編碼意識的匱乏
有些成員專注於功能開發，對代碼的規范、整潔度和質量看得較輕，也沒有意識去思考如何寫出優秀的代碼。
當然這也和編碼習慣有關，習慣性的不去思考代碼質量的問題。
代碼審查的匱乏
限於時間和資源問題，在項目中我們只能花費較少的時間來進行code review。
雖然每次code review能發現一些問題，但每次代碼問題的解決方式都只到表面，內里沒有得到根本性地解決，這也是一些問題反復發生的原因之一。
期望的目標
代碼的痛苦就好比一個慢性疾病，現在我們已經知道了自己得的是什么病，以及病發的原因。
接下來要做的就是如何科學有效地治療這個疾病，讓自己漸漸康復起來。
於是在團中，我就做了這個培訓，這個培訓主要有以下幾個期望目標：
- 提高團隊成員的編碼質量
- 促使團隊成員形成統一的編碼風格
- 提高團隊成員的編碼意識，養成思考和自主code review的習慣
- 希望最終的交付物不僅能滿足客戶的需求，還具備良好的維護性
僅經過一時的培訓，是不能夠解決代碼的痛苦的，於是我們采取了培訓+實踐的方式來解決痛苦。
在經過大約2周的培訓，以及近2個月的反復實踐后，團隊成員整體的代碼質量已經有所提高。
關鍵的是，一些缺乏意識的團隊成員已經產生了自主思考的意識，知道去思考代碼的一些細節了。
關於這個系列
草稿和大綱
在開始這個系列之前，我使用Onenote基本打好了所有的草稿，這些草稿的內容大多是一些文字和圖示，代碼則單獨地放在VS解決方案中。
所以在開始正式寫第一篇文章時，我就列出了整個系列的大綱。
草稿終歸是草稿，真正動鍵盤時，還是發現草稿中有很多瑕疵存在，以致於草稿中的文字我基本沒有用到。
草稿並非沒有作用，每次我都會站在第三者的角度去審視和思考草稿的內容，它指引我向更深處去思考一些問題。
限於本人淺薄的知識和窮乏的描述能力，有些深入思考的內容沒能在文章中表達出來。
計划和堅持
如果只有一天的計划，讓自己按時做完這一天的事情，我相信絕大多數人都能夠做到。
生活和工作每一天都在繼續，我寫這個系列，是想讓自己每一天都能按計划進行下去，更是想讓自己長期地堅持下去。
在開始這個系列時，我樂觀地計划每天應該完成一篇。
誠實地講，我知道自己不可能100%的完成這個計划，能有80%就不錯了。
因為每天都會有不同的事情出現，有些事情你是不得不去優先處理的，其他的事情很可能導致完成這件事情的周期被拉長。
定這么個計划，是為了時刻督促自己要堅持完成這個系列，不要半途而廢。
很多事情要做就做完，做一半還不如不做。
我個人比較欣慰的是，雖然中間因為假期暫停了將近10天，但假期一結束后，我立即接續完成了最后的幾篇文章。
收獲
這個系列帶給我的收獲主要有兩點：
- 寫文章是希望能教一些東西，寫文章的過程也是再思考再學習的過程，就像《暗時間》里所說的“教是最好的學”。
這個系列完成后，不僅可以分享一些知識，也使得自己對重構的認識又上升了一個台階。 - 本人的文字描述能力一直比較欠缺，特別是文字占了較大篇幅的文章，這樣的文章更考究作者的思路和邏輯。
通過這個系列自我感覺文字能力有所提升，在團隊的一些會議中，個人的現場描述能力也有所提升。
后續
關於重構這個系列並沒有完結，之后我會挑一些項目中實踐的代碼作為示例為大家解釋重構的過程。 接下來我還將寫幾個系列的文章，近期應該會寫JavaScript系列或ASP.NET MVC系列的，盡請期待。