人才濟濟的大廠，為何頻頻產(chǎn)出垃圾代碼？

作者 | Sean Goedecke

譯者 | 核子可樂

編輯 | Tina

每隔幾年，各大科技巨頭就會鬧出一番動靜，被人發(fā)現(xiàn)產(chǎn)出極其離譜的垃圾代碼。這時候沒在大廠待過的同學就要問了：既然這里薪資優(yōu)厚、人才濟濟，再加上運營節(jié)奏穩(wěn)健，理應(yīng)能夠從容不迫地扎實完成工作。那這些垃圾代碼是怎么搞出來的？

多數(shù)代碼變更出自菜鳥之手

就個人觀察，我發(fā)現(xiàn)科技大廠中其實充斥著“德不配位”的菜鳥工程師。據(jù)調(diào)查，大廠員工的平均在職周期僅為一到兩年。科技巨頭們在設(shè)計薪酬方案時，往往傾向?qū)⒐こ處煹娜纹谙拗圃谒哪曜笥遥凰哪曛箅S著期權(quán)的全部兌現(xiàn)，工程師們的薪資可能銳減一半。盡管大廠也提供臨時性的單年續(xù)簽政策，但總體上制度更鼓勵工程師們到期就另謀高就。

而如果把內(nèi)部調(diào)崗也算進來，情況則更糟。我在單一團隊或者項目上待過的最長時間也就是三年，基本上每年都會至少經(jīng)歷一次重組，而且實際頻率遠不止于此。

與之對應(yīng)的是，大廠的代碼庫平均存續(xù)周期卻遠遠更長——我經(jīng)手過的很多服務(wù)已經(jīng)運行了十年以上，期間經(jīng)歷過無數(shù)次管轄權(quán)變更。這意味著大量工程師們始終處于“摸索狀態(tài)”。相當比例的代碼變更是由“菜鳥”們完成的——其中很多人剛剛?cè)肼毠静坏桨肽昃烷_始接觸代碼庫，此前甚至連編程語言都不懂。

為什么不用老手？

老手當然有自己的優(yōu)勢：這些工程師長期參與特定系統(tǒng)的開發(fā)，積累下大量扎實的專業(yè)往右。他們有能力完成深度代碼審查，會快速發(fā)展各種典型問題。但對“老手”的過度依賴會帶來兩個問題：

首先，科技大廠是沒有相對正式的“老手”培養(yǎng)及調(diào)配制度的。大廠很少以系統(tǒng)性方式針對個人培養(yǎng)其長期專業(yè)知識，即使偶爾出現(xiàn)了這樣的人才，也不會太關(guān)心如何保留這些能力。這類老手工程師常被調(diào)往不同服務(wù)部門，要么在實質(zhì)上繼續(xù)以自愿的形式履行“老手”職責，要么撒手不管、安心在新的崗位上重新成為相對意義上的“菜鳥”。

第二，經(jīng)驗豐富的工程師們永遠處于超負荷狀態(tài)。作為少數(shù)掌握特定深度專長的工程師，他們的工作本就繁忙，既無暇親自審查每項軟件變更、也無法參與完整的決策流程。畢竟大家還有自己的工作要做：如果把時間都消耗在審查變更和參與討論上，我們很可能因為個人產(chǎn)出不足而被約談。

工程師中的大多數(shù)

綜合以上因素，科技大廠中占據(jù)多數(shù)的工程師們到底有著怎樣的典型畫像？他們往往：

• 能力足以通過招聘部門的要求并勝任工作，但是……

• 要么需要接手他們不太熟悉的代碼庫或者語言；

• 要么需要在處理大量代碼變更的同時，兼顧自己的份內(nèi)工作。

他們每天被 deadline 折磨得身心俱疲，有時甚至需要同時面對多個項目的輪番轟炸。換言之，他們需要在根本不利于產(chǎn)出優(yōu)質(zhì)代碼的泥潭當中，努力編寫相對正常的成果。

這就是大廠頻繁產(chǎn)出垃圾代碼的根本原因。例如：初級工程師接手某個相當棘手的工單，但對代碼庫還一無所知。在耗費幾天的摸索之后，他們提出了權(quán)宜之計。如果運氣夠好，會有友善的“老手”花點時間匆匆審閱菜鳥們提交上來的方案，在否決之后給出更加可行的替代建議。初級工程師意圖實現(xiàn)新方案，在測試通過后就匆匆部署上線，之后所有參與者隨即投入其他高優(yōu)先級工作。直到五年之后有人注意到這段代碼，驚訝地發(fā)現(xiàn)“這么垃圾的代碼怎么會出現(xiàn)在科技巨頭的項目當中？”

科技巨頭表示，

“我們做事是這樣的”

我之前曾經(jīng)多次探討過這個問題，并發(fā)現(xiàn)科技巨頭們對于內(nèi)部可調(diào)度性的堅持遠高于生產(chǎn)力水平——即強調(diào)清晰掌握人員分工，并確保可以隨意調(diào)配。大廠也不傻，知道這種將工程師視為可替換部件隨意調(diào)動的設(shè)計會摧毀他們在單一項目上長期積累的專業(yè)知識，但這就是思考之后的刻意之舉。大廠寧愿犧牲一部分專業(yè)知識和軟件質(zhì)量，也要確保隨時能把技術(shù)人才投入最緊急、最需要沖刺的核心項目上。

我沒法斷言這種做法是好是壞，但它顯然已經(jīng)成為科技大廠們的常規(guī)操作，同時也埋下了不小的隱患。特別是在如今這個“快速轉(zhuǎn)向 AI”正成為絕對正確的時代，這種強行要求工程師們倉促處理陌生系統(tǒng)的模式，必然產(chǎn)生比過去更多、更垃圾的代碼。

個人在這樣的模式設(shè)計下完全無能為力。特別是在 2025 年，權(quán)力的天平已經(jīng)人工程師端向著大廠管理層傾斜。作為個人從業(yè)者，我們能做的也只是成長為“老手”：至少精通某個霍工，用專業(yè)知識阻擋這種糟糕的變革，引導(dǎo)團隊做出至少大致合理的技術(shù)決策。但即便如此，個人 / 小團隊也經(jīng)常會與組織的整體趨勢發(fā)生沖突，甚至可能面臨績效改進計劃（PIP）或其他政策的嚴厲懲處。

工程實踐的純粹與非純粹二分

我認為這個問題的本質(zhì)，很大程度上取決于軟件工程的純粹與非純粹二分特質(zhì)。對于純粹的工程師們——即那些從事獨立技術(shù)項目（如編程語言）的工程師而言，對于垃圾代碼的唯一解釋就是水平不行。而非純粹工程師的工作模式更接近水電工，他們常需要在截止期限的壓力下處理相對陌生的項目，即使自身的技術(shù)底子相當扎實，也必然會在特定情況下面臨棘手或者意外狀況。因此后者不可避免會產(chǎn)出垃圾代碼，但對他們的考核標準也有區(qū)別：只要整體系統(tǒng)能夠正常運行，項目就算成功。

在科技大廠，工程師們無權(quán)決定自己要當純粹工程師還是非純粹工程師，畢竟代碼庫根本不歸你所有！只要上頭要求你從數(shù)據(jù)庫基礎(chǔ)設(shè)施小組轉(zhuǎn)向支付系統(tǒng)開發(fā)，你就得乖乖抱著東西過去。你在陌生系統(tǒng)中當然更可能犯錯，原本的數(shù)據(jù)庫基礎(chǔ)設(shè)施小組的同事也可能因為失去你的協(xié)助而受困——這些情況公司都知道，但公司就是要讓每位員工別那么“純粹”。

我解釋這么多，并不是要為科技大廠搞出的垃圾代碼辯解。發(fā)現(xiàn)問題并提出問題仍有好處，至少能有效推動具體問題的修復(fù)，高管們也可以借此機會將負面公關(guān)轉(zhuǎn)化成正面宣傳。我只希望大家不要把主要責任都甩在大廠工程師身上——即使這些員工們一夜之間技術(shù)實力翻倍，垃圾代碼也仍然不會消失，因為幾乎沒人能在全新的代碼庫中零失誤快速完成修改。再次強調(diào)：問題的根源，在于多數(shù)大廠員工被迫在陌生的代碼庫中修修補補。

令我驚訝的是，評論中有很多朋友誤以為我在宣揚某種虛無主義。我自認對工作抱有相當樂觀的態(tài)度，這篇文章的本意是想給大廠的軟件工程師們正名，回應(yīng)批評者們過于嚴苛的抨擊。

除此之外，很多朋友也在評論中提出了關(guān)于垃圾代碼的其他成因理論：缺乏工作動力、大廠故意打擊工程師士氣以阻撓其內(nèi)部聯(lián)合，或者是純粹追求速度指標優(yōu)化。基于個人經(jīng)驗，我認為這些解釋相對缺乏說服力。畢竟我的許多同事都充滿干勁，我也不大相信有任何大廠會刻意做打壓工程師士氣、讓他們心懷不滿的蠢事。

還有一些朋友對期權(quán)兌現(xiàn)的問題提出了質(zhì)疑，表示他們的公司提供期權(quán)更新制度。我不太了解這個，雖然我也享受類似的期權(quán)歸屬更新，但只要這方面制度沒寫入合同，在我看來就意義有限——畢竟公司可以隨時調(diào)整。這對應(yīng)的可是高達 50% 的薪酬來源，相信大多數(shù)人為了鎖定未來四年的收益預(yù)期，都會主動選擇另換東家。

https://www.seangoedecke.com/bad-code-at-big-companies/

聲明：本文為 InfoQ 翻譯整理，未經(jīng)許可禁止轉(zhuǎn)載。

AI 重塑組織的浪潮已至，Agentic 企業(yè)時代正式開啟！當 AI 不再是單純的輔助工具，而是深度融入業(yè)務(wù)核心、驅(qū)動組織形態(tài)與運作邏輯全面革新的核心力量。

把握行業(yè)變革關(guān)鍵節(jié)點，12 月 19 日 - 20 日，AICon 全球人工智能開發(fā)與應(yīng)用大會（北京站） 即將重磅啟幕！本屆大會精準錨定行業(yè)前沿，聚焦大模型訓練與推理、AI Agent、研發(fā)新范式與組織革新，邀您共同深入探討：如何構(gòu)建起可信賴、可規(guī)模化、可商業(yè)化的 Agentic 操作系統(tǒng)，讓 AI 真正成為企業(yè)降本增效、突破增長天花板的核心引擎。