软件复杂性正在杀死我们

              
banq
18-01-31 0 951 10

本文是一篇从业务开发人员角度发出的批判性文章,技术发展日新月异,但是好像都没有真正解放业务开发工作量,对软件复杂性的抱怨是软件行业发展过程中不断出现的现象,其实如何在代码快速开发和代码灵活性方面找到一个结合点,业界其实没有找到规律或者理论,或者都没有所谓不可能定律,也就是说,快速和灵活是不可能同时具备的,当然这种隐隐的不可能定律感受是banq个人的经验总结,下面是原文大意翻译:

从软件诞生开始就有一个规律与目标:企业想要更方便地更快地构建软件。

这当然是一个可以理解的和值得称赞的目标 - 特别是你从软件开发者角度看这个问题时尤其重要。每一位软件工程师都应该全心全意地支持这个目标,我们应该始终努力并尽可能地高效地创造事物。

但实际情况是我们并不经常这样做。这可能不是故意的,但是随着时间的推移,我们会因为难以预料的软件复杂性而陷入困境。

我们会被优雅的解决方案所迷惑:再加一层抽象!DRY原则!分离关注!组合继承!这些是可以理解的,但是在这个过程中,我们常常忽略了要解决的业务问题,忘记了管理复杂性是软件开发人员第二重要的责任。


软件在某些方面变得更容易了
在过去的几十年中,我们的行业已经非常成功地减少了编写大多数软件所需的自定义代码量。

这种减少大部分是通过使编程语言更具表现力来实现的。像Python,Ruby或JavaScript这样的语言可以只用C的三分之一的代码来实现类似的功能。就像C语言相比汇编语言带给了我们类似的优点一样。展望未来,语言设计方面大概不再可能带来像过去几十年中我们看到的同样进步了。

但是减少构建软件所需的代码量涉及许多其他途径,不一定需要使语言更具表现力。迄今为止,我们在过去二十年中取得的最大收益是开源软件(OSS)。如果没有个人和公司将资金投入到他们向社区免费提供的软件中,那么我们现在所建立的大部分功能就需要花费更多的成本和精力。

这些项目使我们能够站在巨人的肩膀上解决问题,利用工具让我们把更多的精力集中在解决业务问题上,而不是花时间建设基础设施。

业务是复杂的,可笑的复杂性只会越来越多。 OSS非常适合制作框架和工具,我们可以用它来构建系统,但是OSS在很大程度上必须解决大量人员共享的问题,才能获得牵引力。因此,大多数开源项目必须是相对通用的,或者处于非常受欢迎的地位。只有这样,这些工具中的大部分才都是构建系统的绝佳平台,但是最终我们仍然需要在日益复杂和苛刻的系统中构建所有的业务逻辑和接口。

所以我们剩下的是一个看起来像这样的(对于Web应用程序)的堆栈...

<我们的代码>
<库>
<Web框架>
<Web服务器>
<数据存储>
<操作系统>

“我们的代码”部分最终变得非常复杂,因为它反映了企业及其流程。如果我们有特殊的业务逻辑和特殊的流程引擎,那么我们只需构建构成我们应用程序的接口,工作流程和逻辑。当然,我们可以尝试找到不同的方式来记录这个逻辑(业务规则引擎?),但是在一天结束的时候,没有其他人会为你的业务写出业务逻辑。实际上似乎没有办法解决这个问题......至少在人工智能来帮我们做任何工作之前是这样。

不喜欢编码,那么低编码呢?

因此,如果我们必须开发我们自己应用程序的接口,工作流程和逻辑,那么听起来就这是不可避免地需要编写代码,对吗?在一定程度上,是的,但我们有几个选择。

对于大多数开发者来说,软件等于代码,但这不是现实。构建软件的方法有很多,其中一种方法就是通过使用可视化工具。在网络之前,可视化开发和RAD工具在市场上占有更大的份额。PowerBuilder,Visual Foxpro,Delphi,VB和Access等工具都具有可视化设计功能,使开发人员无需输入任何代码即可创建界面。

这些工具涵盖了您需要编写的代码量,但总的来说,您可以直观地设计应用程序,然后编写大量的代码来实现应用程序的逻辑。在许多情况下,您仍然以编程方式操作接口,因为使用这些工具构建的接口通常会变得非常静态(不能解决复杂问题)。但是,对于大量的应用程序来说,这些工具可以大大提高生产力,而且大部分都是以丧失灵活性为代价的。

这些工具的普及程度可能在Web互联网之后就已经减少了,但是企业对这些工具的渴望并没有,特别是在软件需求继续维持不可阻挡的发展进程之时。整个行业的最新趋势是“低编码”系统。低编码开发工具是最新一代的拖放式软件开发工具。这些工具和他们的以前同行产品之间最大的区别在于,他们现在主要是基于Web(和移动)的,并且通常是基于云中的托管平台。

许多公司都跳过这些开发平台,像Salesforce(App Cloud),Outsystems,Mendix或Kony这样的供应商提供比“传统”应用程序开发效率快很多倍。虽然他们的许多说法可能是夸张的,但他们也可能有一些事实,某些类型的应用程序比使用.NET或Java的传统企业方式能更快地构建。

那么,问题是什么?
那么,带来几个问题,首先是有经验的开发人员经常讨厌这些快速开发工具。最严肃的开发者™喜欢用Real Code™编写Real Software™。我知道这可能听起来像是我的观点正在迎合一群巨婴(也许我有点儿),如果你提供的核心价值是技术,这里观点不适合你了。

其次,像我这样的人看着这些有围墙的平台,并说“不要在那里建立我的应用程序”。这是一个合理的问题,也是最让我困扰的问题。

如果你十年前用PHP构建了一个应用程序,那么这个应用程序可能会有些年代了,但它现在仍然可以运行。语言和生态系统是开源的,由社区维护。您需要让应用程序是最新的,但是您不必担心供应商公司不再花时间来支持您了。

如果你在10年前选择了一个锁定了一个平台供应商,那么如果他们倒闭或者大幅度改变了他们的工具,你可能会被迫重写代码(记住Parse?)。或者更糟糕的是,你的系统被冻结在一个平台上,不再满足你的需求。

对于这些类型的平台有很多理由要警惕,但是对于许多企业来说,用较少的努力来创建软件的吸引力就太多了。软件的复杂性还在继续,不幸的是软件工程师在这里没有发现任何好处。

什么需要改变?
有产品化的平台可以让我们用Real Code™方式构建真正的软件™,但不幸的是,我们现在的行业非常担心跟随这些大科技巨头的领导,有时他们的工具不会对我们的项目增加很大的价值。

有多少次开发者告诉我,构建一个单页面应用程序(SPA)的次数不会比直接使用HTML渲染而增加开销。我听说开发人员说每个应用程序都应该基于NoSQL数据存储编写,同时,宣称关系数据库已经死了。我听说有开发人员质疑为什么每个应用程序不是使用CQRS和事件溯源来编写呢?

正是这种思维过程和默认开销导致了公司认为软件开发太昂贵了。你可能会说:“但事件溯源是如此优雅!在微服务之上构建一个SPA是如此的干净!“当然,这可能是事实,但是当你是编写这十多个微服务的人时,就不是这样了。这种额外的复杂性往往是不必要的。

作为一个行业,我们需要设法简化构建软件的过程,而不会忽视企业的合法复杂性。我们需要承认,并非所有的应用程序都需要拥有与Gmail相同的界面复杂度和运营可扩展性。整个世界的应用程序都需要经过深思熟虑的界面,复杂的逻辑,坚实的架构,流畅的工作流程等等。但不需要微服务或AI或chatbots或NoSQL或Redux或Kafka或容器或任何之类的工具。

现在很多开发者似乎对这个技术的魔术太痴迷了,所以他们不能退后一步问自己是否真的需要这些。

就像MasterChef上的人一样,他们以美食家的身份进入和销售自己。他们将食品成分分成不同的组成部分,使用科学的配对方法,然后用产生大量的二氧化碳和液氮作为代价生产出你所见过的最有创意的食物。然后他们在一两次之后就被踢掉了,因为他们忘记了大多数烹饪的核心宗旨,那就是食物需要口感好。他们似乎真的很惊讶,没有人喜欢他们的发酵茴香和芒果精华珍珠鳕鱼与anch鱼泡沫。

我们对灵活性,可组合性和聪明性的痴迷正在给我们带来很大的痛苦,并迫使公司远离我们所爱的平台和工具。我并不是说我上面列出的那些工具不会增加价值; 它们也是为了回应真正的痛点而产生的,尤其是大型公司在大规模操作系统时经常遇到的痛点问题。

我所说的是,我们需要回到简单化的方向,开始以一种更简单的方式创造事物,而不是一味地谈论简单。也许我们可以依靠更多的集成技术栈来提供开箱即用的模式和工具,以便软件开发人员更有效地创建软件。

...我们将把越来越多的企业推到“低代码”平台和其他工具的手中,这些工具承诺通过减少软件成本,并将首先带给我们去除部分编程工作,从而降低软件成本。

我们需要停止掩盖这样的事实,我们在20世纪编写应用程序实际类似需要认真手工缝制的独特挂毯。


Software Complexity Is Killing Us - Simple Thread

10