开发人员有必要过度追求软件灵活性吗？

代码量少了不代表软件的复杂度降低了，而是编程语言的表达力更强了。太多开发人员痴迷于框架，过度追求软件灵活性、可组合性等等，而忘记自己是不是真的需要这些。

在有软件之前，只有黑暗。自从时代的黎明到来后，一直存在一个不变的事实：企业想要构建价格更低、运行更快的软件。

当然，这是可以理解并且值得称赞的目标——尤其是你曾经花费时间跟软件开发人员打过交道。每个工程师都应该全心支持此目标，并且在当前环境的约束下，应该始终努力尽可能有效率地创造产品。

然而，事实上，我们经常做不到这一点。并非故意为之，只是随着时间流逝，在构建软件时会因为意料之外的复杂性而陷入困境，因此自我训练以寻找边界案例、差距分析以及所有可能起源于同一个需求要点的隐藏故障。

我们被大量的复杂度以及设计优雅解决方案的精神执念所迷惑：另一层抽象！干起来！分离相关量！继承构成！这也是可以理解的，但是在这个过程中，我们经常忽略正在被解决的业务问题，忘记管理复杂度是软件开发人员次重要的责任。

为什么会造成现在这样的局面？

软件在某些方面上已经变得更加简单了

在过去的几十年里，软件产业非常成功地降低了编写大多数软件所需要的自定义代码量。

这种减少大部分是通过使编程语言更有表现性来实现的。像 Python、Ruby 或 JavaScript 这些语言可以用不到 C 语言三分之一的代码来实现相似的功能。使用 C 语言取代汇编语言编写程序也同样带来了类似的优势。可以预见，在未来，语言设计不大可能带来如同过去几十年一样的改进。

然而也有很多其他不需要让语言更具有表现力的方法，可以精简构建软件的代码总量。截止到现在，在过去的二十年里，我们最大的收获是开源软件（OSS）。如果没有个人和公司将资金投入到他们为社区免费赠予的软件中，没有这么多的代价和努力，那么我们今天所构建的大部分软件将不会实现。

这些项目使我们能够站在巨人的肩膀上解决问题，利用工具让我们更专注于解决业务问题，而不是花时间建设基础设施。

也就是说，业务是复杂的。可笑的复杂，而且只会更多，开源软件非常适合生成用以构建系统的框架和工具，但在很大程度上为了获得关注，又必须解决大量人员共享的问题。因此，大多数开源项目要么是相对通用的，要么是处于非常受欢迎的领域。因此，这些工具中的大部分都是建立系统的绝佳平台，但最终我们仍然需要在日益复杂且要求苛刻的系统中构建所有业务逻辑和接口。

所以我们剩下的是一个看起来像这样的栈（对于 web 应用程序）…

“Our Code”部分最终变得非常复杂，因为它反映了业务及其流程。如果我们有自定义的业务逻辑和自定义流程，那么我们只需编写组建应用程序的接口、工作流程和逻辑即可。当然，我们可以尝试用不同的方式来记录该逻辑（记住业务规则引擎？），但最终，没有其他人会为您的业务编写业务逻辑。实际上似乎没有办法解决这个问题……至少是在机器人到来并将我们从工作中解救出来之前。

不喜欢代码，那么低代码（Low-Code）如何？

如果我们必须开发应用程序的接口、工作流程和逻辑，这听起来像是难住我们了，对吗？ 在某种程度上，是的，但我们仍有几个选择。

对于大多数开发者来说，软件等于代码，现实并非如此。 开发软件有许多方法，其中一种是使用可视化工具。 在网络普及之前，视觉开发和 RAD 工具在市场上占有更大的地位。 诸如 PowerBuilder、visual Foxpro、Delphi、VB 和 Access 等工具都具有可视化设计功能，允许开发人员在不输入任何代码的情况下创建界面。

这些工具涵盖了需要编写的代码，但总的来说，你可以直观地设计应用程序，然后编写大量代码来实现应用程序的逻辑。 在很多情况下，你仍然用编程操作接口，因为使用这些工具构建的接口通常是静态的。 但是，对于大量应用程序，这些工具通过舍弃其他性能获得了巨大的生产力，主要是以灵活性为代价。

自从网络兴起后，这些工具可能已经不再流行，但公司对它们的渴望并没有降低，尤其是因为势不可挡的软件需求仍然持续不断。 整个行业最新趋势是“低代码”系统。 低代码开发工具是最新一代拖放式软件开发工具的现代术语。 这些工具和其他工具之间最大的区别在于，它们主要基于 Web（和移动端），并且通常被托管于云平台。

许多公司正活跃于这些平台上。Salesforce（App Cloud）、Outsystems、Mendix 以及 Kony 等厂商承诺能够比“传统”应用程序开发快许多倍。 虽然他们的很多说法可能很夸张，但也有一定的可信度。依赖类似上述平台的所有弊端，可能的确导致某些类型的程序比使用 .NET 或 Java 的传统程序开发更快。

那么，问题是什么呢？

的确有几个问题。 首先，有经验的开发人员经常讨厌这些工具。 大多数严肃的开发人员™ 喜欢使用真实代码™ 编写真正的软件™。 我知道这听起来像我正在迎合一群呜咽的婴儿（也许我有点儿），但如果你传递的核心价值是技术，那么采用顶尖开发人员不喜欢使用的工具并非是个好主意。

其次，像我这样的人看着这些被封装的平台，说“不，不要在这里构建应用程序”。这是合情合理的忧虑，也是最让我困扰的事情。

如果你 10 年前用 PHP 搭建了一个应用程序，那么这个应用程序可能会显老，但它现在仍然可以嗡嗡作响。 语言和生态系统都是开源的，并由社区维护的。 你需要保持应用程序持续更新，却不必担心供应商断定不再值得花时间支持。

像我这样的人看着这些被封装的平台，说“不，不要在这里构建应用程序”。这是合情合理的忧虑，也是最让我困扰的事情。

如果你 10 年前选择了有自己平台的供应商，那么如果他们关闭工具或频繁更改工具（还记得 Parse 么？），你可能会被迫重写程序。或者更糟，你的系统会停滞在一个停止更新、不再支持服务的平台上。

有很多理由去警惕这类平台，但对许多企业来说，以更少的付出来搭建软件太具诱惑以至于不忍拒绝。 软件的复杂性仍在持续，不幸的是软件工程师帮不上任何忙。

什么需要改变？

有高效的平台，可以让我们用真实代码™ 构建真正的软件™，但不幸的是，软件行业太过担心于跟随科技巨头地领导，以至于没有意识到他们的工具并没有对项目添加任何价值。

我无法告诉你有多少次，曾遇到开发人员跟我说，相比于仅仅渲染 HTML，构建单一页面应用程序（SPA）类似的东西并不会增加开销。我曾听开发人员说过，所有应用都应该基于 NoSQL 数据库来开发，而关系数据库逐渐没落了。也曾听开发人员质疑为什么应用程序不是用 CQRS 和事件溯源编写的。

正是这种思维过程和常规的开销导致公司认为软件开发过于昂贵。 你可能会说，“但事件溯源如此优雅！在微服务之上搭建 SPA 如此整洁！”当然，它可能是，但对你这种正在写十个微服务的人来说不是这样的。这种额外的复杂性往往是不必要的。

作为从业人员，我们需要找到各种方法来简化搭建软件的过程，并且不忽视业务的合理复杂性。 我们需要承认，并非每个应用程序都需要与 Gmail 相同层次的界面复杂性和运营扩展性。 有很多应用程序需要经过深思熟虑的界面、复杂的逻辑、坚实的体系结构、流畅的工作流程等。但不需要微服务、AI、chatbots、NoSQL、Redux、Kafka、Containers 或任何类似的工具。

如今很多开发人员似乎对技术能力非常着迷，以至于他们不能退后一步，问问自己是否真的需要这些。

就像 MasterChef 上的人一样，他们以分子美食家的身份入场兜售自己。 他们将原料分成不同的组成部分，使用科学配对口味的方法，然后用大量的二氧化碳和液氮来制作你见过的最有创意的食物。 然后他们会在一两集之后被踢开，因为他们忘记了大多数烹饪的核心原则，即食物需要口感好。 他们似乎真的很惊讶于没有人喜欢他们发酵的茴香和芒果精华珍珠加上抹了鳀鱼沫的鳕鱼肉。

对灵活性、可组合性和机敏性的痴迷正在给我们带来巨大的痛苦，并迫使公司远离我们所喜爱的平台和工具。 并不是说我上面列出的那些工具不会增加价值，尽管大公司在大规模操作系统时会遇到典型问题，工具也仅是为了解决真正的痛点而产生的。

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

我们将把越来越多的业务添加到“低代码”平台和其他通过简化、移除起初写过的代码来降低软件成本的工具中。

我们需要停止假装二十行的程序是一些需要认真手工缝制的独特挂毯。

聚焦简单性

写完之后，我仿佛听到一百万位开发人员磨刀的声音，但我相信如果我们继续坚持如下方向：想写所有东西、配置一切、编写所有内容、无论多大规模的问题都使用相同的堆栈，那么我们将把越来越多的业务添加到“低代码”平台和其他通过简化、移除起初写过的代码来降低软件成本的工具中。

我们对业务日益复杂的回答不会增加开发过程的复杂性 – 无论它看起来多么优雅。

我们必须设法通过简化开发流程来管理复杂性。 因为管理复杂性是次重要的责任，我们必须始终记住软件开发人员最重要的责任：通过使用软件来实现价值。