C#常見問題

讀50行程式碼還是使用方法提取重構？- 來自Derek Comartin的見解

Derek Comartin

9m 16s

在軟體開發的世界中，重構是必不可少的。其中一種最常見且受推崇的技術是擷取方法重構——將大型程式碼片段分解為較小的、可重用的方法以提高可讀性和可重用性。雖然理論上聽起來很理想，但Derek Comartin在他的视频《我寧願讀50行而不是擷取方法重構》中提供了一個新鮮而批判性的觀點。

本文將帶您了解Derek對擷取方法重構的分解，提供現實世界的背景和實用建議。我們將遵循他的準確推理和程式碼結構，當他引導我們何時以及如何應用提取重構時，還會詳細說明其實施細節和潜在缺點。

在影片一開始，Derek展示了一個範例：聊天室系統的註冊功能。這是一個大約50行的緊湊而現實的程式碼塊，其執行多項任務：

這段程式碼存在於一個函式中，乍看之下，它似乎是擷取方法重構的理想候選。但正如Derek所警告的，盲目重構而不了解影響可能會降低清晰度。

Derek從許多開發者開始的地方開始——將程式碼片段分解成較小的部分。他展示了如何在大多數IDE或程式碼編輯器中，通過上下文選單或鍵盤快捷鍵選擇擷取方法。

他提取出：

他為每個新函式賦予有意義的名稱，這是乾淨程式碼實踐中經常提升的頂尖提示之一。但正當他介紹這些修改版本時，Derek開始指出邏輯中的裂痕——不是在功能上，而是在可讀性和控制流程上。

Derek強調的第一個紅旗是實施細節現在隱藏在擷取出的方法後面。

例如，validateUsername和validateExistingUser方法實際上會拋出異常。但作為讀取重構程式碼的開發人員，您除非存取其內部，否則不會知道這一點。

這種重構會隱藏控制邏輯，導致錯誤或漏掉的驗證。範圍和流程不再明顯。與其說讓程式碼更清晰，您建立了一個抽象的迷宮，像異常或變數修改這樣的副作用在最初編寫邏輯的形式中不再可見。

接下來，Derek指出間接的問題——當一個擷取方法調用另一個，依此類推。他展示了validateExistingUser方法本身由existingSignUpNotActivated組成。

您不再從上到下閱讀一個簡單的程式碼塊。您正在方法、文件和類之間來回跳轉，只為了追蹤發生了什麼。儘管編輯器可能幫助導航這個流程，但這增加了讀者的認知負荷。

這在涉及多個文件或組件的更大系統中變得更加痛苦。突然間，您的"乾淨程式碼"看起來比原來的"雜亂"50行更加難以追踪。

此影片中最重要的課程之一來自處理局部變數和狀態突變。

Derek強調了filterAgeRestrictedChannels方法。它並不返回結果——它直接改變傳入的channels列表。這意味著您正在從不同的方法中修改局部狀態，除非您仔細檢查方法，否則此更改是隱藏的。

這打破了函式要麼是純操作，要麼明確指明正在改變的預期。當您用一個不返回值但在內部更改它們的新方法替換邏輯時，您引入了風險和混亂。

那麼Derek實際上如何重構舊程式碼的呢？

他提出了一個更簡單的方法：

保持自解釋的邏輯內嵌。最初的空使用者名檢查保持在主方法中，因為它容易理解且不會佔用程式碼庫。
返回結果而不是突變。與其更改channels列表，filterAgeAppropriateChannels函式現在返回過濾後的列表。這讓資料流變得清晰，並防止意外的副作用。
使用簡單、可預測的擷取方法。唯一另一個提取的方法是isExistingUserAlreadyActivated，它明確返回一個布林值，沒有拋出異常。它封裝邏輯而不隱藏細節。
避免內嵌副作用如發送郵件。 Derek為示範保留郵件邏輯，但建議在真正的系統中，這應通過在單獨的流程或執行緒中處理的事件來處理——而不是直接綁定到使用者表單提交。

總之，Derek僅使用兩個提取方法，並將其餘邏輯保留在內嵌——因為這更容易閱讀、推理和控制。