每个成功的开发者都应该拥抱的生产力技巧

在过去的几十年里，科技行业取得了巨大的飞跃。如今，从网络解决方案、软件到企业网络和硬件，几乎所有科技领域都自20世纪80年代末（通常被认为是数字革命现代兴起的起点）以来发生了巨大的演变。得益于我们 IT 基础设施中不断增长的设备计算能力和新技术的大规模实施，为用户提供了前所未有的功能和技术能力选择。

发展的速度如此之快，主要的趋势和技术解决方案每隔几年就会被取代，以至于科技行业中那些负责实现所有这些变革的大多数人似乎从未有过放慢脚步、休息一下，并扪心自问“这条路将把我们引向何方”的时间。

在媒体上充斥着赞扬人工智能或云计算等新技术的力量，并描绘数字化转型好处的大量热情洋溢的报道中，要想认识到在计算机系统开发的各个领域日益显现的问题趋势，可能会非常困难。

过度复杂性和技术栈臃肿是否正在拖累我们？

当今网络、移动和企业软件开发中存在一些趋势和流程，它们都在助长一种只能被描述为开发生产力危机的情况，这种危机是由今天仍在蓬勃发展的、无法控制的臃肿现象造成的。

您不必深入软件开发的幕后才能支持这一论点，证据随处可见。

以下是几个最突出的例子。

• 尽管硬件计算能力不断增强，但软件的运行速度却保持不变甚至更慢。

随着消费者设备和企业硬件解决方案每年都变得越来越强大，我们几乎看不到与之相对应的速度和整体性能的提升。不幸的是，新一代设备的额外资源很大程度上被浪费在了满足新软件不断增长的计算能力需求上——这一切都是由于工程工具选择不当以及对不优雅的软件开发工具的普遍偏好。

• 尽管互联网连接速度越来越快，网页加载速度却越来越慢

在 Web 开发中也可以看到非常相似的情况。尽管在过去十年中，互联网连接速度已经增长了20多倍，但许多网站的实际运行速度却比以前慢。这是因为网页的大小每年都在增加。如今，网页的平均大小已超过3兆字节，而在2011年仅为929千字节。Backlinko 在2019年的一项研究（https://backlinko.com/page-speed-stats）对超过500万个桌面和移动网页进行了分析，发现桌面页面的平均加载时间为10.3秒，而移动页面的平均加载时间高达27.3秒。今天 Web 开发中普遍存在的 JavaScript 元素和库的广泛使用是导致此问题的主要原因。这种软件臃肿也通过采用基于 Electron 框架的应用程序悄然蔓延到桌面软件中，这些应用程序利用 Web 技术，但速度缓慢且消耗大量内存。

• 软件解决方案提供商在跨平台交付方面面临挑战

似乎交付日益复杂且功能丰富的产品的需求还不够，软件开发人员还面临着为越来越多的桌面和移动平台提供产品版本的压力。使用不同的工具链为主要平台（其中 Windows、macOS、Linux、Android 和 iOS 是主要的平台）多次构建和更新同一个应用程序，成本高昂、复杂且脆弱。

• 需要不断提供及时更新，这会耗尽开发资源

缩短开发发布周期以及需要及时提供各种安全、设计和功能更新，是开发者越来越难以跟上这种臃肿的另外几个原因。

所有这些以及其他相关因素带来的压力并非没有后果：它迫使开发者采用最快、最简单的解决方案，牺牲质量和代码优化，因为这样做似乎已成为新常态。

跨编程栈的开发者痛点：从 COBOL 到 Java 和 Python

如前所述，困扰当今软件开发并危及各领域生产力的一些最严重问题是臃肿且效率低下的框架和开发工具。让我们仔细看看几个广泛流行的技术栈，以确定这些工具的专业开发者最抱怨和关注的问题。

COBOL

尽管 COBOL 自数字革命大规模展开（20 世纪80 年代末）以来就被贴上了遗留语言的标签，但 COBOL 开发仍然非常活跃，主要是因为许多公司仍然依赖 COBOL 代码库和用该语言编写的解决方案，这些解决方案驱动着他们 IT 基础设施中一些最基本的部分。

然而，随着时间的推移，COBOL 遗留代码的支持变得越来越困难和昂贵，迫使企业解决现代化需求。

以下是开发者 讨论该领域当前状况的一些直接引述。

用户 jimt1234 表示：“我母亲职业生涯的大部分时间都在做 COBOL 程序员，可以追溯到 80 年代初。她在 2015 年退休，很快就感到无聊。我劝她接受兼职合同工作，让她有事做。她接到了无数招聘人员的电话。他们都告诉她同样的故事：《大公司》担心一个关键系统运行的是 COBOL，而以前支持它的员工要么已经退休，要么已经去世。她认为《大公司》的大多数经理对这些‘关键’系统几乎不屑一顾；他们只是想保住自己的工作，要么通过一个‘救世主’（挥一挥魔杖，在 3 个月内修复 40 年的技术债务），要么找一个‘替罪羊’（这是承包商的错，而不是我的错）。”

用户 notimrelakatos 表示：“调试 20 年的 Java 代码很糟糕，但调试 40 年的 COBOL 项目，其源代码备份在 5 英寸软盘上——就别提了。我曾经遇到过一个人将一个 COBOL 项目迁移到 Java。最大的抱怨甚至不是语言本身，而是从一个 40 年的意大利面条式代码库中提取业务逻辑。有时 Bug 本身就是业务逻辑的一部分，而其他消费这个怪物代码的开发者不得不在自己这边进行修正。”

Java

Java 开发生态系统是技术栈日益复杂的一个典型例子，因为开发工具的新版本不断发布。许多 Java 开发者抱怨 Java 8 到 17（目前最新的版本）之间的差异，以及大量相关的兼容性和性能问题影响了他们的工作。

以下是几个值得注意的直接引述。

用户 DarkmSparks 评论道：“我们仍然使用 JRE8 的原因之一是，我测试过的任何较新 JRE 在执行几项任务时都会抛出崩溃的恐慌，而那些不会的则需要 40 或 50 小时才能完成，而不是 4 或 5 小时。这让我觉得稳定性与性能被牺牲了，因为为了吸引喜欢 Rust 和 Go 的人，他们什么都加进去了。我可能是错的，但他们轻描淡写地说 17 比 15 慢，甚至没有尝试与 8 进行比较，而 8 是非常稳定且性能极高的，这让我觉得实际上什么都没有改变。”

用户 pabl0rg 补充道：“在迁移到 Java 9 时，他们破坏了 Java 惯常的向后兼容性，并抛弃了许多用户。没有一个良好、清晰、完整的指南说明如何升级 SOAP 客户端，这也没有帮助。我最近经历了这个问题，了解到由于 Jakarta 使用多版本 JAR，我们必须进行常规的依赖项更改，并将我们的 fat-jar 构建/发布更改为 Docker 镜像。换句话说，他们决定抛弃用户数十年在学习生态系统方面的投入。我一点也不惊讶人们似乎正在离开这个生态系统。”

JavaScript

JavaScript 无疑是近年来网页变重的主要驱动力之一。这种语言为 Web 开发人员提供了许多强大的功能，例如从第三方来源获取实时数据或以低成本利用创新技术，但它们并非没有代价。JavaScript 元素的过载是页面加载缓慢和延迟的主要原因，特别是当 JavaScript 元素编写/集成不当，与其他组件冲突并导致兼容性问题时。

可以理解的是，JavaScript 开发人员对 Web 开发的日益复杂以及在此技术栈中开发解决方案的整体“不优雅”感到不满，而外部框架和库不断相互取代。

以下是一位 JavaScript 开发人员 撰写 的关于当今 JS 开发痛点的精彩评论。

“任何构建大型 Web 应用程序的人都清楚这一点。十年前，我们有 ASWing、JSwing 以及许多其他实际的框架，你不需要在嵌入在其他逻辑中的大量逻辑的模板中捣鼓。但多亏了苹果，我们仍然被这种糟糕的 Javascript/HTML 范式所困扰，它在 90 年代最初只是为了嵌入一些动画 GIF。是的，它有所改进（我从 90 年代就开始做了，所以我知道）。但它太不优雅了。在某种程度上，这只是开放 Web 标准的问题。如果任何一家公司真正主导到可以编写一个封闭的标准，那会更好，因为它至少会是一致的且跨平台的。2010 年编写 Web 应用程序比现在容易得多，而且我想到如果 Flash 能一直存在，我可以避免多少个小时重复造轮子的工作，这让我很痛苦。现在完全在 Canvas 上编写的任何应用程序只是在复制一个十年前就存在的虚拟机，而那时它是一个成熟得多的生态系统——并且比现在的 Canvas 或 WebGL 速度更快。”

Python

与 Java 开发社区成员类似，Python 开发人员今天也面临着从 Python 2（于 2000 年发布，现被视为遗留代码）迁移到 Python 3 的多重困难，面临兼容性问题以及将过时的 Python 代码迁移到新平台的需要。

用户 Chris2048 指出：“我认为这种情况因此被处理不当。Python 3 basically 是另一种语言，与 Python 2 类似。称其为 Python 3 是营销手段：不是创建一种新语言来与 Python 2（以及所有类似语言，例如 Julia）竞争，而是利用/羞辱现有的 Python 2 社区来支持新事物，最重要的是，Python 2 被其维护者杀死了（而不是移交），所以它无法与 Python 3 竞争，用户将被迫迁移到其他地方，Python 3 是最容易的。如果它 properly 是新语言，他们就可以更自由地修复问题，例如单一的官方包管理器。并且迁移到 Python 3 将更多是通过同意，而不是强迫。”

Electron

使用 Electron 编写的应用程序，这是一个允许开发者使用 Web 技术创建跨平台原生应用的流行框架，是导致当今 Web 解决方案整体性能下降和延迟增加的主要因素。自2013年发布以来，Electron 在行业中的普及度一直在稳步提升。许多非常受欢迎的应用程序都是用这个框架构建的，包括 Slack、Skype、Visual Studio Code、WordPress Desktop、WhatsApp Desktop、Atom 等。Electron 应用的主要问题是它们非常消耗内存，运行时会消耗大量的 RAM。这是因为每个 Electron 应用实际上都是一个带有 Node.js 服务器作为后端的独立浏览器窗口。

自然，软件开发者非常清楚 Electron 的问题性质以及使用此解决方案的所有缺点。

用户 briandear 疑惑道：“我不确定 Electron 的意义是什么：一个资源消耗大的应用，实际上就是一个包装过的 Web 应用。而不是编写利用这些平台的力量和功能的特定平台应用，我们得到的是一个万金油，一无是处。Electron 是一个商业决策，而不是一个开明的技术决策。Electron 为用户增加了什么价值？我敢说没有。Slack 竟然找不到资源为 Mac App 编写真正的 Swift，这让我惊叹不已。我们实际上是在与一个最低公分母的 Web 应用进行交互。写一个聊天应用原生这么难吗？”

用户 brundolf 表示：“15 年前，人们在那个混乱的 Web 标准时代构建 Web 应用。浏览器，即使是好的浏览器，也不会自动更新。世界上大部分地区仍在使用 IE，而 IE 为了锁定用户，积极抵制 Web 标准。那时没有 Babel 来平滑粗糙的边缘，也没有 polyfill。即使是存在的标准，当你获得使用它们的机会时，它们大多也很糟糕。我想，考虑到所有这些，我们可以支持较新的 Chromium 和最新的 Safari，如果这意味着要增强 Web 的多样性并节省数量级的 RAM 和存储空间。”

许多 Web 开发人员还 指出 Electron 代码库在当今标准下已过时：“它八年前就发布了；从那时起，Web 已经发生了很大变化。Edge 直到 2015 年才出现，更不用说用于 Web 视图了。”

开发者生产力正处于螺旋式下降；这必须扭转

回顾最常见技术栈的开发者痛点的目的是表明，当今软件开发确实正经历一个充满挑战的时期：一场生产力危机。

我们必须解决和解决它，以便我们能够前进。听起来可能陈词滥调，但危机总是伴随着机遇。在我们的案例中，机遇在于以正确的心态处理开发过程，并选择旨在解决此问题的软件开发工具，从而引领开发者生产力的新时代。Embarcadero 的 RAD Studio，一个以“一次编写，随处编译”方法为中心的快速应用程序开发包，就是这样一种工具。采用它可能是提升开发者生产力并缓解这些痛苦的一种方式。

软件开发中的生产力意味着什么？

但首先，我们需要明确生产力究竟是什么。在软件开发中，我们将生产力视为开发者生产力、业务功能、应用程序灵活性和产品性能的总和。

为了解决生产力危机，行业经历一些思维转变可能与选择正确的工具同样重要。具体来说，公司需要采用更健康的软件系统开发和维护预算方法。

在估算软件项目成本时，重要的是要预算并认识到不仅要考虑开发人员的工作成本，还要考虑用于构建和维护软件的工具的重要性。采用免费但耗时耗力的开源开发工具，可能由于开发者生产力损失而导致巨大的长期费用。

不幸的是，许多公司今天在长期开发成本规划和战略性思考方面似乎极其短视和粗心。未来的维护、易于测试以及应用程序履行其目的的能力都是隐藏的生产力成本。对它们视而不见是全方位但优化不佳的解决方案在行业中日益受到重视的原因之一。

在不陷入技术债务积累和不必要的栈过度复杂化陷阱的情况下实现高开发生产力的一种方法是，在可以部署的平台上构建可扩展且灵活的应用程序。

生产力提高的另一个关键组成部分是优先考虑旨在实现高性能的软件开发框架和库。Embarcadero 的RAD Studio等集成软件开发工具链从多个角度解决此任务，通过降低代码复杂性、满足业务需求、提供应用程序灵活性和巩固产品性能来加速开发者生产力。

能否用更少的代码改进软件？

如果我们必须列出软件开发者为了在新时代数字技术中取得成功而应该坚持的最重要原则，那么认识到编写更少代码的重要性无疑将占据最靠前的位置。

成功的开发者知道，减少代码量是更具生产力并以智能、战略性的方式最大限度地缩短开发时间的方法。它还使企业能够长期保持其系统的可持续性，而不会使维护成本滚雪球式增长。

成功的开发者知道，“更少代码”范例可以减少过度复杂性，并使技术栈更容易被所有人理解。

成功的开发者知道，编写更少的代码对于控制如今迅速上升的软件测试和维护成本是必要的。

拥抱简洁并避免不必要的复杂性是未来实现高生产力的基本要求。开发者可以通过使用易于阅读、编写和学习的编程语言；采用低代码技术；以及利用最初为解决上述问题而创建并提高开发者生产力的强大工具链来应用这些原则。

Embarcadero 的RAD Studio将“更少代码”理念作为平台的基本原则之一。它旨在为开发者提供易于阅读、编写和学习的语言；集成工具链；低代码技术；以及多平台部署的组合，最终能够实现高达 X5 的开发者生产力提升。

您准备好迎接新的生产力时代了吗？

随着开发者生产力下降的危机日益加剧，我们将在不久的将来不可避免地看到这种问题的更多表现。当务之急是采取更明智的方法来构建、测试和维护软件产品，以避免落入这个陷阱。

您准备好迎接软件开发的未来了吗？免费试用 RAD Studio 或申请产品演示。