现在有一个常见现象：公司想要更快更便宜地构建软件。

　　这当然是一个可以理解和值得称赞的目标。且每个工程师都应该全心全意支持这个目标。

　　然而事与愿违。虽然并非是故意的，但是随着时间的推移，我们会因为软件构建中难以预料的复杂性而陷入困境，然后训练自己去寻找边缘案例，分析差距，以及单点要求所带来的所有隐藏的影响。

　　我们深陷复杂性和优雅的泥沼：再来个抽象层！自己动手！分离关注点！组合优于继承！这也是可以理解的，但是在这个过程中，我们常常忽略了要解决的业务问题，忘记了管理复杂性是软件开发人员的第二重要职责。

　　那么我们怎么会走到这一步？

　　在某些方面……软件变得更容易了

　　在过去的几十年中，我们的行业已经非常成功地减少了编写大多数软件所需的自定义代码量。

　　这种减少大部分是通过使编程语言更具表现力来实现的。像 Python，Ruby 和 JavaScript 这样的语言可以只用C语言三分之一的代码来实现类似的功能。而C语言在编写汇编程序时也提供了类似的优点。展望未来，有很大的可能，语言设计也将提供同样的改进。

　　但是减少构建软件所需的代码量涉及许多其他不需要使语言更具表现力的途径。迄今为止，我们在过去二十年中取得的最大收益是开源软件（OSS）。如果没有个人和企业将资金投入到他们向社区免费提供的软件中，那么我们今天所构建的大部分软件和功能在没有庞大花费和努力的情况下是一项不可能的任务。

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

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

　　所以遗留给我们的是一个看起来像这样的（针对 web 应用程序）的堆栈…

<Our Code>

<Libraries>

<Web Framework>

<Web Server>

<Data Stores>

<Operating System>

　　“Our Code”部分最后会变得非常复杂，因为它反映了业务及其流程。如果我们有自定义的业务逻辑和自定义的流程，那么我们只需构建构成我们应用程序的接口、工作流程和逻辑。当然，我们可以尝试找到不同的方式来记录这个逻辑（还记得业务规则引擎么？），然而恐怕最后再没人愿意为你的业务写业务逻辑。实际上似乎没有办法解决这个问题……至少在机器人横空出世来拯救我们免于做任何工作之前。

　　不喜欢代码，那么 low-code 呢？

　　因此，如果我们必须开发组成应用程序的接口\工作流程和逻辑，那么看上去困难重重，对吗？在一定程度上，是的，但我们有一些选项。

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

　　这些工具涵盖了你需要编写的代码量，总的来说，你可以直观地设计 app，然后编写大量的代码来实现 app 的逻辑。在许多情况下，你仍然以编程方式操作接口，因为使用这些工具构建的接口通常会变得非常静态。但是，对于大量的应用程序来说，这些工具可以大大提高生产力，大部分以牺牲灵活性为代价。

　　这些工具的普及程度可能在 web 接管之后就减弱了，但是企业对它们的渴望却并没有减弱，特别是在软件需求的步伐依然不可阻挡之后。整个行业的最新趋势是“low code”系统。low code 开发工具是最新一代的拖放式软件开发工具。这些工具和它们的同胞之间最大的区别在于，它们现在主要是基于 web（和移动）的，并且通常托管在云的平台上。

　　许多公司前赴后继地涌向这些平台。像 Salesforce（App Cloud），Outsystems，Mendix 或 Kony 这样的供应商都希望可以创建比“传统”应用程序开发快很多倍的应用程序。虽然他们的许多说法可能是夸张的，但可能也有一些事实。虽然依赖这些平台缺点不少，但却能使得构建某些类型的应用程序比使用 .NET 或 Java 的传统企业项目更快。

　　那么，问题是什么？

　　首先是有经验的开发人员讨厌这些工具。最严谨的开发者喜欢用 Real Code 编写 Real Software。我知道这听起来好像是在吹毛求疵(也许是有点)，但是如果你的核心价值是技术，那么采用那些最好的开发人员不愿使用的工具并非是一个好主意。

　　其次，像我这样的人看着这些有壁垒的平台，打从心眼里就“不愿意在那里构建我的应用程序”。这是一个合理的担忧，也是最困扰我的问题。

　　如果你十年前用 PHP 构建了一个应用程序，那么这个应用程序虽然可能会略显沧桑，但它现在可能仍然可以工作良好。语言和生态系统是开源的，还有社区的维护。你需要保持应用程序的更新，但是你不必担心供应商决定不再花时间来支持你。

像我这样的人看着这些有壁垒的平台，打从心眼里就“不愿意在那里构建我的应用程序”。这是一个合理的担忧，也是最困扰我的问题。

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

　　对于这些类型的平台要警惕，但是对于许多企业来说，用较少的努力来创建软件更有吸引力。软件的复杂性还会继续，不幸的是软件工程师在这里不能给自己任何裨益。

　　需要改变什么？

　　有那么多高效的平台允许我们用 Real Code 构建 Real Software，但不幸的是，我们现在的行业太过关心跟随科技巨头的领导，以致不能意识到有时他们的工具不会给我们的项目增加很大的价值。

　　不知道有多少次我碰到开发者告诉我，构建一些如单页面应用程序（SPA）这样的东西不会增加开销，而只是渲染 HTML。我曾听开发人员说每个应用程序都应该写在 NoSQL 数据存储的基础上，而关系数据库已经玩完了。我也听到过开发人员质疑为什么每个应用程序不是使用 CQRS 和 Event Sourcing 编写的。

　　正是这种思维过程和默认开销导致企业认为软件开发太昂贵了。你可能会说：“但 Event Sourcing 是如此优雅！在微服务之上有 SPA 是如此的干净！“当然，可能是这样的，但是当你成为编写这 10 个微服务的人时，情况就并非如此了。这种额外的复杂性往往是不必要的。

　　作为一个行业，我们需要设法简化构建软件的过程，而不忽视业务的合法复杂性。我们需要承认，并非所有的应用程序都要有与 Gmail 相同的界面复杂度和运营可扩展性。全世界的 app 都需要经过周详考虑的界面，复杂的逻辑，坚实的架构，流畅的工作流程等等，但并不需要微服务或 AI 或 chatbots 或 NoSQL 或 Redux 或 Kafka 或 Containers 或任何锦上添花的工具。

　　现在很多开发者似乎对技术魔法本身太过痴迷了，因而不能清醒地问自己是否真的需要这些。

　　我们对灵活性、可组合性和智能的痴迷正在给我们带来很大的痛苦，并迫使公司抛弃我们所喜爱的平台和工具。我并不是说我上面列出的那些工具不会增加价值；它们的出现是为了应对真正的痛点，尽管那些通常是大公司操作大规模系统时所遇到的问题。

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

…我们将把越来越多的业务推到“low code”平台和其他工具的手中，这些平台和工具承诺首先通过简化和删除把我们带往这些平台和工具的部分，来降低软件成本。

　　注重简单性

　　写到这里，我可以预见肯定有很多开发人员会磨刀霍霍，但是我相信，如果我们继续坚持编写、配置、组合所有内容，对所有规模的问题使用相同的堆栈，那么我们将把越来越多的业务推到“low code”平台和其他工具的手中，这些平台和工具承诺首先通过简化和删除把我们带往这些平台和工具的部分，来降低软件成本。

　　我们对业务越来越复杂的解决方案不能是增加开发过程的复杂性——不管它看起来多么优雅。

　　我们必须设法通过简化开发流程来管理复杂性。因为即使管理复杂性是我们第二重要的责任，我们也必须时刻牢记软件开发人员最重要的责任：通过软件的工作来实现价值。

原文发布时间为：2018-09-24

本文作者：yuer

本文来自云栖社区合作伙伴“终端研发部”，了解相关信息可以关注“终端研发部”