“我只需一个周末就可以构建出这个应用！”-白红宇的个人博客

发布日期：2021-06-30 18:34:34 浏览次数：3 分类：技术文章

本文共 2992 字，大约阅读时间需要 9 分钟。

凌云时刻

每次人们购买新房、新车或新电视时，都会对新买的产品赞不绝口，这时他们与新买的产品还处于蜜月期。逐渐地，他们会意识到自己购买的高价产品也有缺陷。然而，工程师会比普通用户领先一步，我们会进入解决方案模式，并考虑这些缺陷的解决方案，以及如果换成我们自己，该如何设计这些产品。我们如此聪明，肯定能做出更好的产品，不是吗？

但是，在进行这样的分析时，我们可能会忽略掉一些背景信息。也许负责设计的人受到掣肘；也有可能是时间紧迫，材料的质量低劣或价格过于昂贵。有时是因为采用了瀑布式过程，到了中后期就很难再修复一些问题。我们常常忽略了对于绝大多数人来说，他们想要的是能够正常工作的产品，而非完美的产品。产品带有缺陷的原因有很多种，至少比表面上看起来更加复杂。我至今仍然记得Andrew Houston在Hackernews上发布Dropbox的时候，第一个热议的评论如下：

对于这款应用，我有一些几点疑虑：

对于Linux用户，你完全可以自己轻松地构建这样的系统，只需要一个FTP账号，然后利用curlftpfs挂载到本地，然后在已挂载的文件系统上使用SVN或CVS。而在Windows或Mac上，自带的软件就可以访问FTP账号。

实际上该应用并无法取代U盘。我认识的大多数人都会通过电子邮件发送文件，或者将文件放到网上，这样就可以在演讲的时候使用文件了，但是他们还是会带一个U盘，以防网络出现问题。而这款产品无法解决网络的问题。

这款应用似乎不怎么“热门”，而且也无法产生收入。虽然我知道现在说这些还有点为时过早，但是不向用户收取服务费，却希望从中获利，这可能吗？

有人认为，安装一个文件同步应用程序，与配置一个FTP服务器并无差别。在我看来，这正是缺乏二阶思维（Second order thinking）的例子。我们只看到了最理想的情况，却忘记了解决问题的复杂度。或者说，我们忽略了重点，没有意识到某个解决方案目的是让大多数普通用户也能够解决只有少数人能够有效解决的问题。

Uber为什么需要100多位移动开发人员？

虽然我从未在Uber工作，但我曾在其竞争对手的公司工作。一些思维惯性常常会导致我们把事情想得太简单。比如，想回家时，我们就会想到通过一款打车应用叫车。我们可以选择乘车类型。然后，驾驶员就来了，他们甚至可以打电话给我们或向我们发送消息。到家之后，我们只需要付款就可以了。有些应用甚至允许乘客拼车。

那么，为什么Uber会需要上百名移动开发人员呢？打车应用打乱了出租车行业。就像软件即服务（SaaS）一样，它们提出了一个可扩展的全球性解决方案来解决一个区域的问题。但是，打车应用与SaaS案例有一个很大的区别。世界上的大多数城市都对出租车有（严格的）规定。因此，这类应用的开发公司需要本地化。他们的应用和业务需要适应每个国家、城市，甚至适应特定的场景，例如火车站和机场。

所以呢？你可能会说，这些全都是后端配置。在某些情况下，确实如此。但是，现在假设某些城市的机场需要建立一个虚拟队列供乘客使用。这项新需求带来了一系列有待处理的新问题。我们如何向司机宣布这项新需求？我们如何显示他们在队列中的位置？地理围栏怎么办呢？如果某位驾驶员的GPS断开了一段时间，但是队列马上就轮到他了，该怎么办？他会被放在最后吗？

所有这些处理的很大一部分发生都在后端。尽管如此，但我们的应用也需要大量工作来处理这些情况。现在，再来试想一下对于全世界各个城市来说，类似于这样的特殊需求有几十倍。然后，再想一想Uber和其他拥有全球应用程序的公司。你在卡米尼亚安装了该应用，然后就可以在访问吉隆坡时使用它。这是提供全球范围解决方案时必须完成的一部分工作。

而且，也并非所有功能都可在任何地方使用。将所有功能放到一起后，A/B测试、用户界面、付款等，这些都需要大量的软件工程工作。主要是因为开发人员不能立即解决大规模构建应用的问题。后端可以通过微服务和其他直接的方法来分隔不同的上下文环境。但是，这一点在一个打包好的二进制移动应用内是无法实现的。

因此，这个问题中最具挑战性的部分之一是，允许数百名工程师有效地协作并构建应用。他们将应用分成模块，然后创建和测试了一系列发布。Gergely Orosz在《Mobile at Scale》一书中谈到了所有这些难题。这就是Uber和其他大公司拥有数百名移动开发人员的原因。

其他SaaS服务也面对类似的困境。当我刚加入InfoJobs时，我觉得这个网站并不会太复杂。这是一个求职网站，既可以服务于求职者，各大公司也可以通过这个网站发布公开岗位。后来，我意识到网站内还有许多其他角色的用户。有些公司希望发布他们的ERP。因此，我们需要一个REST（或SOAP）API。大公司还有子公司和各个部门。他们有大量的人力资源部门，因此需要基于角色的访问控制。还有很多类似的“特殊业务”，每次与了解该业务的人交谈时，我都会感到惊讶。

我讨厌公司的平台/基础设施团队

平台团队在软件工程行业中的地位节节攀升。尽管他们希望提高效率，但有时会惹恼产品团队中的工程师。我曾多次听到有人提出类似的问题：

为什么我们不使用技术X，却要用技术Y？这样不是更容易吗？

如今技术Z已经不流行了。为什么我们还要坚持使用它？我只需要一个周末就可以建立一个更好的版本！

除了技术债务和遗留代码外，还有许多原因导致如今这样的局面。这些团队负责平台或基础设施。工程师们希望能够顺利地开展工作。同样，大多数人都希望顺利地完成工作，而不会遇到任何问题，因为他们信任目前的这个基础设施。因为基础设施只有在出问题时才会被人注意到。当一切都按预期进行时，几乎没有人会称赞他们。

这种责任伴随着不可避免的权衡。我们可能无法获得最热门的技术，我们得到只是他们经过权衡利弊后，提供的某个久经考验、很无聊、却很安全且遍及整个公司的技术。即使有些人坚持尝试新事物，他们也会很快意识到，他们需要打理好一切可以从平台上免费获得内容：日志记录、指标、单点登录、库等等。工程师开始看到在组织内部支持新技术的无形成本。

我们很容易过度简化问题，并提出看似更精简的新技术。然而，随着某个技术扩展到整个组织，我们就会看到一个庞然大物。没有人能够“正确地”构建软件。我们的整个技术栈都依赖于一些库（它们的团队可能因为一些原因而无法更新）。很快，我们就会意识到，精益的做事方式可能不适用于大多数情况。

二阶思维