【CSDN 編者按】在大眾認知里，大廠手握頂尖人才與資源，本應(yīng)是高質(zhì)量代碼的“代名詞”。但實際上，關(guān)于“大廠代碼粗糙”的吐槽卻頻繁發(fā)生。本文作者以一線大廠研發(fā)經(jīng)驗為切口，撕開了“優(yōu)秀工程師寫爛代碼”的表象：從薪酬結(jié)構(gòu)導(dǎo)致的人員高頻流動，到資深工程師的超負荷困境，再到公司戰(zhàn)略對“靈活性”的刻意傾斜，拆解出了代碼質(zhì)量與組織機制間的深層矛盾。

原文鏈接：https://www.seangoedecke.com/bad-code-at-big-companies/

作者 | Sean Goedecke 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

幾乎每隔幾年，就會有人驚訝地發(fā)現(xiàn)：大廠居然也會產(chǎn)出又亂又糟的代碼。

如果你沒在大公司待過，很難理解這是怎么發(fā)生的。畢竟——大廠薪資足夠高，能吸引大量優(yōu)秀工程師；研發(fā)節(jié)奏不快，外界甚至覺得工程師可以慢慢打磨。

那問題就來了：這些爛代碼是怎么被寫出來的？

大廠里的大部分改動，其實都來自“新手”

核心原因在于：大廠里太多工程師都在自己不擅長的領(lǐng)域工作。

有調(diào)查顯示，大廠員工平均任期往往只有 1-2 年。而事實上，大廠的薪酬體系本身就是為“四年上限”設(shè)計的——四年后初始股票發(fā)完，工程師等于被“降薪 50%”。

雖然公司會繼續(xù)提供年度股票刷新獎勵，但你永遠不知道下一年還能不能拿到，這自然會刺激大家跳槽鎖定下一份長期激勵。如果把內(nèi)部調(diào)崗也算上，情況就更糟了。

我職業(yè)生涯中在同一個團隊、同一份代碼庫上工作最久的時間，也不過是剛?cè)胄袝r的三年。現(xiàn)在，我?guī)缀趺磕甓紩?jīng)歷至少一次組織架構(gòu)調(diào)整，有時甚至更頻繁。

但大廠代碼庫的“壽命”比工程師的任期要長得多，像我維護的很多服務(wù)已經(jīng)運行十年甚至更久，中途換過一批又一批負責(zé)人——這意味著：無數(shù)工程師一直處于“摸索中”狀態(tài)。

而這樣的結(jié)果就是：有相當(dāng)高比例的代碼變更，都出自那些入職不到半年、剛熟悉公司流程、代碼庫甚至編程語言的“新手”。

“老手”能救一部分，但救不了全部

確實，大廠里也有一些“老手”：長期圍繞某個系統(tǒng)工作，積累了真正的深度經(jīng)驗。他們能通過深度代碼審查，精準揪出明顯的問題。

但如果依賴“老手”，就會有兩大結(jié)構(gòu)性缺陷：

(1) 完全是“民間體系”，公司本身不培養(yǎng)

很多大廠，其實并不會刻意培養(yǎng)工程師在特定系統(tǒng)上的長期專業(yè)能力，也不太在意如何長期留住這種經(jīng)驗。所以這些“老手”經(jīng)常被調(diào)到其他業(yè)務(wù)線，他們要么自愿繼續(xù)兼職做老代碼庫的顧問，要么徹底放棄、成為另一個新系統(tǒng)中的“新手”。

(2) “老手”永遠超負荷

一個系統(tǒng)里能真正懂全局的人通常就那么幾個，他們每天都很忙：自己有 KPI、要補位做代碼審查，還得參與重要決策。如果他們花太多時間在審查別人的代碼上，很可能被公司認為“個人產(chǎn)出不夠”，影響績效、晉升甚至面臨警告。

那些“明顯很爛的代碼”到底是怎么被寫出來的？

綜合這些因素，大廠里的典型工程師往往是這樣的：

他們足夠優(yōu)秀，能通過大廠的招聘門檻，也能勝任本職工作，但是——

● 要么正在處理自己不熟悉的語言或代碼庫；

● 要么一邊要應(yīng)對海量的代碼變更，一邊還要兼顧自己的核心任務(wù)。

他們幾乎永遠在趕 Deadline，甚至要同時應(yīng)對多個項目的重疊 Deadline。換句話說，他們是在一個根本不支持產(chǎn)出高質(zhì)量代碼的環(huán)境中，盡力做到最好。

于是，這就是“明顯很爛的代碼”出現(xiàn)的全過程：

某個“新手”接到一個完全不熟悉的代碼庫中的 Bug 要求修復(fù)，他花了幾天時間摸索入門，想出了一個臨時解決方案；某個“老手”如果有時間，會匆匆掃一眼，否了它，然后給出一個至少能運行的方案；“新手”照著改，并做了基礎(chǔ)測試，經(jīng)過簡單審查就上線了——所有人隨即轉(zhuǎn)向優(yōu)先級更高的工作。五年后，某位倒霉的新維護者看到這段代碼，不禁疑惑：“這么粗糙的代碼，怎么會出現(xiàn)在大廠里？”

重點來了：大廠其實完全接受這種結(jié)果

我之前就提過，大廠完全清楚把工程師當(dāng)“可替換資源”四處調(diào)動，會損失長期代碼庫經(jīng)驗，但這是一種刻意的權(quán)衡——他們放棄了部分專業(yè)深度和軟件質(zhì)量，換取了快速將熟練工程師投入到“月度重點問題”中的靈活性。

我不知道這種做法是好是壞，但它顯然對大廠是有效的——尤其是在當(dāng)前“快速轉(zhuǎn)向 AI 相關(guān)業(yè)務(wù)”至關(guān)重要的環(huán)境下?？杉热贿x擇了這種模式，大廠也愿意接受隨之而來的結(jié)果：工程師在陌生系統(tǒng)里匆忙產(chǎn)出的劣質(zhì)代碼。

顯然，單個工程師完全無力改變這種現(xiàn)狀。尤其在 2025，組織權(quán)力已經(jīng)從工程師側(cè)傾向管理層。作為個人，你唯一能做的就是爭取成為“老手”：在至少一個領(lǐng)域積累專業(yè)知識，用它來阻止糟糕代碼的產(chǎn)生，并引導(dǎo)團隊做出至少合理的技術(shù)決策。但即便如此，這往往也是在與組織趨勢對抗——如果處理不當(dāng)，甚至?xí)?PIP（績效改進計劃）盯上。

“純粹”工程 vs. “非純粹”工程

這一切的核心，在我看來，在于 “純粹軟件工程” 與 “非純粹軟件工程” 的區(qū)別：

● 對于純粹工程師，比如專注于編程語言等獨立技術(shù)項目的工程師來說，糟糕代碼的唯一解釋就是能力不足；

● 但非純粹工程師的工作更像是水管工或電工：他們要在 Deadline 前完成自己相對陌生的項目，即便技術(shù)基礎(chǔ)無可挑剔，也總會遇到一些特殊場景下的棘手問題。對他們而言，糟糕的代碼是不可避免的——只要整個系統(tǒng)還能跑，項目就算成功。

可問題在于：在大廠里，工程師幾乎沒辦法選擇自己做的是純粹工程還是非純粹工程——公司讓你去哪，你就必須去哪。

我認為，指出大廠的糟糕代碼本身無可厚非，甚至還能促進修復(fù)，但如果把主要責(zé)任歸咎于這些公司的工程師，那就錯了。即使你給予每個工程師加倍的能力，也無法阻止爛代碼發(fā)生，因為：幾乎沒人能在完全陌生的代碼庫里零失誤地高效貢獻。

所以真正的問題根源是：大廠的大多數(shù)工程師，被迫在不熟悉的代碼庫上完成大部分工作。而這是一種組織模式，而非個人問題。

【活動分享】2025 年是 C++ 正式發(fā)布以來的 40 周年，也是全球 C++ 及系統(tǒng)軟件技術(shù)大會舉辦 20 周年。這一次，C++ 之父 Bjarne Stroustrup 將再次親臨「2025 全球 C++及系統(tǒng)軟件技術(shù)大會」現(xiàn)場，與全球頂尖的系統(tǒng)軟件工程師、編譯器專家、AI 基礎(chǔ)設(shè)施研究者同臺對話。

本次大會共設(shè)立現(xiàn)代 C++ 最佳實踐、架構(gòu)與設(shè)計演化、軟件質(zhì)量建設(shè)、安全與可靠、研發(fā)效能、大模型驅(qū)動的軟件開發(fā)、AI 算力與優(yōu)化、異構(gòu)計算、高性能與低時延、并發(fā)與并行、系統(tǒng)級軟件、嵌入式系統(tǒng)十二大主題，共同構(gòu)建了一個全面而立體的知識體系，確保每一位參會者——無論是語言愛好者、系統(tǒng)架構(gòu)師、性能優(yōu)化工程師，還是技術(shù)管理者——都能在這里找到自己的坐標，收獲深刻的洞見與啟發(fā)。詳情參考官網(wǎng)：https://cpp-summit.org/