無法忍受不做單元測試和内卷，我離開了這家在美中國企業

編譯 | Tina、核子可樂

在一個十萬人的企業裡，沒有單元測試也沒有代碼審查，僅依賴于 QA，但這卻是“有效”的方式！

中國衆多的出海企業正在國外快速占領市場。比如在 2021 年 TikTok 就成為了全球通路量最大的網際網路網站，超越原來的領頭羊、美國 Alphabet 旗下的谷歌。

中國人創造的網際網路平台，超越向來雄霸全球的美國平台，這是一個很具實質和象征意義的發展。

同時，随着中國科技企業的影響力日益提升，很多人對中國企業的工作文化充滿了好奇，想了解到底是什麼造就了這種成功。

最近，一位曾在一家在美中企（TikTok）工作了一年多的華裔（之前任職于 Snapchat 和 Facebook），在 YouTube 上釋出了一個視訊“5 crazy things about working for Tiktok(why we quit our PM and engineering jobs)”，從五個方面總結了他從中國企業裡學到的經驗。

YouTube 位址：https://www.youtube.com/watch?v=RNUrZFkHXlo

他的觀點在 Twitter 上吸引了大批對中美或中國科技感興趣的人，網友認為該文章很準确地描述了中美工程文化差異，我們将這些觀點翻譯了出來：

第一點：很多西方企業都會寫單元測試，每個人都知道這是非常基本的事情。但這裡的中國工程師們不需要編寫單元測試！每項代碼送出都指望 QA 部門的手動測試，團隊在送出之前手動測試每個 code commit 送出。

你可能認為這完全是瘋了，為什麼不寫單元測試？利用 QA 進行測試，實際上是希望工程師們關注于功能，并快速啟動，寫測試就完全交給了 QA。

而且讓人震驚的另一件事情是，代碼合并請求也不需要準許。在一個十萬人的企業裡（這不是一個小型初創企業），沒有單元測試也沒有代碼審查，僅依賴于 QA，但這卻是“有效”的方式！也沒有發生過重大當機事件。

中國企業的産品團隊往往人員更多，也更傾向于依靠營運團隊推動業務增長；這一點與美國被動加資料驅動的增長思路不太一樣。我注意到中美科技企業之間的主要差異，是中國企業對人力的依賴性更高，這個優勢也是中國企業得以迅速占領新市場的核心原因。

第二點：在中國企業，很少見到一對一式的會議，因為擴充性太差了。各個團隊内部很少進一步細分，是以需要跟更多同僚開展互動。經常見到那種典型的、自上而下的會議，一開就是 90 多分鐘，期間 60 多人同時參會。大多數情況下，都是 1 個人在前面講、剩下的人在翻看會議資料。很少有歐美公司裡常見的那種暢談會或者讨論會。

第三點：為了防止獵頭挖人，這裡并不公布明确的組織結構體系。組織結構高度扁平，某些工程經理需要接手 200 多份績效評估報告（未經劃分！），有些報告送出者甚至不知道自己的頂頭上司長什麼樣子。

第四點：從流程與執行上來說，中國企業裡的屁事不多，大家都在低頭忙工作，很少會去傳閑話或者搞道德評判。另一方面，中國企業在流程設計上還不夠成熟。文檔與改進團隊的同僚們無論做得多好，但很難得到激勵。也沒人審查工程師們的代碼。

第五點：從工作與生活的平衡上來說，美國團隊不需要 996，但要求必須适應中國時區。這真挺難的，也是造成人員流失的主要原因，我接觸過的所有 PM 都在工作一年後離職了。

中國的 STEM（科學、技術、工程與數學）專業博士是美國的四倍，但技術崗位反而比美國更少，是以這裡的競争烈度要高于美國，大家把這種狀況稱為“内卷”。中國的同僚們很怕自己失去技術優勢并被社會的發展甩在身後，是以他們才能迸發出巨大的工作能量。

從人力 QA 說開去

可以說近年來中美在科技和網際網路創新領域已經并駕齊驅，中國出海企業能順利搶占到市場，起碼能說明在競争中具有一定的優勢。

然而我們也可以進一步從 Lucas 的描述中看到中美軟體開發流程上的一些差異。比如美國公司在軟體開發中會非常注重技術文檔和使用文檔的細緻規範，注重代碼送出和稽核流程，也特别注重單元測試，不是依靠人力，而是依靠開發過程來保證最後的品質。

網際網路企業的崛起改變了許多軟體設計、開發和釋出的模式。

以單元測試來講，在傳統開發流程中，一般來說，QA (Quality assurance) 負責對程式進行黑盒測試，調用接口時傳确定的參數，再校驗接口響應值符合某種預期。而單元測試是一種白盒測試，要求測試人員了解被測程式的構造，進而構造測試用例校驗程式各個分支邏輯。

顯然，後者更具有挑戰性，不可能像黑盒測試那樣能依靠堆積人力的方式快速地完成工作，是以單元測試會導緻傳遞變慢。為了加快釋出周期，我們在實踐中的分工也逐漸有了改變，開發人員專注于功能建立，而業務上司者則專注于傳遞，開發人員的測試工作就被忽略了。

開發和 QA 測試是一個長期受關注的經典話題。不同公司有不同的辦法，在這一點上，中美軟體開發團隊的差異較大。Google 算是其中一個典型，其測試總監 James Whittaker 于 2011 年曾表示 Google 沒有一個“龐大”的測試部門，相反，部分測試工作委派給了開發人員。在“Google 是如何進行測試”的文章中，James 寫道：

“測試和開發同時進行。編寫一些代碼，馬上進行測試和建構。接着，編寫更多的代碼，繼續測試。更好的是，在你編碼的時候或者編碼之前，就計劃好你的測試。測試不是一個獨立分開的過程，它是開發的一部分。品質不等同于測試；要想有高品質的産品，就要把開發和測試緊密捆綁在一起，直到不分彼此。品質來自開發，而不是測試。”

在 Google，測試人員主要是“確定開發人員有自動架構和相關流程”進行測試即可。解決開發人員依賴他人的問題的關鍵思路是，不在團隊中配備數量衆多的測試人員。十多年前，Google 開發和測試的配比是 10:1，其後甚至喊出了“去 QA”的口号。在文章“ QA 部門消亡日”中，Google 專家甚至認為單元測試是 QA 殺手：

單元測試是一種測試特定代碼片段的方法，它可以確定該代碼段可以正常運作并且契合軟體拼圖。有證據表明，借助單元測試，你可以檢查超過 90% 的代碼，而且，和 QA 的手動測試工具不同，恰當建構、可以自動測試的單元測試可以随着代碼庫一起演化，實時測試代碼。

Google 認為，當将測試職責轉移到開發人員身上時，開發人員将會寫出更幹淨的代碼，建構出缺陷更少、品質更高的軟體。這一切都取決于公司如何組織，以便在不降低品質的情況下降低成本。

到了 2017 年，Google 宣布取消舉辦了十年的測試技術會議 GTAC，Google 的理由是“相比自動化測試技術，他們更關心工程效能的提升”。工程效能在實踐中的落地通常就展現在“開發人員完成開發工作的基礎上，還需要承擔測試、上線和運維的全部工作”，為開發人員的“一條龍”工作提供所有必要的全鍊路工具鍊支援。

但 Google 之前提倡的這一套完全依靠開發保證品質的方法，似乎和 Lucas 提到的“依賴 QA”正好相反。

國内網際網路企業近年來快速崛起，2018 年初 Mary Meeker 的年度網際網路報告裡面，Top 20 市值 / 估值的網際網路公司中國占了一半。國内網際網路企業強調在業務模式上的創新，在軟體開發流程上，和傳統軟體相比開始有了一些變化。比如疊代速度比不出問題更重要，如果出了問題，能盡快定位，快速修補，減少影響；使用者回報比按期傳遞更重要，用最快的疊代速度開發，再收集使用者的回報，來确定這個産品的功能要不要或怎麼改；舍棄比較可能導緻延期傳遞的“測試”環節......

隻是我們也很難說清楚，這種技術優勢是一種進步，還是需要大家逐漸去改變的地方。也許能結合歐美軟體行業中先進的管理方法和技巧，充分發揮中國開發人員的優勢和特長，才能更好地提高整體軟體開發水準。