簡(jiǎn)介這是一款專門(mén)用于軟件工程度量的代碼統(tǒng)計(jì)工具面向項(xiàng)目管理者與開(kāi)發(fā)者可快速統(tǒng)計(jì)C、Java、Python、JavaScript等源碼的行數(shù)、注釋與空行從而量化開(kāi)發(fā)工作量并輔助代碼質(zhì)量分析。壓縮包共45個(gè)文件約2.31MB主要包含可執(zhí)行的exe主程序、運(yùn)行所需的dll動(dòng)態(tài)庫(kù)、多語(yǔ)言mo本地化文件、HTML報(bào)告模板、界面圖片與配置文件等解壓即可運(yùn)行。目前已有752人學(xué)習(xí)下載。工具支持按文件或類輸出統(tǒng)計(jì)報(bào)告并可基于環(huán)路復(fù)雜度評(píng)估維護(hù)難度有助于提前發(fā)現(xiàn)潛在問(wèn)題附帶wxWidgets運(yùn)行組件、MinGW環(huán)境以及中/日文語(yǔ)言包適合需要建立輕量級(jí)代碼度量環(huán)境的團(tuán)隊(duì)或個(gè)人收藏使用。注意文中命令與參數(shù)以工具包內(nèi)自帶說(shuō)明為準(zhǔn)如與你手上的版本存在差異以包內(nèi)文檔和幫助輸出為最終依據(jù)。這是這類統(tǒng)計(jì)工具的通用通病先寫(xiě)在前面。1. 代碼統(tǒng)計(jì)工具 Source Counter它解決的不是數(shù)字而是口徑接手別人項(xiàng)目時(shí)最常遇到的一幕對(duì)方說(shuō)「這個(gè)系統(tǒng)大概 6 萬(wàn)行代碼」你打開(kāi)工程一數(shù)好家伙13 萬(wàn)行——差別大到?jīng)]法溝通。這不是誰(shuí)在吹牛而是兩個(gè)人用了完全不同的統(tǒng)計(jì)口徑。代碼統(tǒng)計(jì)工具 Source Counter 解決的正是這個(gè)問(wèn)題它把代碼行、注釋行、空行、混合行按一套固定規(guī)則拆開(kāi)輸出一份可復(fù)現(xiàn)的報(bào)告讓你和別人說(shuō)的是同一份數(shù)據(jù)。它是個(gè)免安裝的本地小工具雙擊能用也支持命令行批量調(diào)用適合三類人接外包要報(bào)工作量的人、寫(xiě)論文或報(bào)告需要寫(xiě)「項(xiàng)目規(guī)?！沟娜恕⒁约岸ㄆ诒P(pán)點(diǎn)內(nèi)部代碼庫(kù)的開(kāi)發(fā)團(tuán)隊(duì)。這篇文章我會(huì)從統(tǒng)計(jì)口徑講到批量盤(pán)點(diǎn)腳本再把我踩過(guò)的五個(gè)坑完整擺出來(lái)。2. 統(tǒng)計(jì)口徑先行三類行數(shù)定義與 Source Counter 的關(guān)鍵參數(shù)先別急著雙擊運(yùn)行。任何統(tǒng)計(jì)工具給出的數(shù)字是否可信取決于你用什么口徑去要求它。我見(jiàn)過(guò)太多人拿到工具直接全盤(pán)默認(rèn)掃描出來(lái)的報(bào)表比自己拍腦袋猜的還離譜原因就是沒(méi)先想清楚「我要統(tǒng)計(jì)的是哪種行數(shù)」。2.1 三種行數(shù)定義物理行、邏輯行與有效代碼行的取舍行數(shù)的定義大致分三類。物理行Physical Lines是按換行符數(shù)的一段代碼寫(xiě)成三行就是三行寫(xiě)成一行就是一行完全取決于作者的書(shū)寫(xiě)習(xí)慣——同一個(gè)文件換個(gè)格式化工具再跑數(shù)字可能立刻變了。邏輯行Logical Lines以語(yǔ)句為單位在 C 系語(yǔ)言里大致對(duì)應(yīng)分號(hào)但對(duì) Python 這種縮進(jìn)敏感的語(yǔ)言判斷邏輯行的算法會(huì)復(fù)雜很多不同工具給出的結(jié)果差異極大。有效代碼行SLOCSource Lines of Code是大多數(shù)人真正想看的「到底寫(xiě)了多少有效代碼」但它的統(tǒng)計(jì)恰恰是最難的注釋里的行算不算、空行算不算、只有大括號(hào)的行算不算各工具口徑五花八門(mén)。Source Counter 這類本地統(tǒng)計(jì)工具實(shí)際做法是把文件拆成幾個(gè)字段來(lái)報(bào)總行數(shù)、代碼行、注釋行、空行、混合行。這個(gè)「混合行」值得單獨(dú)說(shuō)——它指一行里既有代碼又有注釋的行。很多工具不拆這一列而是直接把帶注釋的整行歸進(jìn)代碼行或者整行算成注釋行兩種處理都會(huì)讓最終數(shù)字偏差 5% 到 15%。所以我拿到一個(gè)統(tǒng)計(jì)工具第一件事不是看它能統(tǒng)計(jì)多少種語(yǔ)言而是看它怎么處理混合行。2.2 擴(kuò)展名與注釋規(guī)則讓工具認(rèn)識(shí)你的項(xiàng)目語(yǔ)言第二步是配置擴(kuò)展名和注釋規(guī)則。默認(rèn)情況下統(tǒng)計(jì)工具內(nèi)置了一批常見(jiàn)語(yǔ)言的映射關(guān)系但真實(shí)項(xiàng)目里總有例外比如.jsx和.tsx文件可能沒(méi)有被識(shí)別成前端代碼.vue單文件組件里混著 HTML、JS、CSS 三種片段.sql腳本里注釋用的是--而不是//。如果擴(kuò)展名沒(méi)映射對(duì)那這個(gè)文件要么整個(gè)被跳過(guò)要么被當(dāng)成純文本逐行數(shù)一遍統(tǒng)計(jì)結(jié)果當(dāng)然失真。我一般會(huì)先建一個(gè)配置文件把語(yǔ)言、擴(kuò)展名、注釋符號(hào)、排除目錄全部固定下來(lái)而不是每次手動(dòng)勾選。以下是這類工具里很常見(jiàn)的配置寫(xiě)法原理是通用的鍵名在不同版本里略有差別但思路一致; Source Counter 配置示例統(tǒng)計(jì)口徑全部固定在這里 extensions.c,.h,.cpp,.hpp,.java,.py,.js,.ts,.jsx,.tsx,.go,.sql,.sh block_comment/* */ # -- // formatternone filter_excludenode_modules;build;dist;.git;third_party;venv read_encodingauto report_formatcsv report_detailfile,language,code,comment,blank,mixed,total幾個(gè)關(guān)鍵鍵要理解別照抄就完事。extensions決定哪些文件參與統(tǒng)計(jì)漏了.vue或.sql這類文件會(huì)被無(wú)視block_comment列的是多行注釋和行注釋的符號(hào)Python 的#、SQL 的--、C 系的//都要寫(xiě)進(jìn)去filter_exclude相當(dāng)于統(tǒng)計(jì)黑名單node_modules和build這類目錄不排除結(jié)果會(huì)虛高到?jīng)]法看read_encoding建議設(shè)成auto讓工具自動(dòng)探測(cè)編碼——至于不設(shè)這個(gè)值會(huì)翻什么車我在第四章詳細(xì)說(shuō)。下表是我自己常用的一套語(yǔ)言與擴(kuò)展名對(duì)應(yīng)關(guān)系可以直接抄語(yǔ)言推薦擴(kuò)展名注意點(diǎn)C/C.c, .h, .cpp, .hpp頭文件里可能混入大量宏定義Python.py配置.pyi存根文件是否統(tǒng)計(jì)前端三件套.js, .ts, .jsx, .tsx壓縮過(guò)的.min.js建議排除SQL.sql留意存儲(chǔ)過(guò)程里的注釋是--Shell.sh, .bash長(zhǎng)段注釋有時(shí)用: EOF配置類.yml, .json, .toml默認(rèn)可不統(tǒng)計(jì)看你需求2.3 常用參數(shù)與選型理由為什么用本地工具而不是在線統(tǒng)計(jì)關(guān)于參數(shù)整理一份最常用的幾個(gè)按我自己的使用頻次排列--project指定要統(tǒng)計(jì)的根目錄--exclude排除目錄多個(gè)路徑用分號(hào)或逗號(hào)分隔--format指定輸出格式一般有txt和csv兩種批量盤(pán)點(diǎn)我建議用csv--output指定報(bào)表輸出路徑--encoding指定讀取源碼的編碼默認(rèn)是auto自動(dòng)探測(cè)。前三個(gè)參數(shù)幾乎每次都要用后面兩個(gè)按需。選 Source Counter 而不是別的方式我的理由很簡(jiǎn)單第一代碼不用上傳到任何線上服務(wù)本地跑完就完事遇到公司內(nèi)部項(xiàng)目沒(méi)有隱私顧慮第二它能把口徑固定成配置同一份配置下次還能復(fù)用第三批量盤(pán)點(diǎn)多項(xiàng)目時(shí)能走命令行接私活時(shí)一個(gè)腳本把所有客戶項(xiàng)目的代碼規(guī)模一次性拉出來(lái)。自己寫(xiě)正則腳本統(tǒng)計(jì)行數(shù)看起來(lái)靈活但處理多行注釋嵌套、字符串里包含注釋符號(hào)這些情況時(shí)正則方案會(huì)無(wú)休止地吞邊界條件最后維護(hù)成本遠(yuǎn)超工具本身。2.4 先跑基線再看趨勢(shì)統(tǒng)計(jì)的兩種用法統(tǒng)計(jì)工具在實(shí)際使用中有兩種完全不同的用法很多人只用了第一種。第一種是「盤(pán)點(diǎn)現(xiàn)狀」就是跑一次看當(dāng)前代碼量多少用于報(bào)價(jià)、匯報(bào)、寫(xiě)論文。第二種是「對(duì)比趨勢(shì)」同一份配置固定下來(lái)隔一段時(shí)間跑一次看代碼量增長(zhǎng)了多少、注釋率是上升還是下降。第二種用法更有價(jià)值因?yàn)樗鼙┞俄?xiàng)目的真實(shí)健康度一個(gè)注釋率持續(xù)下降的項(xiàng)目往往意味著文檔正在腐化一個(gè)空行占比異常高的項(xiàng)目可能是某個(gè)同事把大段注釋刪光了只留空行。所以我建議你把配置文件當(dāng)作項(xiàng)目資產(chǎn)來(lái)管理放在倉(cāng)庫(kù)的tools/目錄下而不是放在自己電腦的臨時(shí)文件夾里。這樣團(tuán)隊(duì)其他成員拉下來(lái)跑出來(lái)的數(shù)據(jù)和你在本地跑出來(lái)的完全一致。這一點(diǎn)做到位后面所有匯報(bào)都省去了解釋「你為什么和我數(shù)字不一樣」的功夫。3. 從解壓到批量盤(pán)點(diǎn)命令行跑統(tǒng)計(jì)與報(bào)表字段說(shuō)明配置文件準(zhǔn)備好了工具也下載好了接下來(lái)就是實(shí)際操作。這一章涵蓋三個(gè)落地場(chǎng)景單項(xiàng)目統(tǒng)計(jì)、多項(xiàng)目批量盤(pán)點(diǎn)、以及拿到報(bào)表后怎么看。3.1 拿到工具包之后先看說(shuō)明文檔再跑第一個(gè)命令下載解壓之后別急著雙擊主程序。先花兩分鐘看看包里的說(shuō)明文件確認(rèn)主程序是圖形界面還是命令行工具以及支持哪些參數(shù)。不同版本的參數(shù)名可能有差異但幫助命令一般是通用的在終端里切到工具目錄運(yùn)行主程序并帶上--help或/help參數(shù)能列出全部可用選項(xiàng)。路徑方面有一個(gè)小坑如果項(xiàng)目路徑里帶空格命令行調(diào)用時(shí)要給路徑加引號(hào)否則工具會(huì)把路徑攔腰截?cái)鄨?bào)錯(cuò)。另外建議把工具解壓到一個(gè)固定的純英文路徑下比如D:\tools\sourcecounter\不要放在中文目錄里某些本地工具對(duì)路徑編碼處理不友好放在中文路徑下會(huì)出現(xiàn)不明所以的「文件打不開(kāi)」錯(cuò)誤。3.2 單項(xiàng)目統(tǒng)計(jì)從圖形界面到命令行圖形界面的操作流程通常是選擇根目錄、確認(rèn)擴(kuò)展名配置、點(diǎn)開(kāi)始統(tǒng)計(jì)、查看結(jié)果、導(dǎo)出報(bào)表。第一次用圖形界面沒(méi)問(wèn)題它能幫你直觀地看到每個(gè)文件夾的分布情況。但如果同樣的事情要做第二次就別再點(diǎn)界面了——命令行更穩(wěn)定不會(huì)因?yàn)槭只┻x某個(gè)目錄導(dǎo)致數(shù)字對(duì)不上。以下是我經(jīng)常用的一個(gè)單項(xiàng)目統(tǒng)計(jì)腳本#!/usr/bin/env bash # 單項(xiàng)目代碼統(tǒng)計(jì)固定配置、固定輸出位置 TOOL./sourcecounter PROJECT./src OUT./reports/project_size.csv $TOOL \ --project $PROJECT \ --exclude build,dist,third_party \ --format csv \ --output $OUT \ --encoding auto echo 統(tǒng)計(jì)完成報(bào)表輸出至 $OUT這個(gè)腳本的邏輯很直白第一段變量定義把工具路徑、項(xiàng)目路徑、輸出路徑集中放在一起換項(xiàng)目時(shí)只改變量不改命令第二段調(diào)用主程序四個(gè)參數(shù)分別指定項(xiàng)目根目錄、排除目錄、輸出格式、輸出路徑。排除目錄這里用逗號(hào)分隔多個(gè)目錄都能寫(xiě)。--encoding auto是建議值讓工具自動(dòng)探測(cè)源碼編碼避免手動(dòng)指定錯(cuò)了導(dǎo)致全盤(pán)亂碼。最后一行輸出提示信息方便在批量跑的時(shí)候知道每個(gè)項(xiàng)目是否完成。如果你是在 Windows 環(huán)境下把這段邏輯寫(xiě)成count.bat即可參數(shù)本身不需要改動(dòng)。順手提醒一句腳本里給路徑加引號(hào)是為了兼容帶空格的目錄比如E:\Work Projects\demo這類路徑不加引號(hào)必炸。3.3 多項(xiàng)目批量盤(pán)點(diǎn)一個(gè)腳本匯總所有客戶項(xiàng)目接外包或者做部門(mén)代碼盤(pán)點(diǎn)時(shí)你面對(duì)的往往不是單個(gè)項(xiàng)目而是十幾個(gè)甚至幾十個(gè)倉(cāng)庫(kù)。逐個(gè)打開(kāi)工具去選目錄效率太低了。更現(xiàn)實(shí)的做法是寫(xiě)一個(gè)循環(huán)腳本把每個(gè)項(xiàng)目都統(tǒng)計(jì)一遍然后匯總成一張總表。下面這個(gè)腳本是我在盤(pán)點(diǎn)多個(gè)歷史項(xiàng)目時(shí)經(jīng)常用的核心思路是「遍歷目錄、逐個(gè)統(tǒng)計(jì)、統(tǒng)一收集」import subprocess import csv import os import glob tool rD:\tools\sourcecounter.exe # 工具實(shí)際路徑 projects_base rE:\works # 所有項(xiàng)目所在的根目錄 csv_paths [] for proj_dir in glob.glob(os.path.join(projects_base, *)): if not os.path.isdir(proj_dir): continue out_csv os.path.join(proj_dir, _size.csv) subprocess.run([ tool, --project, proj_dir, --exclude, build,dist,node_modules, --format, csv, --output, out_csv, --encoding, auto, ], checkTrue) csv_paths.append(out_csv)這段代碼先列出E:\works下的所有子目錄逐個(gè)調(diào)用統(tǒng)計(jì)工具生成_size.csv再把所有結(jié)果匯總。注意兩個(gè)細(xì)節(jié)glob.glob通配符匹配到的是完整路徑判斷isdir是為了避免把單個(gè)文件也當(dāng)成項(xiàng)目目錄subprocess.run的checkTrue會(huì)讓腳本在某個(gè)項(xiàng)目統(tǒng)計(jì)失敗時(shí)立刻報(bào)錯(cuò)而不是帶著殘缺數(shù)據(jù)繼續(xù)跑——批量處理時(shí)及早暴露錯(cuò)誤比事后排查更省時(shí)間。匯總步驟再往下就很簡(jiǎn)單了用 Python 的csv庫(kù)把所有_size.csv讀進(jìn)內(nèi)存每行加上項(xiàng)目名寫(xiě)入一個(gè)summary.csv。寫(xiě)到這一步時(shí)有個(gè)經(jīng)驗(yàn)之談?shì)敵鼍幋a用utf-8-sig而不是utf-8因?yàn)?Excel 打開(kāi)無(wú) BOM 的 UTF-8 文件會(huì)亂碼加了 BOM 就能直接雙擊查看。以下是匯總部分rows [] for path in csv_paths: with open(path, newline, encodingutf-8) as f: for row in csv.DictReader(f): project_name os.path.basename(os.path.dirname(path)) row[project] project_name rows.append(row) fieldnames list(rows[0].keys()) with open(summary.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnamesfieldnames) writer.writeheader() writer.writerows(rows)3.4 報(bào)表字段怎么看區(qū)分「代碼行」與「總行數(shù)」拿到 CSV 報(bào)表之后每個(gè)文件的字段大致是這些文件路徑、語(yǔ)言、代碼行、注釋行、空行、混合行、總行數(shù)。匯報(bào)時(shí)最?；煜氖恰缚傂袛?shù)」和「代碼行」對(duì)外報(bào)項(xiàng)目規(guī)模時(shí)我會(huì)優(yōu)先用代碼行而不是總行數(shù)——總行數(shù)里摻著注釋和空行別人無(wú)法判斷你到底寫(xiě)了多少有效代碼對(duì)內(nèi)看代碼質(zhì)量時(shí)注釋行和注釋率就更值得關(guān)注。比如一個(gè)項(xiàng)目總行數(shù) 5 萬(wàn)代碼行 3.2 萬(wàn)注釋行 0.9 萬(wàn)空行 0.9 萬(wàn)注釋率約 22%這個(gè)比例在業(yè)務(wù)系統(tǒng)里算健康。如果注釋率低于 10%要么項(xiàng)目太新還沒(méi)開(kāi)始寫(xiě)注釋要么注釋習(xí)慣很差?？招姓急冗^(guò)高則往往意味著代碼被拆得零碎或者大量無(wú)用代碼被注釋后沒(méi)刪干凈。這些解讀比單純報(bào)一個(gè)數(shù)有用得多也更能體現(xiàn)統(tǒng)計(jì)的價(jià)值。4. 常見(jiàn)問(wèn)題避坑統(tǒng)計(jì)結(jié)果偏差的五個(gè)真實(shí)來(lái)源這章是全文最想讓你認(rèn)真看完的部分。以下五個(gè)坑我都真實(shí)踩過(guò)每一條都會(huì)讓統(tǒng)計(jì)結(jié)果偏得離譜而且表面上看不出任何報(bào)錯(cuò)。4.1 編碼問(wèn)題中文注釋變成亂碼注釋行數(shù)忽高忽低現(xiàn)象同一個(gè)項(xiàng)目在 Windows 上統(tǒng)計(jì)注釋行數(shù)和在 Mac 上統(tǒng)計(jì)的結(jié)果不一樣打開(kāi)報(bào)表看到某些文件的注釋行數(shù)是 0但源碼里明明有大段中文注釋。原因源碼文件是 UTF-8 編碼但沒(méi)有 BOM 頭而工具在 Windows 下默認(rèn)按本地編碼常見(jiàn)是 GBK去讀。中文字符被解釋成亂碼后注釋起始符號(hào)可能被拆壞導(dǎo)致整段注釋沒(méi)被識(shí)別于是注釋行統(tǒng)計(jì)為 0甚至亂碼內(nèi)容被當(dāng)成代碼行計(jì)入。這會(huì)讓代碼行虛高、注釋行虛低。解決配置文件里把read_encoding設(shè)為auto讓工具自動(dòng)探測(cè)編碼如果項(xiàng)目里混著 GBK 和 UTF-8 兩種編碼文件auto也可能失效此時(shí)只能把兩種編碼的文件分開(kāi)目錄統(tǒng)計(jì)。最徹底的做法是統(tǒng)一項(xiàng)目編碼用編碼轉(zhuǎn)換工具把所有源文件轉(zhuǎn)成 UTF-8 with BOM一勞永逸。4.2 注釋誤判正則表達(dá)式和 URL 里的 // 被當(dāng)成注釋現(xiàn)象一個(gè) JS 文件里有一堆正則和 URL統(tǒng)計(jì)出來(lái)的注釋行數(shù)明顯高于實(shí)際寫(xiě)的注釋。原因統(tǒng)計(jì)工具對(duì)注釋的識(shí)別大多基于字符串掃描會(huì)把const url https://example.com里的兩個(gè)斜杠識(shí)別成行注釋起始符或者把正則表達(dá)式/\d/當(dāng)成注釋塊。字符串感知能力弱的工具在這一類文件上幾乎必然誤判。解決先看報(bào)表里的「混合行」或「注釋行」列找出注釋行占比異常高的文件人工打開(kāi)抽查。如果確認(rèn)是字符串誤判換一個(gè)支持詞法分析的工具模式重新統(tǒng)計(jì)如果換不了就在配置里把這類文件排除用別的方式單獨(dú)評(píng)估。還有個(gè)大坑是塊注釋不閉合一個(gè) C 文件里寫(xiě)了/*忘記收尾后面幾百行全部變成注釋導(dǎo)致代碼行為 0這種翻車很難一眼發(fā)現(xiàn)但通過(guò)對(duì)比相鄰版本的統(tǒng)計(jì)結(jié)果能快速定位。4.3 過(guò)濾規(guī)則失控node_modules 和 build 目錄沒(méi)排除現(xiàn)象統(tǒng)計(jì)一個(gè)前端項(xiàng)目總行數(shù) 20 萬(wàn)打開(kāi)報(bào)表一看光node_modules就占了大半或者統(tǒng)計(jì)一個(gè) Java 項(xiàng)目build 目錄下生成的代碼全被算了進(jìn)去。原因配置里的filter_exclude沒(méi)有覆蓋依賴目錄和生成目錄。很多人第一次跑統(tǒng)計(jì)時(shí)只選了項(xiàng)目根目錄沒(méi)配排除項(xiàng)依賴包里的代碼全部被當(dāng)成項(xiàng)目源碼。解決默認(rèn)排除清單建議包含這些node_modules、build、dist、target、.git、vendor、third_party、venv。如果是 Git 管理的項(xiàng)目另一個(gè)更實(shí)用的做法是直接對(duì)比兩次提交之間的變更量用git diff統(tǒng)計(jì)增刪行數(shù)這比統(tǒng)計(jì)全量代碼更能反映一個(gè)迭代周期的工作量。4.4 換行符與空行同一文件兩次統(tǒng)計(jì)結(jié)果不一樣現(xiàn)象同一個(gè)文件第一次統(tǒng)計(jì)空行 200 行代碼格式化后再統(tǒng)計(jì)變成 150 行或者同事在 Windows 上改過(guò)的文件空行數(shù)突然變化。原因換行符不一致。Windows 用 CRLFLinux/Mac 用 LF。某些統(tǒng)計(jì)工具把\r\n算成兩個(gè)字符導(dǎo)致帶回車符的空行被識(shí)別為「有內(nèi)容的行」而不是空行文件末尾如果多一個(gè)換行符部分工具也會(huì)把那個(gè)位置多算一行。解決項(xiàng)目?jī)?nèi)統(tǒng)一換行符用.editorconfig或.gitattributes固定統(tǒng)計(jì)前先跑一次格式化工具比如前端項(xiàng)目的 Prettier把所有文件換行符統(tǒng)一后再統(tǒng)計(jì)。如果只是臨時(shí)對(duì)一下數(shù)字可以接受小幅度偏差但如果是季度之間的趨勢(shì)對(duì)比換行符不統(tǒng)一會(huì)讓數(shù)據(jù)失真到?jīng)]法用。4.5 多工具對(duì)不齊不同工具統(tǒng)計(jì)結(jié)果相差 30% 以上現(xiàn)象用 Source Counter 統(tǒng)計(jì)是 5 萬(wàn)行用另一個(gè)在線統(tǒng)計(jì)工具統(tǒng)計(jì)是 8 萬(wàn)行兩個(gè)數(shù)字差出一個(gè)數(shù)量級(jí)誰(shuí)都說(shuō)服不了誰(shuí)。原因這幾乎是必然的。不同工具的統(tǒng)計(jì)口徑差異極大有的把空行算進(jìn)代碼行有的把混合行拆開(kāi)分別計(jì)有的包含注釋頭尾標(biāo)記行有的把import語(yǔ)句分行計(jì)。工具之間對(duì)語(yǔ)言邊界和擴(kuò)展名的判斷也不同所以對(duì)不齊才是常態(tài)。解決選定一個(gè)工具就固定下來(lái)所有匯報(bào)、論文、報(bào)價(jià)都從同一份配置出發(fā)并在匯報(bào)材料里注明「統(tǒng)計(jì)工具、口徑、排除目錄」這一行說(shuō)明。當(dāng)別人拿著不同數(shù)字來(lái)質(zhì)疑時(shí)不需要爭(zhēng)論誰(shuí)對(duì)誰(shuí)錯(cuò)直接把配置文件和報(bào)表甩給他讓他用同一份配置重跑一遍。做到這一步統(tǒng)計(jì)數(shù)字的「黑匣子」性質(zhì)就基本消失了。5. 把統(tǒng)計(jì)變成固定習(xí)慣規(guī)模估算與可復(fù)現(xiàn)的統(tǒng)計(jì)腳本統(tǒng)計(jì)工具學(xué)到這最后一層是把它變成工作習(xí)慣而不是偶爾想起來(lái)才跑一次。兩個(gè)小技巧分享給你。第一個(gè)是把行數(shù)換算成工作量時(shí)別只看總行數(shù)。常見(jiàn)的參考區(qū)間是業(yè)務(wù)系統(tǒng)平均每人每天有效代碼 150 到 400 行不含測(cè)試代碼注釋和空行大概要再放寬 30% 到 50%。如果你的統(tǒng)計(jì)報(bào)告里代碼行是 3 萬(wàn)行按這個(gè)區(qū)間倒推單人開(kāi)發(fā)大約需要 75 到 200 個(gè)工作日。這個(gè)區(qū)間跨度很大能輔助判斷一個(gè)需求是不是要延期但下單報(bào)價(jià)還是得結(jié)合業(yè)務(wù)復(fù)雜度行數(shù)只負(fù)責(zé)提供邊界參考。第二個(gè)是固定一份可復(fù)現(xiàn)的統(tǒng)計(jì)腳本放進(jìn)項(xiàng)目倉(cāng)庫(kù)的tools/目錄里。腳本內(nèi)容就是第三章的單項(xiàng)目統(tǒng)計(jì)邏輯固定工具路徑、固定配置、固定輸出目錄每次跑完把 CSV 提交到倉(cāng)庫(kù)留檔。這樣做的價(jià)值在于三個(gè)月后任何人拉下倉(cāng)庫(kù)跑一遍腳本得到的報(bào)表和今天完全一致——同一個(gè)項(xiàng)目在不同人手里統(tǒng)計(jì)出不同數(shù)字的爭(zhēng)論直接從源頭消失。我之前接手過(guò)一個(gè)歷史項(xiàng)目對(duì)方交接文檔里寫(xiě)「核心模塊約 3 萬(wàn)行」我跑完統(tǒng)計(jì)愣是沒(méi)找到這 3 萬(wàn)行在哪。后來(lái)把排除目錄和擴(kuò)展名配置調(diào)了一遍發(fā)現(xiàn)真正的有效代碼是 1.1 萬(wàn)行另外 1.9 萬(wàn)行是自動(dòng)生成的代碼和拷貝進(jìn)來(lái)的第三方庫(kù)。對(duì)方的「3 萬(wàn)行」沒(méi)有錯(cuò)我的「1.1 萬(wàn)行」也沒(méi)有錯(cuò)差的只是口徑。從那以后我每次接手新項(xiàng)目、接外包報(bào)價(jià)、或者季度末寫(xiě)匯報(bào)都強(qiáng)制自己先跑一遍固定配置的統(tǒng)計(jì)腳本再開(kāi)口談數(shù)字。數(shù)據(jù)有邊界才經(jīng)得起追問(wèn)。希望這篇工具拆解和踩坑記錄能幫到你。本文還有配套的精品資源點(diǎn)擊獲取