重構是一種對軟件進行修改的行爲,但它並不改變軟件的功能特徵,而是通過讓軟件程序更清晰,更簡潔和更條理來改進軟件的質量。代碼重構之於軟件,相當於結構修改之於散文。每次人們對如何對代碼進行重構的討論就像是討論如果對一篇文學作品進行修訂一樣無休無止。所有人都知道應該根據項目的自身情況來對代碼進行重構,而重構是無止境的。莫扎特從來不不對他的作品進行修訂,特羅洛普對自己作品修訂的恰到好處,大多數作家認爲他們倆這樣做都是合適的,但他們的合適對於你我來說未必是合適的。 最常見的基本重構方法可以歸納爲兩個方向。通過歸納方法將一個長的過程分解爲小的可以重用的組件,和通過內聯(inline)方法來消除那些不夠份量的小方法。我們可以提煉方法來讓大量的子類共享相同的功能特徵,我們可以下放方法來讓只有用到這些功能的子類才知道它們的存在。重構就是爬山,通過一步一步的小的提高來逐漸的改進整體的質量,但在重構時,我們如何知道哪種方法是上山的正確道路? 關於代碼地形學的這個問題公認的方法有兩種。去除有異味的代碼和重構成模式。如果能做到這樣,當然是很好的。就像是糾正作文裏的一個語法錯誤或不恰當的比喻。如果我們可以找到這些四處隱藏的有異味的代碼,將它們重寫成整潔的,條理的,結構化的形式,何樂而不爲。但這些都是特殊情況。如果沒有明顯的模式來重構,或沒有很直接的方法來去除代碼異味,那該怎麼辦呢? 這纔是我們如今編程藝術的中心問題,而很少人討論這些。通常我們討論這些問題時都是羅列出更多更長的有異味的代碼模式的清單,但這並不是解決問題的方法。代碼異味應該是我們公認的不好的東西,而不是那些置之不理也無妨的事情。我們經常會說到老闆不給我們重構的機會,甚至代碼有明顯的異味,老闆們認爲這是浪費時間。並不是每個人都有懂軟件的老闆。我很吃驚爲什麼只有很少的討論談到點子上。。也許我這篇文章才說到問題關鍵處。 我的觀點,當重構沒有現成的明顯的方向時,我們可以遵循下面的原則:
|
代碼重構方向原則指導
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.