做C這些年我越來越覺得真正勸退大家的不是語法坑也不是內(nèi)存問題而是藏在代碼結(jié)構(gòu)里的“壞味道”。最近在清理一個遺留的交易系統(tǒng)模塊不大才一萬多行但每次改需求都像拆炸彈——牽一發(fā)動全身。我慢慢意識到C代碼復(fù)雜性分析這件事不是寫幾篇文檔就能糊弄過去的它得用數(shù)據(jù)說話用工具落地用重構(gòu)行動去壓。這篇博文我就用自己的實操經(jīng)驗把為什么代碼會變復(fù)雜、怎么量化復(fù)雜度、怎么用工具體檢、以及怎么一步步把復(fù)雜度降下來講清楚。1. 為什么C代碼的復(fù)雜性值得單獨深挖1.1 C的“自由度陷阱”特性越多失控風(fēng)險越大C是一門給了開發(fā)者極大自由的語言。從經(jīng)典的三大件——類繼承、運(yùn)算符重載、模板——到現(xiàn)代C引入的RAII、移動語義、lambda、concept每一項特性都是好工具但每一項也都能成為復(fù)雜度放大器。同樣是寫一個配置解析有人用簡單的std::ifstream加字符串處理一百行內(nèi)解決有人會疊上模板元編程、可變參數(shù)、類型擦除硬生生把解析器寫成一個“小型編譯器”。代碼都能跑看起來都很“C”但后者的維護(hù)成本是前者的十倍不止。我見過太多生產(chǎn)代碼問題不在底層邏輯而在于開發(fā)者“敢于使用一切特性”的習(xí)慣。類繼承能抽象出七八層運(yùn)算符重載能讓obj1 obj2變成一個網(wǎng)絡(luò)包發(fā)送模板工具類嵌套得像俄羅斯套娃。這些代碼在寫的那一刻確實聰明三個月后再讀連作者自己都要翻半天的上下文。C的工程復(fù)雜性往往不是業(yè)務(wù)復(fù)雜度帶來的而是這些語言自由度堆出來的。1.2 技術(shù)債的正反饋越復(fù)雜越不敢改越不敢改越復(fù)雜有人可能會說代碼復(fù)雜就復(fù)雜唄能用就行。這個想法在項目初期問題不大但一旦代碼進(jìn)入維護(hù)期復(fù)雜性會形成一個惡性循環(huán)。比如你負(fù)責(zé)一個模塊里面某個核心函數(shù)的圈復(fù)雜度高達(dá)50邏輯盤根錯節(jié)函數(shù)簽名還帶著四個輸出參數(shù)。新需求來了改吧怕改壞老功能不改吧新功能沒地方塞。最后只能在外面再包一層判斷把原來就亂的分支變得更加不可預(yù)測。這個循環(huán)一旦形成對團(tuán)隊的打擊是全方位的。新人看代碼無從下手老人改代碼心驚膽戰(zhàn)Code Review也只能停留在“能編譯、能跑”的層面根本沒人敢深入優(yōu)化結(jié)構(gòu)。長期下來模塊就像一座慢慢腐爛的危樓看著還能住人可誰也不敢大動。這也解釋了為什么C項目里經(jīng)常出現(xiàn)“誰寫的代碼誰自己最清楚、別人一概不敢碰”的現(xiàn)象。C代碼復(fù)雜性分析存在的意義就是打破這個循環(huán)用客觀數(shù)據(jù)把問題擺到臺面上逼著大家正面處理。2. 復(fù)雜度指標(biāo)先量化再談優(yōu)化2.1 圈復(fù)雜度最常用的入門指標(biāo)圈復(fù)雜度Cyclomatic Complexity是McCabe在1976年提出的度量核心思想是統(tǒng)計代碼中線性無關(guān)路徑的數(shù)量。簡單說就是看一個函數(shù)里有多少個獨立的執(zhí)行路徑路徑越多測試用例要覆蓋的情況越多邏輯越復(fù)雜越容易出Bug。計算規(guī)則其實很樸素圈復(fù)雜度 決策點數(shù)量 1。這里的決策點包括if、else if、for、while、do-while、switch的每個case、catch以及三元運(yùn)算符?:和、||。來看一段實際代碼我建議你自己也拿這段去跑跑看int handle_request(Request req) { int result 0; if (req.type TYPE_A) { // 決策點 1 if (req.state STATE_READY) { // 決策點 2 result process_a(req); } else if (req.state STATE_BUSY) { // 決策點 3 result -EBUSY; } else { result -EINVAL; } } else if (req.type TYPE_B) { // 決策點 4 for (auto item : req.items) { // 決策點 5 if (item.valid()) { // 決策點 6 result item.value; if (result LIMIT) { // 決策點 7 result LIMIT; break; } } } } return result; }按McCabe的標(biāo)準(zhǔn)數(shù)一數(shù)最外層兩個if/else if算2個內(nèi)層if/else if算2個for算1個item.valid()和result LIMIT各算1個一共7個決策點。圈復(fù)雜度就是718。8意味著什么按業(yè)界常見的參考閾值15以上算高風(fēng)險10~15算中等風(fēng)險而8已經(jīng)逼近“需要拆解”的邊界了。這個函數(shù)不到30行圈復(fù)雜度就到了8說明里面分支的密度相當(dāng)高。2.2 認(rèn)知復(fù)雜度比圈復(fù)雜度更貼近“人”圈復(fù)雜度有一個讓很多開發(fā)者不滿的地方它按“決策點”計數(shù)但沒有懲罰嵌套的深度。一個函數(shù)有5個連續(xù)的if和5個層層嵌套的if圈復(fù)雜度都是5可人腦閱讀后者的負(fù)擔(dān)要重得多。為了彌補(bǔ)這個缺陷SonarQube提出了另一個指標(biāo)——認(rèn)知復(fù)雜度Cognitive Complexity。認(rèn)知復(fù)雜度強(qiáng)調(diào)“人閱讀代碼時的理解成本”每多一層嵌套額外的權(quán)重就會增加else if、三元運(yùn)算符、和||這類邏輯連接符也會按規(guī)則疊加分?jǐn)?shù)。所以兩段圈復(fù)雜度相同的代碼認(rèn)知復(fù)雜度可能差出好幾倍認(rèn)知復(fù)雜度越高的代碼同事review起來越容易崩潰。我實踐中的一個感受是圈復(fù)雜度你想控制到15以下其實不算難難的是讓認(rèn)知復(fù)雜度也掉下來。真正啃不動的舊代碼往往是嵌套特別深、邏輯特別繞的那種。這就是為什么我建議團(tuán)隊在做復(fù)雜度分析時兩個指標(biāo)一起看不要只盯一個。2.3 規(guī)模、耦合與其他輔助指標(biāo)除了復(fù)雜度還有一些輔助指標(biāo)能幫我們判斷代碼的“體型”是否健康。我平時最少會看三個維度的數(shù)據(jù)代碼規(guī)模單個文件行數(shù)、單個函數(shù)行數(shù)。一般來說函數(shù)超過100行就需要打一個問號超過200行基本就是重構(gòu)候選。參數(shù)數(shù)量函數(shù)參數(shù)超過4個就該考慮是否需要用結(jié)構(gòu)體/類來聚合參數(shù)了。C里的參數(shù)列表長往往也意味著調(diào)用方要背很多隱含約束。耦合程度看一個類對外部類型的依賴數(shù)量可以用扇入和扇出粗略衡量。某個類的頭文件里塞了幾十個其他類的#include它的可測試性通常很差。另外一個經(jīng)典度量是Halstead復(fù)雜度它通過統(tǒng)計程序里的操作符和操作數(shù)個數(shù)估算“程序詞匯量”“程序長度”“工作量”等指標(biāo)。說實話Halstead在C這種語言里顯得有點笨重因為它會把模板實例、lambda一起算進(jìn)去數(shù)據(jù)噪音很大。我更愿意把它當(dāng)作一個背景參考而不是核心決策依據(jù)。3. 實戰(zhàn)如何用工具給C工程做一次代碼體檢3.1 工具選型Lizard、clang-tidy、SonarQube怎么配合聊完指標(biāo)進(jìn)入實戰(zhàn)。我給C工程做“體檢”時常用的工具組合是這樣的先上Lizard快速摸底再用clang-tidy對重點文件做交叉檢查有條件的話在CI里掛SonarQube做長期跟蹤。先說Lizard。這是一個用Python寫的輕量級代碼復(fù)雜度分析工具支持C/C、Java、Python等十幾種語言不需要編譯你的工程就能掃描。它最實用的地方是能在幾秒內(nèi)跑完一個大型工程直接輸出每個文件的NLOC代碼行數(shù)、每個函數(shù)的圈復(fù)雜度等指標(biāo)還能按復(fù)雜度排序幫你快速鎖定熱點。缺點是它對C的理解停留在詞法層面遇到復(fù)雜的模板、宏展開會有些失真但作為排查工具足夠用了。clang-tidy則更“懂”C。它基于Clang的AST來做分析可以結(jié)合編譯數(shù)據(jù)庫對代碼進(jìn)行精確的語法制導(dǎo)掃描。clang-tidy里有一些和復(fù)雜度相關(guān)的檢查項比如readability-function-size可以配置函數(shù)行數(shù)、參數(shù)數(shù)量、語句數(shù)量上限。它還能給出重構(gòu)建議甚至用--fix自動改一些簡單問題。缺點是速度比Lizard慢不少而且必須先生成compile_commands.json編譯數(shù)據(jù)庫配置成本高一些。SonarQube適合團(tuán)隊長期用。它能收集歷史趨勢和CI結(jié)合把復(fù)雜度紅線變成“門禁”機(jī)制。缺點也很明顯——部署和運(yùn)維成本高對個人項目來說有點殺雞用牛刀。我的建議是個人項目用Lizard就夠了公司級項目再考慮上SonarQube。3.2 用Lizard掃描并定位熱點Lizard的安裝和上手都極其簡單一條命令的事pip install lizard然后直接對源碼目錄跑lizard src/ -l cpp --csv加上--csv是為了拿到結(jié)構(gòu)化輸出方便用Excel或腳本進(jìn)一步分析。如果你只想快速看一眼結(jié)果可以不加CSV默認(rèn)終端表格更直觀。我拿一個真實項目跑過之后輸出大概是這個感覺——不同版本字段略有差異但關(guān)鍵列就是下面這幾個NLOC Avg.NLOC AvgCC Avg.token Function ------------------------------------------------ 123 45 18.4 1294 parse_configsrc/config.cpp 89 30 14.7 1120 handle_messagesrc/network.cpp 67 22 11.2 541 apply_settingsrc/config.cppNLOC表示函數(shù)凈代碼行數(shù)AvgCC就是圈復(fù)雜度。看到parse_config的圈復(fù)雜度到了18我的反應(yīng)通常是兩種要么這個函數(shù)真的邏輯復(fù)雜要么它能把簡單的邏輯表達(dá)得很復(fù)雜。不管是哪種該拆了。實際操作中我一般還會加一個過濾參數(shù)只關(guān)注復(fù)雜度超過閾值的函數(shù)lizard src/ -l cpp -C 15 -w-C 15表示只列出圈復(fù)雜度大于15的函數(shù)-w會忽略警告級別的誤報。這樣幾分鐘之內(nèi)整個工程里最“危險”的幾十個函數(shù)就都被撈出來了。3.3 用clang-tidy對高復(fù)雜度文件做交叉檢查Lizard把熱點撈出來后第二步是用clang-tidy對熱點文件做精確檢查。前提是先讓CMake導(dǎo)出編譯數(shù)據(jù)庫cmake -B build -DCMAKE_EXPORT_COMPILE_COMMANDSON編譯數(shù)據(jù)庫生成后在build/compile_commands.json里就能看到每個源文件的編譯命令。然后對目標(biāo)文件跑clang-tidyclang-tidy -p build/ src/config.cpp \ -checks-*,readability-function-size這個命令的意思是把所有默認(rèn)檢查關(guān)掉-*只開啟readability-function-size。你還可以通過--config-file自定義閾值比如把函數(shù)超過60行就報警clang-tidy -p build/ src/config.cpp \ -checks-*,readability-function-size \ --config{CheckOptions: [{key: readability-function-size.LineThreshold, value: 60}]}clang-tidy的好處是它能從AST層面告訴我哪些變量未使用、哪些構(gòu)造函數(shù)可以explicit、哪些函數(shù)可以const這些信息結(jié)合Lizard給出的復(fù)雜度數(shù)據(jù)能讓我在重構(gòu)前把文件里所有潛在問題都過一遍。兩個工具一快一慢、一粗一細(xì)配合起來效率很高。3.4 匯總問題清單排出重構(gòu)優(yōu)先級掃描不是目的目的是生成一份能指導(dǎo)行動的問題清單。我通常會把數(shù)據(jù)整理成下面這種表格按評估結(jié)果排序文件 / 函數(shù)圈復(fù)雜度認(rèn)知復(fù)雜度行數(shù)評估結(jié)果建議動作config.cpp / parse_config1824123高風(fēng)險立即拆解優(yōu)先處理network.cpp / handle_message141989中高風(fēng)險下一輪拆解dbwrapper.cpp / write_batch8645可控暫時不動觀察utils.cpp / trim218健康無需處理判斷優(yōu)先級我有一條很樸素的原則先拆“高頻改動高復(fù)雜度”的代碼再碰“低頻改動但高復(fù)雜度”的代碼。前者直接切斷技術(shù)債的增長源頭后者屬于歷史遺留可以放到重構(gòu)窗口期慢慢處理。像trim這種圈復(fù)雜度只有2的函數(shù)就算寫得再丑也沒有必要動它冒險重構(gòu)的收益接近零。4. 降低復(fù)雜度的重構(gòu)策略從最容易見效的開始4.1 拆函數(shù)、砍嵌套成本最低收益最明顯的動作復(fù)雜度數(shù)據(jù)出來后第一刀應(yīng)該砍向哪我強(qiáng)烈建議先從拆大函數(shù)、消滅深層嵌套開始。這個動作技術(shù)門檻最低出錯概率最小而且效果立竿見影。最常見的兩個招式是“衛(wèi)語句提前返回”和“提取子函數(shù)”。舉一個我實際處理過的例子。有一段配置解析代碼原版長這樣——縮進(jìn)一層疊一層每個分支都往里鉆int parse_config(const std::string path, Config cfg) { int status 0; FILE* fp fopen(path.c_str(), r); if (fp) { char line[256]; while (fgets(line, sizeof(line), fp)) { std::string s(line); trim(s); if (!s.empty() s[0] ! #) { auto eq s.find(); if (eq ! std::string::npos) { std::string key s.substr(0, eq); std::string value s.substr(eq 1); if (key timeout) { cfg.timeout std::stoi(value); } else if (key retries) { cfg.retries std::stoi(value); } else if (key debug) { cfg.debug (value 1 || value true); } else { status WARN_UNKNOWN_KEY; } } } else { continue; } } fclose(fp); } else { status ERR_OPEN_FAILED; } return status; }這段代碼邏輯本身不算深但嵌套層次一眼望過去就讓人煩躁。重構(gòu)之后我把它拆成四個小函數(shù)每個函數(shù)只做一件事bool is_blank_or_comment(const std::string s) { return s.empty() || s[0] #; } bool parse_key_value(const std::string s, std::string key, std::string value) { auto eq s.find(); if (eq std::string::npos) return false; key s.substr(0, eq); value s.substr(eq 1); return true; } int apply_setting(const std::string key, const std::string value, Config cfg) { if (key timeout) { cfg.timeout std::stoi(value); } else if (key retries) { cfg.retries std::stoi(value); } else if (key debug) { cfg.debug is_truthy(value); } else { return WARN_UNKNOWN_KEY; } return 0; } int parse_config(const std::string path, Config cfg) { FILE* fp fopen(path.c_str(), r); if (!fp) return ERR_OPEN_FAILED; int status 0; char line[256]; while (fgets(line, sizeof(line), fp)) { std::string s(line); trim(s); if (is_blank_or_comment(s)) continue; std::string key, value; if (!parse_key_value(s, key, value)) { status WARN_INVALID_LINE; continue; } int rc apply_setting(key, value, cfg); if (rc ! 0 status 0) status rc; } fclose(fp); return status; }重構(gòu)后的效果非常明顯parse_config本身的圈復(fù)雜度從原來的十幾降到了4左右apply_setting的圈復(fù)雜度也只有5而且每個函數(shù)看名字就能猜出職責(zé)。最關(guān)鍵的是以后想加一個max_connections配置項只需要改apply_setting一個函數(shù)不再需要在主解析函數(shù)里上下求索。4.2 用狀態(tài)機(jī)把“開關(guān)地獄”理清楚另一種典型的復(fù)雜度聚集地是那種“根據(jù)狀態(tài)和事件做分支”的代碼。最原始的寫法是if (state A event X) ... else if (...) ...寫到最后可能出現(xiàn)幾十個分支。這種場景下我建議把邏輯轉(zhuǎn)成有限狀態(tài)機(jī)尤其是狀態(tài)和事件都相對固定的時候。舉個報文處理的例子。模塊要處理四種狀態(tài)、四種事件如果用嵌套if處理狀態(tài)一變就要在好幾個地方同步改漏改一個就會出線上事故。我改成一張規(guī)則表enum class State { kIdle, kRunning, kFaulted, kStopped }; enum class Event { kStart, kPause, kError, kReset, kStop }; using Handler std::functionvoid(const Message); struct TransitionRule { State from; Event event; State to; Handler handler; }; const std::vectorTransitionRule kRules { {State::kIdle, Event::kStart, State::kRunning, handle_start}, {State::kRunning, Event::kPause, State::kIdle, handle_pause}, {State::kRunning, Event::kError, State::kFaulted, handle_error}, {State::kFaulted, Event::kReset, State::kIdle, handle_reset}, {State::kIdle, Event::kStop, State::kStopped, handle_stop}, {State::kRunning, Event::kStop, State::kStopped, handle_stop}, }; State next_state(State current, Event evt, const Message msg) { for (const auto rule : kRules) { if (rule.from current rule.event evt) { if (rule.handler) rule.handler(msg); return rule.to; } } return current; }這段代碼圈復(fù)雜度幾乎恒定為1因為整個循環(huán)里只存在一次if邏輯全部被數(shù)據(jù)表承載了。以后要新增一個狀態(tài)本質(zhì)上是往表里加一行不用再到處找case和else if。需要提醒一句狀態(tài)機(jī)不是萬能藥。如果狀態(tài)數(shù)量不大、變化不頻繁硬塞一個規(guī)則表反而是過度設(shè)計判斷標(biāo)準(zhǔn)很簡單——當(dāng)新增一個狀態(tài)或事件需要改動超過兩個地方時才考慮換狀態(tài)機(jī)。4.3 簡化依賴接口隔離和依賴注入復(fù)雜度不只來自函數(shù)內(nèi)部還來自類型之間的依賴糾纏。C里最常見的壞味道是“一個類什么都自己來”。在業(yè)務(wù)代碼里我看到過太多直接在構(gòu)造函數(shù)里new具體依賴的實現(xiàn)比如下面的寫法class PaymentService { public: PaymentService() : gateway_(new CreditCardGateway()) {} // 寫死具體實現(xiàn) void pay(double amount) { gateway_-charge(amount); } private: CreditCardGateway* gateway_; };這段代碼在單測時很痛苦因為CreditCardGateway沒法替換成樁。一旦業(yè)務(wù)要求支持更多支付渠道PaymentService內(nèi)部就要塞一堆if (type ...) new ...圈復(fù)雜度和參數(shù)數(shù)量都會蹭蹭上漲。改成接口注入之后依賴關(guān)系清晰了不少class PaymentGateway { public: virtual ~PaymentGateway() default; virtual void charge(double amount) 0; }; class PaymentService { public: explicit PaymentService(std::unique_ptrPaymentGateway gateway) : gateway_(std::move(gateway)) {} void pay(double amount) { gateway_-charge(amount); } private: std::unique_ptrPaymentGateway gateway_; };PaymentService不再關(guān)心具體網(wǎng)關(guān)的構(gòu)造邏輯測試時可以輕松注入一個MockGateway。不過這里要非常謹(jǐn)慎接口抽象是把雙刃劍。我見過有的團(tuán)隊為了“解耦”每個類都抽一個接口結(jié)果接口數(shù)量翻了四倍代碼跳轉(zhuǎn)路徑長了三倍閱讀起來反而更累。接口隔離的核心目標(biāo)是“把變化點封裝起來”而不是“讓所有類都實現(xiàn)接口”。一個沒有第二實現(xiàn)方的接口大概率是過度設(shè)計的產(chǎn)物。4.4 模板復(fù)雜度限制別讓自己的模板變成新一門語言C的模板是把雙刃劍這個說法大家耳朵都聽出繭了。但落到復(fù)雜度分析上模板導(dǎo)致的坑往往比普通業(yè)務(wù)代碼更隱蔽——工具算不出圈復(fù)雜度可編譯器會告訴你編譯時間翻了十倍、二進(jìn)制體積膨脹三倍。我接手過一個內(nèi)部序列化庫作者為了“通用”把類型、字節(jié)序、壓縮算法全部做成了模板參數(shù)調(diào)用的時候要寫一長串SerializeBinaryCodec, LZ4Compressor, LittleEndian。抽象能力確實強(qiáng)但每次模板實例化失敗編譯器輸出的幾百行錯誤信息能把人看瞎。我的經(jīng)驗是模板代碼必須設(shè)定“復(fù)雜度紅線”模板參數(shù)超過2個的必須有詳細(xì)的文檔說明模板函數(shù)超過50行的先想想是不是真的需要泛化嵌套模板別名using X YZT超過兩層基本該拆了。現(xiàn)代C里很多模板替代品已經(jīng)很好用比如concept約束、std::variant替代部分“多類型重載”的場景、auto參數(shù)簡化泛型lambda。能用這些更易讀的機(jī)制就沒必要硬堆元編程。說到底模板是為了讓調(diào)用方更簡潔而不是為了讓你展示語言功底。5. 常見問題與排查技巧實錄5.1 工具誤報宏、回調(diào)、重構(gòu)邊界用工具做代碼體檢最怕的一件事就是工具掃描出來的“高復(fù)雜度”其實名不副實。我在工程里遇到最多的情況是宏定義把復(fù)雜度藏起來了。比如這個經(jīng)典宏#define CHECK_RETURN(expr) \ do { int rc_ (expr); if (rc_ ! 0) return rc_; } while (0)Lizard在掃描時會直接展開宏調(diào)用的結(jié)果導(dǎo)致一個使用大量CHECK_RETURN的函數(shù)圈復(fù)雜度虛高?？蓪嶋H上這些宏代表的是統(tǒng)一的錯誤處理模式邏輯并不復(fù)雜。遇到這種情況我的做法是把宏納入白名單或者直接在結(jié)果里把這類函數(shù)標(biāo)記為“已知合理項”不參與排名。另一個常見誤報來自回調(diào)函數(shù)。在C里函數(shù)指針、std::function、虛函數(shù)調(diào)用都會增加代碼的“間接層”Lizard這類詞法分析工具往往會把這些間接層當(dāng)作普通分支算進(jìn)去。這里我強(qiáng)調(diào)的是復(fù)雜度指標(biāo)是向?qū)Р皇桥袥Q書工具報告里數(shù)字高只能說明“該看一眼了”不能說一定是壞代碼。我一般要求團(tuán)隊成員用“人的判斷”去復(fù)核工具的結(jié)論如果這個函數(shù)讀起來邏輯清晰、測試也好寫那數(shù)字高一點無妨如果讀起來就暈?zāi)菙?shù)字低也值得重構(gòu)。5.2 舊代碼重構(gòu)先織“測試安全網(wǎng)”再動手給老項目做復(fù)雜度治理最忌諱的是“操起鍵盤就拆”。C代碼的隱性耦合太強(qiáng)了一個看似內(nèi)聚的函數(shù)可能被編譯單元外部的全局變量、靜態(tài)單例、回調(diào)注冊表悄悄影響。我踩過的最大坑就是重構(gòu)一個協(xié)議解析函數(shù)時自以為邏輯不變結(jié)果漏看了一個全局狀態(tài)變量上線后消息串包。那次之后我給自己定了一條鐵律重構(gòu)之前先織“測試安全網(wǎng)”。所謂安全網(wǎng)就是在重構(gòu)前為原有函數(shù)的行為創(chuàng)建一組特征測試。不需要追求100%覆蓋但要把核心輸入輸出、邊界情況、異常分支都釘住。C做特征測試我常用的工具是Google Test或者Catch2寫起來都很快。測試通過之后再一步一步重構(gòu)每拆出一個子函數(shù)就編譯一次、跑一遍測試確認(rèn)綠燈再繼續(xù)下一步。一次只動一個點提交信息里標(biāo)明“僅重構(gòu)無行為變更”出了問題也能快速回滾。5.3 復(fù)雜度門禁讓“紅線”成為團(tuán)隊的共同記憶代碼復(fù)雜度的治理靠個人自覺是堅持不了多久的。團(tuán)隊協(xié)作的場景下我強(qiáng)烈建議把復(fù)雜度紅線寫進(jìn)門禁系統(tǒng)。具體怎么做呢最輕量的方案是在Code Review清單里加一條新提交的代碼函數(shù)圈復(fù)雜度不得超過10重活是給CI加一個檢查腳本直接用Lizard的--threshold參數(shù)讓超限提交直接失敗。我用過的一個實用方法是在CI里加一個簡單步驟lizard src/ -l cpp -C 15 --warnings_only如果掃描到圈復(fù)雜度超過15的函數(shù)腳本返回非零狀態(tài)流水線直接紅掉。這樣團(tuán)隊里的每個人都會被迫面對數(shù)據(jù)而不是靠某個人review時憑感覺說“這段有點復(fù)雜”。當(dāng)然門禁閾值要設(shè)得合理一開始可以從20開始讓存量代碼先活下去再逐步收緊到15、10。太激進(jìn)的閾值會導(dǎo)致團(tuán)隊天天跟CI搏斗反而沒人關(guān)心代碼到底好不好。5.4 我踩過幾次坑之后的幾條心得把上面的內(nèi)容總結(jié)成幾條大實話。圈復(fù)雜度、認(rèn)知復(fù)雜度這些數(shù)字從來不是為了發(fā)報告好看也不是為了在review時跟同事爭論“你這個函數(shù)9分我接受不了”。它們的最終目的只有一個——讓代碼能夠被“安全地修改”。我的日常工作里每次改代碼前都會問自己一句“如果新需求下周就來我敢不敢動這塊”如果答案是不敢那不管指標(biāo)怎么好看這塊代碼在實質(zhì)上就是高復(fù)雜度的。另外每次給工程做完復(fù)雜度分析我都會做一件很簡單的事挑出“本周最讓我頭疼的一個函數(shù)”花半小時試著拆掉它。不需要大刀闊斧哪怕只是把一層嵌套變成衛(wèi)語句、把一段重復(fù)邏輯提取成函數(shù)都算贏。日拱一卒一個月下來你再跑一次Lizard看到的曲線走勢那種成就感比寫十篇漂亮的架構(gòu)文檔來得真實得多。