200行是黃金標準？500行必須拆分？這些數(shù)字你大概聽過。但谷歌軟件工程師在維護大型系統(tǒng)十年后，發(fā)現(xiàn)整個行業(yè)對"文件太長"的理解，可能從一開始就跑偏了。

從" cluttered desk "到認知崩塌

作者最初的判斷很直覺：長文件=亂，短文件=整潔。這種感受"幾乎像物理直覺"——亂糟糟的桌子對比井井有條的桌子。但當他真正深入大型系統(tǒng)維護后，這套直覺失效了。

問題出在"太長"這個詞本身。它不是一個描述，而是一個裁決。而裁決需要標準。文件對誰太長？太長而讀不懂？太長而維護不了？剝掉"太長"的框架，真正的問題是：什么讓代碼難以理解和維護？

文件長度是一個癥狀，而非病因。

"短文件=好代碼"怎么變成行業(yè)鐵律

這個規(guī)范的起源其實很合理：在糟糕的代碼庫里，長度和混亂恰好同時出現(xiàn)。工程師們觀察到相關性，于是把它從啟發(fā)式經(jīng)驗提拔為絕對法則——卻沒人驗證它在一般情況下是否成立。

實證研究給出了反直覺的結論。缺陷率研究顯示曲線關系：極小的模塊反而因接口表面過大而問題更多。認知負荷研究證實，將相關邏輯拆到過多小文件中，會真實增加理解成本。

換句話說，過度拆分和過度冗長一樣有害。

為什么"長度完全無關"也是錯的

另一個極端同樣站不住腳。長度確實攜帶一個嘈雜但真實的信號：責任在累積。當文件膨脹，通常意味著它在做太多事。

但關鍵是區(qū)分信號和噪聲。長度值得注意，應該作為提問的提示，而非答案本身。看到800行文件，第一反應不該是"必須拆"，而是"這些東西真的屬于一起嗎？"

該在一起的就要在一起；行數(shù)只是這個結果，不是目標。

cohesion 才是唯一標準

代碼質(zhì)量的真正準則是 cohesion（內(nèi)聚性）——文件里的內(nèi)容是否屬于彼此。長度只是這個判斷的副產(chǎn)品。

一個300行的文件，如果所有邏輯緊密相關，可能比三個100行但頻繁互相調(diào)用的文件更易維護。反之，一個150行的文件如果混雜了不相關的責任，拆分反而是正確的。

作者沒有給出具體行數(shù)建議。他的立場是誠實的：沒有普適數(shù)字。行業(yè)需要放棄對度量的迷信，回到更困難但更重要的問題——這段代碼在做什么，為什么這些部分需要共處一室？

當你下次看到"文件過長"的警告，或者準備按行數(shù)閾值強制拆分時，不妨先問：我是在解決 cohesion 問題，還是在用行數(shù)逃避思考？