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