为什么说“大公司的技术顽疾根本挽救不了”？，java大数据开发面试题

在很多开发者看来，提升敏捷性是解决技术难题的不二法则。但本文的作者作为一家有着一百多年历史的大公司的技术援助顾问却认为，由于历史遗留、文化隔阂等原因决定：在大公司，所谓的敏捷性开发其实并不是人们以为的管用。

为什么他会这么说呢？一起来看看。

以下为译文：

在硅谷流传着很多油嘴滑舌、哗众取宠的肤浅言论，这些言论都是关于开发过程中保持敏捷的重要性的。关于引入敏捷技术的容易性，以及哪些问题可以通过敏捷技术解决，有太多的假设。在这篇文章中，我试图纠正其中的一些错误看法。

在过去的20年里，我曾经是三家初创公司的技术合伙创始人，其中两家公司发展到中等规模后被卖掉了，后来我给一些中型到大型规模的公司做一些咨询工作。这些公司通常有几个办公室，最多可能有3000人。特别是我在2009年搬到纽约后，我成了一名技术救援人员，试图帮助拯救那些技术落后于时代的老媒体公司，让他们迎头赶上新技术。

现在我正在为我曾经合作过的最大的集团公司工作。它拥有11000名员工，旗下有180家公司在运营。这是一家你们大多数人可能都认识的著名公司，你们中的许多人可能还是它的客户。在本文中，我将它称为“SuperRentalCorp”。

关于“初创企业很敏捷，而大公司就像转个身都困难的恐龙一样难以成事”这一主题的文章，已经比

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】

浏览器打开：qq.cn.hn/FTf 免费领取

比皆是。许多商业作家甚至写了一些有趣的书，来介绍大公司如何重组以使其更加敏捷。例如，埃里克·里斯在他的书《创业之路》中提出过一些有趣的想法。

但拯救一家大公司的技术是如此困难，原因何在呢？

在SuperRentalCorp发生的一些问题就是一个很好的例子。

当我最初被告知这家公司需要帮助时，是这样的情形。我的一个给这家公司做咨询工作的朋友这样对我说：“嘿，这家公司需要帮助构建一个API。你知道如何构建API吗？你能帮他们吗？”他告诉我，这家公司尝试构建这个API已经两年了，但到目前为止他们还在失败。

我心里想，“用两年的时间来构建一个API，并且还失败了！看在上帝的份上，现在都已经是2019年了，有几百万个工具可以用来轻松构建API。他们怎么可能认为这很困难呢？一个好的工程师可以在一天内把这件事解决掉。他们为什么苦苦挣扎这么久？”

但是我最初的想法是基于这样的一种场景假设：你只有一个数据库，而你想要做的只是将API置于你的数据库和外部世界之间。这是我在早期初创公司工作时的常见场景。如果使用一个新建的Ruby on Rails项目，说正经的，你可以在一个小时内构建出这种API。

然而，对大公司来讲，有两个大问题困扰着大公司的技术救援：历史和信任。

——我先谈谈历史。

当我提到“历史”这个词时，我指的不是简单地解决历史遗留应用程序的问题，而是处理过去30或40年间不同CEO所做决定的遗留后果，因为公司对过去每个十年时代的变化趋势都得适应。

SuperRentalCorp成立于100多年前，当时世界大部分地区由几个欧洲帝国统治，而大多数公司都是依托他们在西方国家内的公司来经营全球业务。但在1948年至1980年的那个时代，所有的旧帝国都解体了，取而代之的是一百多个新的国家，而这些新国家都保护着自己的独立性。因此，SuperRentalCorp决定采用分散结构。它在大多数国家中设立了子公司，并且子公司作为独立公司运营。有时子公司的部分所有权被出售给他人。这意味着，当上世纪70年代末第一批大型数据库来到时，这家公司没有中央数据库、中央IT部门、也没有首席技术官或首席信息官。

不久之后，由于政治形势似乎变得安全了一些，合并一些服务的好处变得显而易见，因此一些子公司被合并，组建了区域性公司。例如，中东和北非有一家，欧洲有一家，北美有一家，亚洲有一家，南美有一家。通过这种结构，这家公司进入了90年代，这时它开始认真考虑通过网络数据库来管理它所提供的所有服务。

20世纪90年代，面对激烈的全球竞争，这家公司决定通过收购最成功的竞争对手们来实现增长。如果我告诉这些被收购的所有的品牌名字，你会认出其中的大多数，但你可能会惊讶地发现他们现在都为一家公司所拥有。我也很惊讶，因为我也认为这些公司是竞争对手。但事实上他们不再是了。

然后，大约在2005年Web2.0时代的到来，导致竞争对手大量涌现，这些竞争对手提供类似于SuperRentalCorp的服务，但是他们通过使用互联网技术，以新的方式来提供这些服务。同样地，SuperRentalCorp收购了其中的几家初创公司，通过吸收竞争对手来赢得竞争的胜利。许多被收购的初创公司只在单一国家，或单一的市场（如欧盟）内运营。

就在最近，这家公司的新首席执行官决定最好把公司统一起来。一些国际子公司已被全资收购，目前正在进行重组，因此它们将作为公司内部的部门而非独立公司运营。

作为对公司统一的新的重点工作的一部分，SuperRentalCorp希望构建一个统一的API，以便外界认为该公司具有内部统一的技术架构。也就是说，SuperRentalCorp希望给外界一个这样的假象：即该公司只有一个统一的数据库，并且与该数据库的交互很容易。

然而，真实的情况是怎样呢？真实的情况是：SuperRentalCorp拥有20个主要数据库，由20个不同的团队在至少10个不同的国家/地区运行，其中许多拥有独立公司的运营历史，每个团队都保护自己的数据，部分出于安全担忧，部分出于对有关用户隐私的本地法律和对国际用户数据传输的监管的担忧，还有部分原因是纯粹的顽固。

和任何数据库的操作一样，这里有两个需要关注的问题：读取和写入。数据库读取并不难。我们可以从20个不同的数据库中提取（必要的）数据，将数据存储在一个作为缓存的集中数据库中，并在该数据库和外部世界之间放置一个API。数据的时效会出现一些小问题，我们必须进行实验，以确定哪些数据是高优先级的，需要在几秒钟内复制过来。不太重要的数据可以每5分钟复制一次，或者在更新时触发一次复制操作。