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

神译局2021-04-21
这是一个无解的问题?

神译局是36氪旗下编译团队,关注科技、商业、职场、生活等领域,重点介绍国外的新技术、新观点、新风向。

编者按:规模化生产可以降低成本,这应该是一个很简单的经济理论常识。规模化生产在工业领域是以标准化为前提的,例如汽车实现量产,企业因为实现标准化而受益。 软件行业确实完全相反,尤其是管理软件行业,更为突出。如果软件行业也是通过简单标准化实现规模,那么软件企业也就太好做了,因为软件的拷贝是无成本的。但其实,软件的规模化是非常非常复杂的,以至于现在世界上没有任何一家公司很好的解决了这个问题,本文作者分析了这一现象背后的原因。原文标题Everyone Is Still Terrible At Creating Software At Scale,作者Mikio L. Braun

我有一种感觉,当人们看到软件的经济潜力后,就会开始寻找 “扩大规模 ”的方法,不止不休。

软件有一些奇特的地方,使它与其他事物不同。很久以前,我读过弗雷德里克·布鲁克斯(Frederick Brooks)的《神话人月》,书中提到了一个概念交“意外的复杂性”(accidental complexity)。为什么我们已经找到了许多创造性学科组织工作的方法,但写软件仍然很难?

我说软件很难是什么意思?自己写软件也许需要花几天时间去做,工作中,变成了企业跨越几个月或几年的项目,这还只是创业公司,可能只有50个软件工程师。大企业中还有更糟糕的情况。

某公司一位很资深的管理者曾对我说,所有的大公司都是“这样”运作的,大公司 “能成功”。我说的 “这样”是指中央项目管理,迁移项目需要几个月才能完成,而对客户的影响却不明显。就像是拿破仑在一些山上排兵布阵。他需要把骑兵放在前面,但首先他要把这支部队调到河对岸,但在这之前,还需要把另外三支部队调来调去等等。当然,这可以做到(就像Twitter臭名昭著的放弃Ruby on Rails,改用 Java一样),但这并不好玩,也没有很好地利用大家的时间和金钱。

有趣的是,我突然就联想到军队,这可能就是大脑的工作方式吧,还有许多其他比喻 “规模化 "地编写软件的意向:比如瀑布,一种自上而下的方法,它的灵感来自于工程项目。布鲁克斯提出的是外科医生的团队作为更好的隐喻。敏捷软件开发没有明确的隐喻,除了本质上是一群人之外(”人高于流程!“)。以及,不要问我SAFe(大规模敏捷开发)像什么!

我发现自己又想到了电影行业,因为这也是一项既具有高度创造性,又有很多专业性的活动(有谁真的知道 “best boy grip”(第一灯光助理)是干什么的?他们也花了几十年的时间来摸索,所以也许这就是软件开发所缺少的。

那么,软件开发有什么特别之处呢?它似乎是一种在一心一意的情况下受益匪浅的活动。然而,你面前的代码只是冰山一角,似乎即使做的很好,你有时也需要把它全部换掉,重写一遍(当然,如果你必须这样做,至少要快)。

一旦涉及到不止一个人,你可以尝试让他们都在同一个心理表征上工作,就像在结对编程(pair programming,两个程序员一起配合)中一样,或者你需要引入一些责任区域,让每个人都能管好自己的事,或者至少更独立地工作。

我很久以前读过的另一本书叫《形式的合成笔记》( Notes on the Synthesis of Form),作者是Christopher Alexander,如果我没记错的话,其中一个主要的观点是,每当你需要针对许多约束条件设计一个系统时,如果你一次解决一个单个的问题,事情就会成倍地变得简单(当然我是这么解读的)。所以这是个好主意,对吧?

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

对于某些类型的程序(如webservices),我们找到了如何架构它们以使工作更容易的方法,但往往当你在编写那一个将为你的创业提供动力,并使你进入十角兽(创业不到10年但市值超过百亿美元的科技公司)领域的软件系统时,你可能只在半途才弄清楚什么是最好的方法,如果你没有勇气去清理这些东西,你最终会得到一个没有监督就无法工作的分工,这意味着需要软件架构师、项目经历和频繁的检查。

这种工作分离的情况,在你决定谁在一个团队中从事什么工作的时候,每次都会发生。一旦你在公司中定义了团队,也会发生这种情况。这将对你所写的软件产生非常真实的影响,也就是所谓的康威定律( 大致意思是设计系统的企业,它们生产的设计等同于企业内的沟通结构)。Skelton和Pais写的《团队拓扑结构》(Team Topologies)一书就采用了这种见解,并应用了 “反向康威手法”,按照你希望系统的样子来设计团队。但你还是需要知道你的系统应该是怎样的。

敏捷软件开发提出了一个强有力的策略,那就是写最简单的能用的东西,然后不断重构(就是提纯的意思)你的代码库。有一些书(很久以前读过的一本Martin Fowler写的 "Refactoring")谈到了重构,但这些大多是一些较小的改动,比如把类中的字段移到它们所属的地方(此处为简化说法!)。

在这一点上,已经非常清楚,“规模化地编写软件”不是一个努力或意志的问题。单纯的 “快速行动,打破局面”是无法帮助你实现这个目标的(是的,我知道他们把它改成了 “用稳定的基础设施快速行动")。我们架构软件和团队的方式是非常现实的,会制约任何一个工程师或团队能做什么、要投入多少工作。

我发现自己又回到了城市的比喻,我第一次读到这个比喻是在格雷和范德沃尔的《连系公司》(Connected Company)一书中。城市之所以引人注目,是因为城市往往相当古老,几乎看起来是不朽的,即使它们在数百年或数十年间被重建和改造,并不断变化。

城市是人类活动的平台。它们提供了基本的基础设施,如道路、电力、建筑、你可以租用的商店空间,现在还有互联网。其中一些基础设施的变化非常缓慢(如道路),而另一些基础设施的变化则要灵活得多,如公寓或商店的用途。

如果也用同样的方式构建软件呢?如果我们企业的核心部分像街道一样,新的东西都是我们可以在上面搭建、实验,不行就拆掉的东西呢?我从内部看了几家电商公司,虽然他们的系统是能够每秒处理上千笔交易的技术奇迹,但感觉并不是这样,而是像App和网站这样的东西和其他的东西纠缠得很深。即使你想,你也无法创建一个100%全新的应用或网站。

反过来说,如果我们用建造软件的方式来建造城市,你可能就需要从专门的车库进入店铺,从屋顶出来走一条电线,才能到另一个用废旧集装箱定制的建筑去结账。而有些窗户是涂上去的,因他们是MVP(最小可行性产品)。

我们正试图通过平台团队来实现,就像城市里的电力公司一样,提供商品服务,这样就不需要每个人都在地下室里运行自己的柴油发电机,这是一个很好的第一步。但往往平台团队要迎合太多不相干的 “客户”(比如后端服务和数据科学家都要部署基础设施),我们通过强制使用平台团队来消除激励,使其为客户做好服务。

城市也很了不起,因为只有有限的中央控制。如果有市场,商店就会开张,如果没有足够的生意,商店就会关闭。相比之下,大多数公司的经营方式更多的是自上而下,导致做出错误或不正确的决定。

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

你现在可能已经意识到了,我只有指针,没有答案。我们仍然没有做到这一点。也许在50年后,我们已经找到了正确的角色,正确的团队结构方式,以及正确的方法来架构软件 “城市”,这些城市是有趣的。

在此之前,我的建议是审视一下结构,问问自己,在你的 “系统”中,任何一个 “单元”完成事情有多难,一切跨责任区的事情都会增加复杂性。《团队拓扑学》(Team Topologies )一书建议,要偏向于端到端的团队,完全负责一个要解决的问题,由平台团队管理一个非常复杂的技术的团队来进行支持。

对于那些需要以流水线方式进行协作的团队来说,无论如何都要从整个系统中找出瓶颈,并集中精力加以改进。这就是Eliyahu Goldratt的 “约束理论”的核心思想。你需要限制正在进行的工作,使其与你的瓶颈相匹配,其他的都是瞎忙活。

也许还有另一种方法,研究如何让人们更有效地合作。我在上面简单地提到了结对编程,我不得不承认,我历来认为这是做不到的,或者说只有少数非常了解对方的人才行,并且已经想出了一种方法,可以互相启发。

具有讽刺意味的是,根据我的经验,仅仅是互相交换想法并不是种好方法。你可能最终的结果是,人们把自己的想法扔进圈里,只是为了让别人发现其中的错误。在最坏的情况下,这可能会变成一场比谁最懂、谁最聪明的比赛。

除非你注意每个人对问题的理解不同,没有注重信息收集和建设性的创意。我最近开始阅读更多的设计思维方法,比如说,利用头脑风暴既收集信息又产生新的想法。我发现这些东西对共同解决问题有惊人的效果。无论如何,我们肯定还没有搞清楚如何规模化地编写软件的方法。

译者:蒂克伟

+1
16

好文章,需要你的鼓励

参与评论
登录后才能参与讨论哦...
后参与讨论
提交评论0/1000

请回复有价值的信息,无意义的评论将很快被删除,账号将被禁止发言。

文章提及的项目

下一篇

在闲鱼,发现当代文豪。

2021-04-21

36氪APP让一部分人先看到未来
36氪
鲸准
氪空间

推送和解读前沿、有料的科技创投资讯

一级市场金融信息和系统服务提供商

聚焦全球优秀创业者,项目融资率接近97%,领跑行业