在一個十萬人的企業裡，沒有單元測試也沒有程式碼審查，僅依賴 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 市值 / 估值的網路公司中國佔了一半。國內網路企業強調在業務模式上的創新，在軟體開發流程上，和傳統軟體相比開始有了一些變化。例如迭代速度比不出問題更重要，如果出了問題，能盡快定位，快速修補，減少影響；用戶反饋比按期交付更重要，用最快的迭代速度開發，再收集用戶的反饋，來確定這個產品的功能要不要或怎麼改；捨棄比較可能導致延期交付的「測試」環節…
只是我們也很難說清楚，這種技術優勢是一種進步，還是需要大家逐漸去改變的地方。或許能結合歐美軟體產業中先進的管理方法和技巧，充分發揮中國開發人員的優勢和專長，才能更好地提升整體軟體開發水準。
更多程式相關知識，請造訪：程式設計影片！ ！
