“爛代碼”扎堆，為何優(yōu)秀工程師一進(jìn)大廠就“變菜”？

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

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

作者 | Sean Goedecke 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

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

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

那問(wèn)題就來(lái)了：這些爛代碼是怎么被寫(xiě)出來(lái)的？

大廠里的大部分改動(dòng)，其實(shí)都來(lái)自“新手”

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

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

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

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

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

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

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

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

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

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

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

(2) “老手”永遠(yuǎn)超負(fù)荷

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

那些“明顯很爛的代碼”到底是怎么被寫(xiě)出來(lái)的？

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

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

● 要么正在處理自己不熟悉的語(yǔ)言或代碼庫(kù)；

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

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

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

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

重點(diǎn)來(lái)了：大廠其實(shí)完全接受這種結(jié)果

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

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

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

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

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

● 對(duì)于純粹工程師，比如專(zhuān)注于編程語(yǔ)言等獨(dú)立技術(shù)項(xiàng)目的工程師來(lái)說(shuō)，糟糕代碼的唯一解釋就是能力不足；

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

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

我認(rèn)為，指出大廠的糟糕代碼本身無(wú)可厚非，甚至還能促進(jìn)修復(fù)，但如果把主要責(zé)任歸咎于這些公司的工程師，那就錯(cuò)了。即使你給予每個(gè)工程師加倍的能力，也無(wú)法阻止?fàn)€代碼發(fā)生，因?yàn)椋簬缀鯖](méi)人能在完全陌生的代碼庫(kù)里零失誤地高效貢獻(xiàn)。

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

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

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