別動不動拿 重構 說事

2021-04-13 01:07:48 字數 1209 閱讀 6212

自從martin fowler先生將refactoring這個概念帶到了中國,許多程式設計師都如同獲得了乙個通行金牌似的,隨時可能提起"bad **ell"和"重構"。

從我的心裡來講,我並不反對重構。但我反對不考慮專案情況的盲目重構。

回想一下,當我們在考慮系統需要重構的時候,我們都考慮了那些因素?特別是大範圍的系統級別的重構。由於小型重構涉及面較小,所以下面的很多原因都是針對大型重構進行論述的。

"bad **ell"也許是我們第乙個說出的原因。講起這個,我彷彿就聽到有無限個非常有道理的理由,能從重構者嘴裡說出。其中最經常的理由就是:現在不重構,以後也得重構,顯然現在重構的代價更小一點。

那麼,我們就因此而準備進行重構了嗎?

至少我看到很多專案最終都選擇了重構。

選擇重構的心理,應該和我們程式設計師的追求完美的個性非常相關。軟體不斷的進行重構,那麼軟體的質量就能越好。最關鍵的是,我們越來越將**修改得讓自己感覺沒有遺憾。請允許我這樣來分析重構者的心理,但是你不得不承認,往往決定一件事的時候,潛意識很容易戰勝理智。

我的問題是,我們重構的時候,真正理性而全面的考慮過嗎?

第一、重構的目標是什麼?是系統的完美嗎?是專案的順利完成!我想提出乙個大家不一定能夠接受的標準,任何系統都是可以也是必然存在足夠多的缺陷的。真正的成功,是指專案的成功,而並不是指創造乙個完美的系統。重構的需要,是專案開發過程中,根據需要而採用的開發方式。只要保障足夠程度的軟體架構,重構是可以不進行的。

第二、重構的基礎具備了嗎?在很多成功的經驗中,都明確地指出,重構需要有足夠的單元測試支援。而且最好是自動化的。目前,很多專案並不具備這樣的基礎。對於單元測試的問題,我在最近的幾篇關於單元測試的博文中也分析過現狀和原因。總體說來,真正具備重構的基礎的很少。

第三、重構對成本是否考慮周到。我們知道,重構必然會影響到現有專案的進度。這個進度的影響是否是可以接受的?你先不要忙著回答這個問題。能不能接受不是重構者說的,而是市場說的。這個時候,乙個三方的溝通會議必不可少。

第四、重構的策略是否制定。重構這件事,並不是簡簡單單地就去將所有需要重構的地方進行重構。重構的範圍越大,這個策略的需求就越高。過分樂觀地估計重構的過程,往往是重構失敗的重要原因之一。在對專案進行系統級別重構的時候,針對重構的範圍規劃,進度控制是非常必要的。這個不能要求重構者完全把控。本著適合的人做適合的事的原則,專案經理,應該充分考慮這方面的問題。

其實說到底,不要因為喜歡重構而重構,不要因為重構而重構。在重構之前以及重構的過程之中,我們都必須進行足夠的保障,才能保障成功地完成。 

別動不動拿 重構 說事

自從martin fowler先生將refactoring這個概念帶到了中國,許多程式設計師都如同獲得了乙個通行金牌似的,隨時可能提起 bad ell 和 重構 從我的心裡來講,我並不反對重構。但我反對不考慮專案情況的盲目重構。回想一下,當我們在考慮系統需要重構的時候,我們都考慮了那些因素?特別是大...

別動不動拿 重構 說事

自從martin fowler先生將refactoring這個概念帶到了中國,許多程式設計師都如同獲得了乙個通行金牌似的,隨時可能提起 bad smell 和 重構 從我的心裡來講,我並不反對重構。但我反對不考慮專案情況的盲目重構。回想一下,當我們在考慮系統需要重構的時候,我們都考慮了那些因素?特別...

別動不動拿 重構 說事

自從martin fowler先生將refactoring這個概念帶到了中國,許多程式設計師都如同獲得了乙個通行金牌似的,隨時可能提起 bad smell 和 重構 從我的心裡來講,我並不反對重構。但我反對不考慮專案情況的盲目重構。回想一下,當我們在考慮系統需要重構的時候,我們都考慮了那些因素?特別...