在一个十万人的企业里，没有单元测试也没有代码审查，仅依赖于 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 市值 / 估值的互联网公司中国占了一半。国内互联网企业强调在业务模式上的创新，在软件开发流程上，和传统软件相比开始有了一些变化。比如迭代速度比不出问题更重要，如果出了问题，能尽快定位，快速修补，减少影响；用户反馈比按期交付更重要，用最快的迭代速度开发，再收集用户的反馈，来确定这个产品的功能要不要或怎么改；舍弃比较可能导致延期交付的“测试”环节…
只是我们也很难说清楚，这种技术优势是一种进步，还是需要大家逐渐去改变的地方。也许能结合欧美软件行业中先进的管理方法和技巧，充分发挥中国开发人员的优势和特长，才能更好地提高整体软件开发水平。
更多编程相关知识，请访问：编程视频！！
