为什么软件行业规模化这么难吗？

编者按:大规模生产可以降低成本，这应该是一个很简单的经济理论常识。大规模生产是基于工业领域的标准化，例如汽车的批量生产，企业从标准化中受益。软件行业恰恰相反，尤其是管理软件行业更为突出。如果软件行业的规模也是通过简单的标准化实现的，那么软件公司就太容易做到了，因为软件复制是没有成本的。但事实上，软件的规模是如此复杂，以至于世界上没有一家公司很好地解决了这个问题。本文作者分析了这一现象背后的原因。原标题:每个人都不擅长大规模开发软件。

软件有一些奇怪的地方，使它与其他东西不同。很久以前，我读了弗雷德里克·布鲁克斯的《神话人月》，其中提到了一个叫做“偶然复杂性”的概念。为什么我们已经发现了许多在创造性学科中组织工作的方法，但编写软件仍然很困难？

我说软件很难是什么意思？编写自己的软件可能需要几天时间，但在工作中，它已经成为企业跨越数月或数年的项目。这只是一家创业公司，可能只有50名软件工程师。大企业的情况更糟。

一位非常资深的公司经理曾经告诉我，所有的大公司都是这样运作的，大公司可以“成功”。当我说“像这样”时，我指的是中央项目管理。搬迁项目需要几个月的时间才能完成，但对客户的影响并不明显。这就像拿破仑在某些山上布置军队一样。他需要把骑兵放在前面，但首先他需要把这支部队转移到河对岸，但在此之前，他需要转移其他三支部队，以此类推。当然，这是可以做到的（就像Twitter臭名昭著地放弃了Ruby on Rails而改用Java一样），但这并不有趣，也没有很好地利用每个人的时间和金钱。

有趣的是，我突然想到了军队，这可能是大脑的工作方式，大规模编写软件的意图还有许多其他隐喻:例如，瀑布（一种自上而下的方法）的灵感来自工程项目。布鲁克斯提出外科医生团队作为一个更好的比喻。敏捷软件开发没有明确的比喻，除了它本质上是一群人（“人在过程之上！”)。还有，别问我保险箱是什么样的！

我发现自己又开始思考电影行业了，因为这也是一项极具创造性和专业性的活动（有人真的知道“最佳男孩握把”（第一个灯光助理）是做什么的吗？他们也花了几十年来探索，所以这可能是软件开发所缺乏的。

那么，软件开发有什么特别之处呢？这似乎是一项同心同德、受益匪浅的活动。然而，您面前的代码只是冰山一角。似乎即使它做得很好，您有时也需要将其全部替换并重写（当然，如果您必须这样做，至少要快）。

一旦涉及到不止一个人，你可以尝试让他们都在同一个心理表征上工作，就像在结对编程中一样，或者你需要引入一些责任区域，以便每个人都可以管理自己的事务，或者至少更独立地工作。

我很久以前读过的另一本书是克里斯托弗·亚历山大写的《形式综合笔记》。如果我没记错的话，其中一个要点是，每当你需要为许多约束设计一个系统时，如果你一次解决一个问题，事情就会加倍简单（当然，我是这样理解的）。所以这是个好主意，对吗？

问题是把问题分解成几个部分严重限制了解决问题的空间。如果你做错了，正确的解决方案取决于两个不同的部分。如果你孤立地看待它，你可能找不到解决方案。

对于某些类型的程序（如webservices），我们已经找到了一种方法来构建它们以使我们的工作更容易，但通常当您正在编写一个将为您的创业提供动力并使您进入颓废野兽（一家成立不到10年但市值超过100亿美元的技术公司）领域的软件系统时，您可能只会在半路上发现什么是最佳方法。如果你没有勇气清理这些东西，你最终会得到一个没有监督就无法工作的分工。

每次当你决定谁在团队中做什么工作时，都会发生这种分工。一旦你在公司定义了一个团队，这也会发生。这将对你编写的软件产生非常真实的影响，这就是所谓的康威定律（大致意思是设计系统的企业，他们产生的设计相当于企业内部的通信结构）。Skelton和Pais撰写的《团队拓扑》一书采用了这种观点，并应用“反向康威方法”根据您想要的系统外观来设计团队。但是您仍然需要知道您的系统应该是什么样的。

敏捷软件开发提出了一个强大的策略，即编写可以使用的最简单的东西，然后不断重构（即净化）您的代码库。有一些书（“重构”是马丁·福勒写的，我很久以前读过）谈到了重构，但这些大多是微小的变化，例如将类中的字段移动到它们所属的位置（简化这里的陈述！)。

在这一点上，非常清楚“大规模编写软件”不是努力或意愿的问题。简单地“迅速行动并打破局面”无法帮助您实现这一目标（是的，我知道他们将其更改为“在稳定的基础架构下迅速行动”）。我们构建软件和团队的方式非常现实，这将限制任何工程师或团队可以做什么以及投入多少工作。

我发现自己又回到了城市的隐喻中。我第一次读到这个比喻是在格雷和范德瓦尔所著的《互联公司》一书中。城市之所以引人注目，是因为它们往往相当古老，看起来几乎是不朽的，尽管它们已经重建和改造了数百年或数十年，并在不断变化。

城市是人类活动的平台。他们提供基本的基础设施，如道路、电力、建筑、可供租赁的商店空间以及现在的互联网。其中一些基础设施的变化非常缓慢（如道路），而另一些基础设施的变化则灵活得多，如公寓或商店的使用。

如果软件是以同样的方式构建的呢？如果我们企业的核心部分就像一条街道，所有的新事物都是我们可以在上面建立和实验的东西，或者如果它不起作用就拆除它，那会怎么样？我从内部见过几家电子商务公司。虽然他们的系统是技术奇迹，每秒可以处理数千笔交易，但感觉不是这样，但应用程序和网站等事物与其他事物深深交织在一起。即使你想，你也不能创建一个100%全新的应用程序或网站。

另一方面，如果我们通过建筑软件来建造一个城市，您可能需要从一个特殊的车库进入商店，并从屋顶走一条电线，然后才能去另一个定制有废物容器的建筑结账。而且有些窗户是喷漆的，因为它们是MVP（最小可行产品）。

我们正试图通过平台团队来实现它，就像城市中的电力公司一样，提供商品服务，这样每个人都不需要在地下室运行自己的柴油发电机，这是很好的第一步。但通常平台团队必须迎合太多不相关的“客户”（例如，后端服务和数据科学家必须部署基础架构）。我们通过武力使用平台团队来消除激励因素，并使其很好地服务于客户。

城市也很伟大，因为只有有限的中央控制。如果有市场，商店就会开门，如果没有足够的生意，商店就会关门。相比之下，大多数公司自上而下地运作，导致错误或不正确的决策。

至少，在公司内部建立一个新项目应该比从头开始更容易，但我的直觉是，许多公司都没有通过这项测试。

你现在可能已经意识到我只有一个指针，但我没有答案。我们还没有这样做。也许50年后，我们已经找到了构建软件“城市”的正确角色、正确团队结构和正确方式。这些城市很有趣。

在此之前，我的建议是看一下结构，问问自己任何“单元”在你的“系统”中完成事情的难度有多大，所有跨越责任区的事情都会增加复杂性。《团队拓扑》一书建议端到端团队应该负责解决一个问题，平台团队应该管理一个非常复杂的技术团队来支持这个问题。

对于那些需要以流水线方式合作的团队来说，无论如何都需要从整个系统中找到瓶颈并集中精力进行改进。这是埃利耶胡·戈德拉特“约束理论”的核心思想。你需要限制正在进行的工作以匹配你的瓶颈，其余的只是徒劳的。

也许有另一种方法来研究如何使人们更有效地合作。我在上面简单地提到了结对编程，我必须承认，我一直认为这是不可能的，或者说只有几个彼此非常了解的人才能做到，我想出了一个相互启发的方法。

具有讽刺意味的是，以我的经验来看，仅仅互相交流想法并不是一个好方法。你可能最终会让人们把他们的想法扔进圈子里，只是为了让别人发现他们的错误。在最坏的情况下，这可能会变成一场竞赛，看谁最了解情况，谁最聪明。

除非你注意到每个人对问题的不同理解，否则你不会注意信息收集和建设性的创造力。我最近开始阅读更多的设计思维方法，例如，使用头脑风暴收集信息并产生新想法。我发现这些东西对一起解决问题有惊人的效果。无论如何，我们肯定还没有弄清楚如何大规模地编写软件。

译者:Tikvay