學習之路四十一丶簡論重構

四月份的最後一天，寫點心得，記錄一下。

這個月一直忙着開發一個基於Win32 API的程序，大量運用了句柄等不少API的知識。

尤爲隨着代碼量愈來愈大，邏輯愈來愈複雜，代碼的清晰，健壯，擴展性成了一個須要重視的問題，也就是要適時的重構了。

 

一丶重構的時機

　　上個星期在修改一塊重大邏輯的時候，須要修改不少代碼，當時我犯了一個錯誤，一開始想了一個思路，但一上來沒寫多少就開始想着重構代碼，目的是使其代碼清晰以及可擴展。

　　但是隨着時間的流失，不只沒有重構好，並且該改的邏輯也沒有改好，我很鬱悶，爲何會這樣呢？因而開始了沉思 - 重構的時機應該是何時？

　　重構的時機要把握的恰到好處，太早缺少代碼之間的連貫性，由於你代碼都沒有寫好，就想着開始重構了，那可很差；太晚代碼寫好了，邏輯也通了，可是改起來特別費力，是牽一髮而動全身，說不定還改出了更多問題呢，須要花更多的時間去修改代碼以及 fix bug。

　　因此重構的時機因人而異，因你的能力，因你的業務流程熟悉度，不過我選擇的時機是中間靠前一點。

　　由於這個時候你已經寫了將近一半的代碼，業務邏輯也已經實現了一半了，那麼是否出現代碼冗餘，閱讀性差，抽象程度差的問題，若是有的話就要想一想該怎麼重構了，若是沒有繼續往下寫，保持好狀態。

　　當快要接近完成的時候，再來看看之前的代碼，由於從如今的眼光看之前寫的，總會有新的想法，若是有，趕忙實施，寫出高質量代碼。

　　因此重構的時機要本身掌握好，其實有幾點能夠代表你須要重構：

　　1.冗餘，重複代碼太多；

　　2.邏輯層次不清晰，變量命名本身都搞不清楚了；

　　3.類，方法各個層次之間很混亂；

　　4.沒法進行有效的擴展；

　　5.健壯性太差

　　因此在遇到上面一些問題以後，就要思考須要用哪些重構技巧來改善代碼質量了，這個須要積累，加油。

 

二丶重構的一些技巧

　　這裏就寫一些我重構用的方法：

　　1.去重，提取共用方法

　　　　記得寫過一個去除重複的try-catch的代碼，用到了委託以及反射來減小重複代碼

　　2.抽象

　　　　接口，繼承，虛方法，抽象類。

　　　　其實最重要的是你要深入理解你的業務，而且抽取他們共同的部分，以及經過虛方法來實現一個方法的不一樣操做

　　3.抽象工廠

　　　　抽象工廠又能夠分爲：單例工廠和多實例工廠

　　4.配置文件

　　　　自定義配置文件，能夠更有效的控制不一樣方式作不一樣的事

　　5.靈活運用Attribute

　　6.取更有意義的變量，屬性，方法，類的名稱，長一點沒有什麼大礙

　　7.反射

　　好了，就這些，還有不少沒學習了，繼續加油......

 

以同步至：我的文章目錄索引