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