C#項目維護到一定階段重構(gòu)是繞不開的話題。只要你還在寫業(yè)務(wù)代碼、還在接手別人的上位機項目就一定遇到過那種看三遍還不敢改的方法體變量名叫a1、b2一個方法兩百行里面還嵌套三層if。這正是那篇被轉(zhuǎn)了很多次的《C#重構(gòu)代碼的8種基本方法》想解決的問題——不是讓你去背一堆理論而是給你一套能直接落地的操作清單。我做C#開發(fā)這些年大大小小重構(gòu)過幾十個項目從工控上位機到Web服務(wù)都碰過今天就把這8種基本方法結(jié)合真實場景重新講一遍告訴你每種方法在什么時機用、怎么用、有哪些坑。這篇文章適合剛開始接觸重構(gòu)的新人也適合那些已經(jīng)在重構(gòu)但經(jīng)常把代碼越改越亂的開發(fā)者我會盡量把“為什么這么做”也講透。1. 重構(gòu)不是炫技先搞清楚要解決什么問題1.1 什么是重構(gòu)什么不是重構(gòu)很多人一提重構(gòu)腦子里浮現(xiàn)的是“推翻重寫”“換框架”“升級語法”。這不是重構(gòu)這是重寫。重構(gòu)的定義很樸素在不改變代碼外部行為的前提下改善內(nèi)部結(jié)構(gòu)。說人話就是——功能還是那個功能輸入輸出還是那個結(jié)果但代碼變得更容易讀、更容易改、更容易測。我在實際項目里見過太多把重構(gòu)和重寫搞混的情況。有一回同事覺得一個報表模塊太亂花了兩周“重構(gòu)”結(jié)果把數(shù)據(jù)源從DataSet換成了EntityFramework順帶改了數(shù)據(jù)庫表結(jié)構(gòu)最后整條業(yè)務(wù)鏈路崩了大半。那不是重構(gòu)那是重新發(fā)明了一套系統(tǒng)。真正的基本方法應(yīng)該像給房子做內(nèi)部改造承重墻不能動水管電線走向盡量不變改的是格局和收納。C#里也一樣接口的簽名盡量不動方法的行為盡量保持一致你改的是方法內(nèi)部的組織方式、類與類之間的協(xié)作關(guān)系、重復(fù)邏輯的收斂方式。1.2 重構(gòu)的前置條件測試保護網(wǎng)沒有測試就重構(gòu)等于沒有安全網(wǎng)就走鋼絲。C#項目里當然有那種歷史包袱特別重、壓根沒有單元測試的代碼但這不代表你不需要保護網(wǎng)至少你要先把“手工驗證清單”列出來。我的習慣是在重構(gòu)之前先做兩件事把核心流程跑一遍記錄關(guān)鍵輸入和輸出。給最危險的方法補幾個最小的單元測試不要求覆蓋全只要求能抓住行為變化。比如你面對一個計算電費的方法輸入用電量和峰谷時段輸出電費。你至少要用三個數(shù)據(jù)點把正常路徑、邊界路徑、異常路徑固定住。如果項目里連測試框架都沒建用控制臺寫個臨時驗證腳本也行關(guān)鍵在于重構(gòu)前后跑出來的結(jié)果必須一致。保護網(wǎng)的意義在于你改完代碼敢點“生成”失敗了能立刻知道是哪一步改壞了而不是對著滿屏報錯發(fā)懵。1.3 識別代碼壞味道的清單要使用8種基本方法你得先知道該用哪一種而判斷依據(jù)就是代碼里的“壞味道”。我總結(jié)了幾個最常見的信號方法太長超過30行或者你需要在滾動條里找結(jié)尾。重復(fù)代碼同一段邏輯復(fù)制粘貼了三處以上。過長參數(shù)列表一個方法有超過4個參數(shù)調(diào)用的人記不住順序。過度使用switch或if-else看到switch(type)里每個case都調(diào)不同的方法就該考慮多態(tài)了。類太大一個類做太多事比如既管數(shù)據(jù)訪問又管界面展示還管日志記錄。霰彈式修改改一個需求需要動五六個不相關(guān)地方的代碼。這些壞味道就是8種方法的觸發(fā)條件。你不需要把一本書讀完才動手只要聞到味找到對應(yīng)的方法去做就行。2. 8種基本方法逐個拆解2.1 提取方法Extract Method——最常用、最安全的重構(gòu)提取方法的意思是把一段獨立的邏輯從一個大方法里搬出去成為一個新的、有名字的方法。這是所有重構(gòu)方法里回報率最高的一種也最適合新手練習。為什么要提取因為人腦的工作記憶是有限的。一個方法里同時處理數(shù)據(jù)校驗、格式轉(zhuǎn)換、計算和日志輸出讀代碼的人需要同時記住四件事。提取之后每個方法只做一件事方法名就是注釋調(diào)用處讀起來像在朗讀業(yè)務(wù)步驟。比如你有一段判斷設(shè)備是否允許啟動的代碼if (device.Status DeviceStatus.Ready device.LastHeartbeat.AddMinutes(5) DateTime.Now _authService.CheckPermission(currentUser, device.Id)) { StartDevice(device); }這段邏輯有業(yè)務(wù)含義但被一堆技術(shù)細節(jié)蓋住了。提取出一個方法后if (CanStartDevice(currentUser, device)) { StartDevice(device); } private bool CanStartDevice(User user, Device device) { return device.Status DeviceStatus.Ready device.LastHeartbeat.AddMinutes(5) DateTime.Now _authService.CheckPermission(user, device.Id); }注意提取出來的方法名要能回答問題“這個方法到底在判斷什么”。CanStartDevice遠比CheckDeviceAndUser清晰。這是重構(gòu)里最容易上手的一步但也是最容易被忽略的一步因為很多人習慣了“直接往下寫”不愿意停下來給代碼起名字。實操時有兩個技巧一是提取出的方法體內(nèi)不應(yīng)使用臨時變量來傳值傳遞上下文盡量用參數(shù)或返回值二是提取后要立刻編譯運行確認行為沒變。如果提取過程中發(fā)現(xiàn)方法內(nèi)部用了外部變量要么把變量作為參數(shù)傳進去要么讓它成為返回值的一部分絕不能直接引用一個“碰巧在作用域里的變量”否則你會造出隱式耦合。2.2 引入解釋變量Introduce Explaining Variable——別再讓讀的人猜含義當你看到一個復(fù)雜的布爾表達式比如if (order.Total 1000 order.Customer.Level 3 order.CreatedDate DateTime.Today.AddDays(-30)) { // 給予VIP折扣 }這段表達式的每一個子句可能都有業(yè)務(wù)含義但它們?nèi)珨D在一起讀代碼的人必須先猜order.Total 1000是什么意思再看Customer.Level 3又是什么。不如拆開bool isLargeOrder order.Total 1000; bool isHighLevelCustomer order.Customer.Level 3; bool isRecentOrder order.CreatedDate DateTime.Today.AddDays(-30); if (isLargeOrder isHighLevelCustomer isRecentOrder) { // 給予VIP折扣 }這就是引入解釋變量。它的價值在于給一段“沒有名字的計算結(jié)果”起一個業(yè)務(wù)名字。很多人在第一次重構(gòu)時覺得這步多余但當你三個月后回來看代碼這三個變量名能直接告訴你當時的業(yè)務(wù)判斷依據(jù)。有一種情況你需要小心如果這個表達式會被多次使用比如在循環(huán)里或者多個if中被重復(fù)計算那么引入解釋變量不僅提高可讀性還避免重復(fù)求值。如果只在單個if塊里用一次我更推薦直接提取成方法因為方法可以被復(fù)用變量做不到。2.3 用多態(tài)替換條件表達式Replace Conditional with Polymorphism——消滅switch魔鬼這是8種方法里“面向?qū)ο蟆蔽兜雷钪氐囊粋€。當你看到switch或if-else根據(jù)某個類型做不同分支處理時意味著這個行為分散在了多個地方每增加一種新類型你就要打開這個開關(guān)再補一個case改著改著就漏了。比如你有一個計算不同設(shè)備數(shù)據(jù)解析的方法public object ParseDeviceData(string deviceType, byte[] rawData) { switch (deviceType) { case PLc: return ParsePlcData(rawData); case Dcs: return ParseDcsData(rawData); case Sensor: return ParseSensorData(rawData); default: throw new NotSupportedException(); } }假設(shè)設(shè)備類型的數(shù)量還會增長這段代碼就會不斷膨脹。換成多態(tài)的思路就是讓每種設(shè)備自己負責自己的解析邏輯public interface IDeviceParser { string DeviceType { get; } object Parse(byte[] rawData); } public class PlcParser : IDeviceParser { public string DeviceType PLc; public object Parse(byte[] rawData) /* PLC解析邏輯 */; } public class DcsParser : IDeviceParser { public string DeviceType Dcs; public object Parse(byte[] rawData) /* DCS解析邏輯 */; }然后你可以用一個工廠來收集所有IDeviceParser調(diào)用處直接parser.Parse(rawData)業(yè)務(wù)邏輯不再關(guān)心設(shè)備類型分支。這個重構(gòu)的收益在于“開閉原則”——新增設(shè)備類型時你只需要新增一個類不用回頭改判斷邏輯。代價是類數(shù)量變多結(jié)構(gòu)變復(fù)雜。所以我在實際項目中有一條自己的原則只有當分支超過兩個、且未來大概率會繼續(xù)擴展類型時才用多態(tài)。如果只有兩種類型且?guī)啄甓疾蛔僺witch反而更直接。過度設(shè)計往往是重構(gòu)最容易踩的坑之一8種基本方法教的不是“凡是switch都要干掉”而是“在合適的時機用合適的工具”。2.4 提取類與引入?yún)?shù)對象Extract Class Introduce Parameter Object——給臃腫類瘦身當一個類里包含了太多不相關(guān)的職責或者一個方法需要傳5個以上參數(shù)你需要考慮這兩個基本方法。先看提取類。比如你的DeviceService里既有設(shè)備通信邏輯、又有數(shù)據(jù)解析邏輯、還有配置文件讀寫邏輯。每次改通信要動這個類改解析也要動這個類兩邊并行開發(fā)時還會沖突不斷。這時候應(yīng)該拆成DeviceCommunication、DeviceDataParser、DeviceConfig三個類讓每個類的職責單一。拆類不是簡單的把代碼搬個家你要注意類與類之間的依賴關(guān)系。比如數(shù)據(jù)解析類需要通信類提供原始字節(jié)流那就讓解析器依賴通信接口而不是直接依賴通信類。一旦你發(fā)現(xiàn)拆完后出現(xiàn)了大量跨類私有成員的互訪說明拆分的邊界沒選對——兩個類仍然在共享內(nèi)部狀態(tài)。再看引入?yún)?shù)對象。如果一個方法有六個參數(shù)public void SaveDeviceRecord(string deviceId, string deviceName, DeviceType type, string location, bool enabled, int timeoutSeconds)調(diào)用處的可讀性和可維護性都很差。你可以定義一個DeviceRecord類把這些參數(shù)包起來public class DeviceRecord { public string DeviceId { get; set; } public string DeviceName { get; set; } public DeviceType Type { get; set; } public string Location { get; set; } public bool Enabled { get; set; } public int TimeoutSeconds { get; set; } } public void SaveDeviceRecord(DeviceRecord record)這個方法重構(gòu)還附帶一個好處當后面需要增加新字段比如增加“安裝日期”你不需要改動方法簽名只需要擴展DeviceRecord。調(diào)用方也不需要重新記參數(shù)順序更加不容易出錯。注意引入?yún)?shù)對象不是讓你無腦把所有參數(shù)都塞進一個類。如果某幾個參數(shù)在語義上根本沒有關(guān)聯(lián)強行包裝會讓代碼更別扭。我的經(jīng)驗是只有那些“經(jīng)常一起出現(xiàn)且共同描述一個概念”的參數(shù)才值得包裝比如設(shè)備信息、用戶信息、查詢條件都屬于這種概念聚合體。2.5 用委托和事件解耦Delegate Event——讓類與類不再死死綁住C#里的委托delegate和事件event是重構(gòu)中非常強大的工具可惜很多人只用來寫按鈕點擊。它們的核心用途是把“通知別人”的邏輯從“執(zhí)行自己”的邏輯中解耦出去。舉個典型的例子上位機里有一個數(shù)據(jù)采集服務(wù)采集到新數(shù)據(jù)后要同時更新界面、寫入數(shù)據(jù)庫、可能還要轉(zhuǎn)發(fā)給別的模塊。最容易寫出來的代碼是這樣的public void OnDataReceived(byte[] data) { _uiPanel.Update(data); _dbService.Save(data); _forwardService.Forward(data); }這樣寫的問題是DataAcquisitionService直接依賴了UiPanel、DbService、ForwardService。以后新增了一個“數(shù)據(jù)分析模塊”你不得不回來改DataAcquisitionService。改多了數(shù)據(jù)采集服務(wù)就變成了一個所有模塊的大雜燴中心。用事件重構(gòu)public class DataAcquisitionService { public event EventHandlerDataReceivedEventArgs DataReceived; public void OnDataReceived(byte[] data) { DataReceived?.Invoke(this, new DataReceivedEventArgs(data)); } }UI、數(shù)據(jù)庫、轉(zhuǎn)發(fā)服務(wù)各自注冊自己的事件處理器。數(shù)據(jù)采集服務(wù)完全不知道外面有誰在聽新增模塊時只需要在啟動配置里多一行訂閱代碼。這就是依賴倒置在重構(gòu)中的落地高層模塊不再依賴低層模塊而是雙方都依賴抽象事件。實際操作中要注意三點第一事件處理器拋出的異常會打斷后續(xù)訂閱者所以你的事件調(diào)用方法里要包一層try-catch別讓一個訂閱者的崩潰影響其它訂閱者第二如果反復(fù)訂閱同一個事件會造成事件處理器的重復(fù)調(diào)用尤其是使用匿名方法時你一定要在合適的位置取消訂閱第三事件不要隨便暴露給外部類操作盡量使用event關(guān)鍵字包裝委托這樣外部只能和-不能隨便觸發(fā)維護起來安全得多。2.6 泛型化消除重復(fù)集合邏輯Generic Refactoring——把“拷貝代碼”變成“復(fù)用邏輯”C#的泛型不是只有ListT和DictionaryTKey, TValue才叫泛型。你自己寫的數(shù)據(jù)處理邏輯如果只是類型不同、邏輯完全相同就應(yīng)該用泛型收斂。這是8種基本方法里很關(guān)鍵的一條尤其在后端開發(fā)、數(shù)據(jù)處理項目中價值巨大。假設(shè)你有兩段幾乎一樣的代碼一個處理Listint一個處理Liststringpublic int SumAll(Listint numbers) { int sum 0; foreach (var n in numbers) sum n; return sum; } public string ConcatAll(Liststring strings) { string result ; foreach (var s in strings) result s; return result; }雖然返回類型不同但“遍歷集合并逐一累加”這個骨架是重復(fù)的。用泛型加委托你可以抽取公共邏輯public T AggregateT(IEnumerableT source, T seed, FuncT, T, T func) { T result seed; foreach (var item in source) { result func(result, item); } return result; }調(diào)用時傳入具體累加函數(shù)就行。注意這個例子只是為了演示思路真正在C#里你直接用LINQ的Sum()、Aggregate()更省事但泛型化思維的本質(zhì)是一樣的把“類型無關(guān)的結(jié)構(gòu)”和“類型相關(guān)的邏輯”分離。泛型化重構(gòu)有一個隱性成本泛型約束一旦濫用或者使用不當會讓代碼變得非常抽象新人看不懂。我有一條經(jīng)驗至少有三處重復(fù)時才值得泛型化如果只有兩處重復(fù)且這兩處的邏輯差異并不只是類型那復(fù)制代碼反而更穩(wěn)。泛型化是為了消除“真正的重復(fù)”而不是消除“看起來相似”的重復(fù)。2.7 用異步重構(gòu)阻塞調(diào)用Async/Await Refactoring——把卡頓變成流暢在C#里做重構(gòu)絕對繞不開async/await。很多老代碼里用的是Thread.Sleep、.Result、.Wait()這些在UI線程里直接卡界面在服務(wù)端會浪費線程資源。異步重構(gòu)的基本方法就是把這些阻塞調(diào)用換成真正的異步調(diào)用。舉一個常見的例子。一個C#上位機程序從PLC讀數(shù)據(jù)老代碼可能寫成public bool ReadPlcData(string address, out int value) { Thread.Sleep(100); // 模擬IO等待 value 123; return true; }重構(gòu)后public async Task(bool Success, int Value) ReadPlcDataAsync(string address, CancellationToken ct default) { await Task.Delay(100, ct); // IO等待讓出線程 return (true, 123); }調(diào)用處也要跟著改從ReadPlcData(DB1, out var val)變成var result await ReadPlcDataAsync(DB1)。這次重構(gòu)不僅僅是把Sleep換成Delay而是改變了線程模型異步等待期間線程可以回去處理其它事情界面不再卡死服務(wù)端的并發(fā)能力也會提高。異步重構(gòu)有四個容易踩坑的地方避免async void除了事件處理器其它地方一律用async Task否則異常無法捕獲。不要阻塞異步不要用.Result或.Wait()去等異步方法否則可能死鎖。注意上下文在UI項目里await后會嘗試回到UI線程如果被.Result阻塞就會互相等待。取消支持長耗時操作要接受CancellationToken方便用戶中斷或程序退出。我見過太多“看起來改成異步、實際上還是卡死”的代碼往往就是把Thread.Sleep換成Task.Delay但外層調(diào)用用了.Result。重構(gòu)完一定要用并發(fā)壓力測一下別只看界面不卡就以為成功。2.8 簡化方法調(diào)用鏈Remove Middle Man Reorganize——去掉多余的中間人第8種基本方法針對的是另一種壞味道過度的委托轉(zhuǎn)調(diào)。面向?qū)ο笤O(shè)計里講究封裝但封裝過頭就會變成“中間人”——A調(diào)用B去調(diào)用C去調(diào)用D最后真的干活的是DB和C只是傳話的。這種代碼在加了多層架構(gòu)的企業(yè)級項目里非常常見。舉個例子public class UiController { private readonly BusinessService _service; public UiController(BusinessService service) _service service; public DeviceInfo GetDeviceInfo() _service.GetDeviceInfo(); } public class BusinessService { private readonly Repository _repository; public BusinessService(Repository repository) _repository repository; public DeviceInfo GetDeviceInfo() _repository.GetDeviceInfo(); }如果你UiController里的GetDeviceInfo()只做了一件事把調(diào)用轉(zhuǎn)發(fā)給BusinessService并且BusinessService的GetDeviceInfo()又只是轉(zhuǎn)發(fā)給Repository那這個中間層就沒有價值。重構(gòu)時要么直接讓UiController調(diào)用Repository要么在BusinessService里添加真正的業(yè)務(wù)邏輯否則就去掉它。實際操作中要分清楚“中間人”和“必要抽象”。我說一個判斷標準如果你刪掉這個中間層讓調(diào)用方直接和更底層協(xié)作你發(fā)現(xiàn)調(diào)用方需要知道太多底層細節(jié)那這個中間層就是必要抽象。反過來如果刪掉后調(diào)用方依舊很舒服那這個中間層就是純粹的中間人刪掉能降低理解成本。3. 實操從一個真實的C#上位機示例開始重構(gòu)說了這么多方法來看個完整的案例。我簡化一個從PLC采集數(shù)據(jù)并更新畫面顯示的上位機模塊這里有明顯的壞味道方法過長、switch分支、參數(shù)過長、阻塞調(diào)用、類職責混亂。我會演示如何用上面幾種方法逐步重構(gòu)并說明每一步的意圖。3.1 重構(gòu)前一段滿是壞味道的代碼public class DataService { private string _plcIp; private int _plcPort; public string UpdateAndGetData(string deviceType, string ip, int port, string address, int timeout) { _plcIp ip; _plcPort port; object rawData null; switch (deviceType) { case plc: rawData ReadFromPlc(address, timeout); break; case dcs: rawData ReadFromDcs(address, timeout); break; default: rawData null; break; } if (rawData ! null) { string value ParseValue(rawData, deviceType); Thread.Sleep(500); return value; } return N/A; } private object ReadFromPlc(string address, int timeout) { /* 省略 */ } private object ReadFromDcs(string address, int timeout) { /* 省略 */ } private string ParseValue(object rawData, string deviceType) { /* 省略 */ } }這塊代碼的問題是UpdateAndGetData方法混合了連接配置、設(shè)備路由、數(shù)據(jù)獲取、數(shù)據(jù)解析和顯示值格式化。方法名UpdateAndGetData讀起來也含混不清switch分支以后要擴展設(shè)備類型很麻煩Thread.Sleep(500)會卡住界面字段_plcIp和_plcPort被直接賦值這個類隱含了狀態(tài)多個方法調(diào)用時會互相干擾。3.2 第一步區(qū)分職責提取類先把“設(shè)備通信”和“業(yè)務(wù)處理”分開。我建立一個DeviceConnector類負責不同設(shè)備的讀取再讓DataService只負責編排。public interface IDeviceConnector { object Read(string address, int timeoutMs); } public class PlcConnector : IDeviceConnector { public object Read(string address, int timeoutMs) { /* PLC協(xié)議讀取 */ return new byte[] { 1, 2, 3 }; } } public class DcsConnector : IDeviceConnector { public object Read(string address, int timeoutMs) { /* DCS協(xié)議讀取 */ return new byte[] { 4, 5, 6 }; } }這樣switch就沒必要存在了用字典或者依賴注入來路由即可。3.3 第二步消除阻塞引入異步把讀取方法改成異步public interface IDeviceConnector { Taskobject ReadAsync(string address, int timeoutMs, CancellationToken ct default); } public class PlcConnector : IDeviceConnector { public async Taskobject ReadAsync(string address, int timeoutMs, CancellationToken ct default) { await Task.Delay(timeoutMs, ct); return new byte[] { 1, 2, 3 }; } }DataService里的Thread.Sleep(500)也一并移除改成在解析之后異步等待刷新或者干脆去掉等待直接返回結(jié)果。這里的思路是如果等待只是為了“讓數(shù)據(jù)穩(wěn)定”應(yīng)該用循環(huán)重試讀取來替代固定Sleep。3.4 第三步引入?yún)?shù)對象與解釋變量原來UpdateAndGetData的四個參數(shù)deviceType, ip, port, address其實描述的是“一次設(shè)備點讀取請求”完全可以包裝成DeviceReadRequestpublic class DeviceReadRequest { public string DeviceType { get; set; } public string Ip { get; set; } public int Port { get; set; } public string Address { get; set; } public int TimeoutMs { get; set; } }方法簽名變成public async Taskstring GetDisplayValueAsync(DeviceReadRequest request)在方法內(nèi)部把isDataAvailable、canResolveValue這樣的中間判斷用解釋變量命名讀起來就像在閱讀一條業(yè)務(wù)規(guī)則。經(jīng)過這三步重構(gòu)后的代碼結(jié)構(gòu)大致是這樣public async Taskstring GetDisplayValueAsync(DeviceReadRequest request) { IDeviceConnector connector _connectorFactory.Create(request.DeviceType); object rawData await connector.ReadAsync(request.Address, request.TimeoutMs); bool hasData rawData ! null; if (!hasData) return N/A; string value _valueFormatter.Format(rawData, request.DeviceType); return value; }每個方法都只做一件事擴展新設(shè)備只需新增連接器類調(diào)用界面不再卡頓方法參數(shù)也變清晰了。這就是8種基本方法組合在一起的效果。4. 重構(gòu)中的常見問題與排查技巧實錄4.1 行為不保持多個問題逐一排查重構(gòu)不改變行為但實踐中經(jīng)常出了詭異的問題。我遇到最多的場景是修改了字段的賦值時序老代碼在方法開頭臨時給_plcIp賦值重構(gòu)后你把它改成了局部變量但方法的后面某處還在用那個字段行為就會變。所以凡是看到“只在方法內(nèi)使用卻賦值給字段”的情況先檢查有沒有隱式依賴。switch順序變化影響默認分支重構(gòu)多態(tài)時路由工廠的創(chuàng)建順序變了可能導(dǎo)致某些設(shè)備類型落到了錯誤的分支上。排查方法是把工廠里的映射字典打出來核對一遍看看是否有重復(fù)Type。異步上下文變化從同步改異步后UI代碼的調(diào)用線程變了有些控件不能在非UI線程訪問。這時你要在重構(gòu)完成后啟動程序跑一遍所有界面刷新路徑發(fā)現(xiàn)問題后在await后調(diào)用Invoke或使用調(diào)度器別嫌麻煩。排查行為不一致時不要靠猜先對比重構(gòu)前后的輸入輸出。上線代碼前留一份手工測試用例腳本把所有關(guān)鍵業(yè)務(wù)路徑過一遍比事后加班定位快得多。4.2 性能倒退重構(gòu)后變慢怎么辦有些重構(gòu)會引入性能損耗比如濫用多態(tài)導(dǎo)致每一次調(diào)用都查字典或者異步操作頻繁創(chuàng)建任務(wù)對象。遇到性能問題先區(qū)分是“變慢在可接受范圍”還是“慢到無法容忍”。我認為絕大多數(shù)業(yè)務(wù)場景下可讀性優(yōu)先于極小性能損耗。一百次虛方法調(diào)用才損失幾微秒但代碼混亂帶來的維護成本是按小時計的。當然如果你在循環(huán)里反復(fù)解析大量數(shù)據(jù)那確實要考慮優(yōu)化。我的習慣是先用Stopwatch寫個微基準測試確認瓶頸再對熱點路徑做針對性優(yōu)化絕不為了“性能”放棄結(jié)構(gòu)。如果確實需要高性能可以考慮把運行時多態(tài)改為策略緩存用ConcurrentDictionary緩存設(shè)備連接器實例用ValueTask減少熱路徑上異步分配用SpanT減少字節(jié)數(shù)組復(fù)制。這些優(yōu)化手段應(yīng)該在重構(gòu)結(jié)構(gòu)穩(wěn)定后再做不要在結(jié)構(gòu)大調(diào)的同時疊優(yōu)化否則出問題很難定位。4.3 重構(gòu)到一半發(fā)現(xiàn)依賴太多如何處理很多時候你拆著拆著發(fā)現(xiàn)這個類依賴了十幾個其它類拆出來的類還得依賴它們。這說明初始設(shè)計就不合理或者原先的類承擔了不該承擔的職責。這時不要硬拆先把強依賴關(guān)系理清。我的做法是先用接口把所有外部依賴抽象出來再通過構(gòu)造函數(shù)注入。一旦依賴變成接口你可以為拆出來的新類提供“最小接口”只把需要的方法暴露出去。比如原來DeviceService同時依賴ILogger、IDatabase、IConfiguration、IMqttPublisher拆分成DeviceReader后它只需要IDeviceConnectorFactory和ILogger兩個依賴這樣你就能在新類構(gòu)造函數(shù)里只注入這兩個而不是一股腦全傳進去。依賴太多時的另一個常用手段是“分解接口”把一個大接口按語義拆成多個小接口然后各自實現(xiàn)。雖然拆完類數(shù)量變多但每個類的依賴面會變窄測試時mock對象也容易寫。4.4 關(guān)于利用工具與本地AI模型輔助重構(gòu)現(xiàn)在很多C#開發(fā)者提到用IDE自帶的重構(gòu)功能Visual Studio里就有“重命名”“提取方法”“提取接口”這些輔助操作?？旖萱I我經(jīng)常用CtrlR, CtrlM提取方法CtrlR, CtrlR重命名。這些工具能大幅減少手改造成的低級錯誤但它們只負責“機械重構(gòu)”不會替你做“如何拆類、如何選設(shè)計模式”的決策。最近熱詞里經(jīng)常出現(xiàn)“用本地AI模型重構(gòu)C#項目代碼”我實測下來AI模型可以幫你做的是分析一段代碼里有哪些壞味道、給出重構(gòu)建議、生成第一版重構(gòu)后的代碼草稿。尤其是處理超長方法時先讓AI幫你拆分再人工評審比自己硬啃要快很多。但你一定要保持警惕AI模型不理解你的業(yè)務(wù)上下文它生成的多態(tài)方案有時會把系統(tǒng)搞得更復(fù)雜。我的建議是把它當成一個隨時可調(diào)用的結(jié)對伙伴而不是決策者。使用本地模型時注意不要上傳敏感代碼盡量用私有化部署。C#項目代碼通常包含業(yè)務(wù)邏輯輕則違反保密要求重則導(dǎo)致安全風險。只把剝離過敏感信息的片段或者簡化后的示例發(fā)給模型既能得到建議又守住安全線。4.5 常見錯誤與正確做法對照常見錯誤問題后果正確做法重構(gòu)和重寫混淆風險不可控周期拉長堅持行為不改變小步提交沒有測試保護就開始重構(gòu)出現(xiàn)行為差異難以定位先補最小測試用例或手工基線提取方法時引入隱式依賴方法間的隱式耦合加深參數(shù)顯式傳入避免直接訪問外部變量濫用多態(tài)替換簡單switch結(jié)構(gòu)過度設(shè)計分支少于三處時保持switch異步重構(gòu)外層用.Result死鎖、線程池耗盡全鏈路使用async/await添加中間層來“隱藏依賴”調(diào)用鏈變長維護困難適度抽象區(qū)分必要中間層與純轉(zhuǎn)發(fā)這張表實際上是我每次Code Review時都會掃一遍的清單你可以在自己的項目里直接抄過去。5. 重構(gòu)后的一件事提交與回顧如果非要說一個重構(gòu)收尾技巧那就是小步提交。一次重構(gòu)別改太多東西最好一次重構(gòu)只對應(yīng)一個方法或一個類跑通測試就提交一次。這樣即使某個提交破壞了項目你也只需要回退這一小步而不是面對一個大倉庫無處下手。我在實際項目里有一個習慣重構(gòu)完成后會把當前分支的提交記錄按“行為保持型重構(gòu)”和“行為優(yōu)化型重構(gòu)”分類標記。前者如果出問題多半是我無意中改了行為后者則可能是預(yù)期中的性能或體驗變化。分類清晰之后后續(xù)回溯會輕松很多。另外提交信息一定要寫清楚“重構(gòu)了什么、為什么這個順序”。比如“提取DeviceConnector接口替代ReadFromPlc和ReadFromDcs的switch分支”下一周你再回來看能快速想起來當時決策的上下文。這比你寫著“重構(gòu)代碼”四個字要強百倍。8種基本方法里沒有哪一種能包治百病它們組合起來才能解決真實項目里錯綜復(fù)雜的壞味道。我在C#開發(fā)這些年最深刻的體會是重構(gòu)拼的不是誰用了更高深的技術(shù)而是誰能在改代碼之前想清楚“我要動哪一小塊、動了之后怎么知道沒改壞”。如果你能守著這兩條原則剩下的方法細節(jié)都會逐漸變成你的本能。