重構(gòu)代碼很危險-如何避免重構(gòu)帶來的危險

第第頁重構(gòu)代碼很危險:如何避免重構(gòu)帶來的危險重構(gòu)代碼很危險:如何避免重構(gòu)帶來的危險

發(fā)表于：2023-12-13來源：IT博客大學習：不詳點擊數(shù)：標簽：重構(gòu)

重構(gòu)代碼很危險:如何避免重構(gòu)帶來的危險?重構(gòu)代碼很危險，它會給測試工作增加巨大的負擔。除非你的程序需要重構(gòu)，一定不要輕易重構(gòu)代碼。我這里所說的并不是把一個for循環(huán)改成while循環(huán)，

重構(gòu)代碼很危險，它會給（測試）工作增加巨大的負擔。除非你的程序需要重構(gòu)，一定不要輕易重構(gòu)代碼。我這里所說的并不是把一個for循環(huán)改成while循環(huán)，或把一個StringBuffer改成StringBuilder，我說的是大動作，例如重寫一個方法，一個函數(shù)，甚至整個類或包。如果你缺乏對一個方法或一個類的了解，那你重構(gòu)它的條件就不充分。即使你有一個天才的計劃，你也需要和團隊一起設(shè)計其中重大的修改。

當屬于下列情況時，你不該重構(gòu)

對于你來說，它的邏輯看起來過于復雜，你沒有花時間去分析它。

你不理解為什么前任程序員要這樣編寫。

你著手的是一個很重要的系統(tǒng)，而且時間很緊。

你是團隊里的新成員，或新接觸這個項目，或這種語言。

當屬于下列情況時，你可以重構(gòu)

現(xiàn)有的代碼對它要實現(xiàn)的功能顯得過于復雜，并且你分析過它。

修改后的代碼遠比現(xiàn)存的代碼邏輯要清晰。

你有足夠的時間，人手，財力來支持對項目進行（回歸）測試。

現(xiàn)有的代碼陳舊無效率。

無人認領(lǐng)的，寫的很爛的代碼都屬于此類。

跟你的一位同事談?wù)搶@部分程序進行重構(gòu)的好處和存在的風險，你們兩個都贊成重構(gòu)。

如何降低重構(gòu)的風險

權(quán)衡一下對一段代碼進行重構(gòu)的利與弊，找出降低風險的方法。調(diào)試一段你經(jīng)過重構(gòu)但卻使產(chǎn)品崩潰的代碼，這對你來說將會是在這個行業(yè)中最有壓力的事情。

使用（自動化）的回歸測試，快速的驗證你的修改。這非常重要，如果沒有準備（自動化）測試，你應該在做任何修改前建好它。

盡量讓你的重構(gòu)處于很短的（開發(fā)）周期，產(chǎn)品更新發(fā)布周期也盡可能短。

把你重構(gòu)的代碼和其它程序隔離開，這樣能讓你更容易找到出問題的地方。

為你的重構(gòu)活動準備測試計劃，包括回歸測試，（功能測試），反向測試，負載測試，（性能）測試和用戶確認測試。

投入全部精力來研究其中的邏輯，不要分心做其它事情。

在需要的地方使用設(shè)計模式。不要為了設(shè)計模式而增加設(shè)計模式。設(shè)計模式應該用在合適的時間和合適地方。

小粒度重構(gòu)

當你在開封一個方法時，如果你發(fā)現(xiàn)其中有一部分可以改進，那你就該考慮它，改進它。整潔的代碼是我們需要的，因為寫的很爛的代碼我們到處可見。和你的同事討論它們，當有人要修改你的代碼時不要固守己見。重構(gòu)，然后回歸測試，然后才提交代碼。沒有人希望自己提交的代碼會弄垮系統(tǒng)。

下面是一些比較有深度的閱讀材料。

重構(gòu):改善既有代碼的設(shè)計

代碼整潔之道

WorkingEffectivelywithLegacyCode

程序員的職業(yè)素養(yǎng)

忍住你的欲望，不要試圖重構(gòu)你不理解的代碼。多問問題，努力能清楚他們?yōu)槭裁匆殉绦驅(qū)懗蛇@樣。也許他們有很好的理由。如果你找到一段很古老的代碼，很有可能它們是按照古老的方式寫的。每天都在新增的API