InfoQ - 無法忍受不做單元測試和內卷，我離開了這家在美中國企業－鑽石舞台

編譯 | 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 市值 / 估值的互聯網公司中國占了一半。國內互聯網企業強調在業務模式上的創新，在軟件開發流程上，和傳統軟件相比開始有了一些變化。比如迭代速度比不出問題更重要，如果出了問題，能儘快定位，快速修補，減少影響；用戶反饋比按期交付更重要，用最快的迭代速度開發，再收集用戶的反饋，來確定這個產品的功能要不要或怎麼改；捨棄比較可能導致延期交付的「測試」環節......

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

相關鏈接：

https://threadreaderapp.com/thread/1493408428626100226.html

https://testing.googleblog.com/2011/01/how-google-tests-software.html

https://www.infoq.com/articles/day-qa-dept-died/

今日好文推薦

Rust拖慢開發速度？2021年Rust調查報告出爐

出道即巔峰，十年後卻「泯然眾人矣」，蘋果拿什麼拯救 Siri？

滴滴裁員涉及幾乎全線業務；傳微信有部門試行 1065 工作制：6 點準時下班、雙休；曝英特爾將開放x86內核授權 | Q資訊

來自谷歌的開發心得：所有SQL和代碼，都沒必要藏着掖着

活動推薦

5 月 12-14 日，QCon 全球軟件開發大會將落地北京國際會議中心，大會設置了下一代大數據系統架構、分布式數據庫、雲原生數據湖、業務架構、Rust、WASM、可觀測、業務安全合規、產品設計、大前端新基建、組織管理等多個熱點專題，與你一起探討技術新趨勢，點擊閱讀原文了解更多。現在購票即可享受 8 折限時優惠，購票立減 1760 元，掃碼立即購票。