观点
PDFIDE 的困境
Jef Raskin
题词：“我们可能感受不到这些局限性，直到它们从我们身上被解除，正如我们常常不知道自己生病了，直到突然感觉好转。因此，有理由期望未来的语言会让我们感受到[我们当前环境]的那些今天无法察觉的局限性。” --Gerald Weinberg
来自人机界面领域的专家和权威人士的布道正在慢慢地说服管理层、软件设计师——甚至程序员——更好的人机界面可以通过加快工作速度、减少学习时间、减轻人类记忆负担以及缓解用户的身心压力来提高生产力。
这一切听起来都不错，并且很多已被证明是真实的，但如果它真的那么好，那么为什么人机工程学专家自己不使用更好的界面呢？当他们写作时，大多数人使用 Microsoft Word（参见侧边栏）。当他们编程时，他们使用与我们其他人相同的集成开发环境 (IDE)。我们看到很多人努力撰写关于如何使 Web 设计有效运作的书籍（尽管在网上冲浪时，我不确定是否有人在阅读所有这些书），但根本没有人致力于改进 IDE。这样的改进将提高编程的质量和速度，这显然是一个理想的目标。
那么 IDE 到底有什么不好呢？长期以来，它们一直存在问题。如果您认为只是最近才开始关注这方面的人为因素，请允许我再次引用 Gerald Weinberg 1971 年出版的著作《计算机程序设计心理学》中的话。该书的既定目标是“引发一个新的研究领域的开始：作为人类活动的计算机程序设计”。他认为，“如果我们能够采纳心理学的观点，那么在我们的硬件和软件设计方面，也可能取得巨大的进步。”
他是对的。
Weinberg 的书仍然值得一读：他的一个观察是，“与小说不同，阅读[程序]的最佳方式并不总是从头到尾”。阅读大多数程序感觉就像在解决一个谜题：你必须小心翼翼地进入，回溯，重新思考，并且（如果你使用的是纸质文档）做一些旁注。Donald Knuth 在 1984 年的一篇文章中，后来发表在名为《文学编程》（1992 年）的书中，找到了一种使程序能够从头到尾正确阅读的方法。Knuth 的创新之处在于以对人类有意义的顺序编写程序，然后通过或多或少自动化的过程将其放入编译器或解释器运行程序所需的任何序列中。他还提倡并提供了使文档编写更简单的机制。
我自己在同一方向的发展始于 20 世纪 70 年代我在 Apple II 上工作时。在我的方法中，程序段嵌入在文字处理文档中——就像蛋糕中的葡萄干一样——因此重点是解释而不是代码。一个简单的预处理器为编译准备代码。Susan Lammer 1986 年出版的《Programmers at Work》一书中就出现了一个这样的程序示例。这个问题至少已经显现了三十年。
大多数当前的 IDE 使添加注释变得困难，有时甚至痛苦：您经常需要手动换行注释，这会抑制段落长度的解释，或者至少会抑制它们的编辑。在 21 世纪的产品中看到如此古老的界面真是令人难以置信。
内部文档的问题不是一个小问题。对于许多程序来说，段落几乎不够用； essay 长度的文档将是合适的。在维护程序时尤其如此。很少有程序员能够充分解释他们的代码，以至于阅读它不会令人难以置信地沮丧。很大一部分问题是，今天程序中只有一小部分是由编写来实现规范的代码组成。程序员所做的大部分工作（正如 Weinberg 所意识到的那样）包括用于绕过硬件和软件限制、冗长的声明以及系统或语言设计以及其他障碍所需的其他形式的技术。程序员很少在他们的注释中注明选择特定技术是为了适应特定硬件配置的要求或绕过编译器怪癖。
有些语言几乎无法记录（更不用说它们自己很少附带足够的文档，从一开始就树立了坏榜样）。过去，APL 和 Forth 被认为是无法记录的语言的典范，但它们的极端紧凑性意味着一行代码通常需要一篇小论文。我管理了一个基于 Forth 的大型项目，结果非常易读且易于维护。为了实现这一点，我们定期进行代码阅读会议，其中一位程序员阅读并评论另一位程序员编写的每一段代码。此外，一位专业的文档编写员/作家与程序员并肩工作。如果他不理解一段代码，他会采访程序员，直到他能写出一个有说服力的解释。
顺便说一句，在这个过程中发现了许多错误和概念性错误，这在减少调试时间方面得到了充分的回报。一些程序员最初对这些程序犹豫不决，但当项目没有放慢速度或在接近完成时崩溃时，所有人都变得热情起来。该项目按时、按预算完成，并且没有错误（这意味着该软件已商业发布给数万用户，并且没有产生错误报告）。
更现代的语言，不但没有变得更易于维护，反而变得更难维护。这会让 Weinberg 感到惊讶（参见本文开头的题词），并且应该让今天从事或管理涉及编程的项目的任何人感到不安。Visual Basic (VB) 就是一个典型的例子。一个 VB 程序很快就会变成一堆窗口，需要费力地打开和关闭窗口才能创建一个程序或跟踪程序中发生的事情。该语言在很大程度上是非结构化的，编写程序是一种手腕麻木的体验。不仅环境糟糕透顶，而且除非您的界面将自己限制在标准的 Microsoft 小部件内，否则该语言也令人沮丧。创造力和想象力很快就会受到惩罚；任何超出界面规范的东西要么非常困难，要么根本不可能做到。考虑到被认为是 VB 设计者的人撰写了关于界面设计的书籍，VB 界面的问题及其不愿实施新的界面小部件尤其令人惊讶。
一些语言，例如 Smalltalk 及其面向对象的追随者，向我们展示了大量的类。比起游泳，更容易被淹没。Smalltalk 本身简单而优雅。在实际环境中使用它既复杂又混乱。而且，与现在的情况一样，文档匮乏。Smalltalk 和 Java 等语言的 IDE 是传统的 GUI，它们过度依赖鼠标，没有人性。这一切都不是必要的。这仅仅是习惯。
开源开发——在许多方面都是一种祝福，因为如果需要，您可以深入了解系统的内部结构——也受到为大多数开源项目做出贡献的常常缺乏纪律的大众的诅咒。几乎没有质量控制，也很少有人选择认真和专业地记录他们的工作。几乎没有人关注 IDE 的用户界面，因为参与的程序员通常没有研究过认知科学，并且没有意识到他们自己的 IDE 设计正在给他们造成困难。
计算机最真实的益处源于其大多数用户从未做过的一件事：编程。虽然永远不会有超过一小部分用户学习编程，但鉴于当今不透明的编程语言和难以理解的 IDE，这一比例几乎降至零。
学习编程的另一个障碍是惊人地缺乏手册。有大量的在线参考资料，甚至还有一些教程，但在在线指南和您尝试使用的 IDE 之间来回切换是很困难的。此外，几乎所有教程都假设您已经了解作者以前的编程语言，并且新概念都用该语言来解释。如果您不具备作者的知识库，那就再见了，宝贝。当 IDE 本身出现问题并且您无法访问 IDE 的帮助系统时，请尝试修复系统。有充分的理由拥有纸质手册，螺旋装订以便它们可以平放。
当我与学生一起工作时，我可以看到有多少时间浪费在学习复杂 IDE 的来龙去脉和特定操作系统的特性上，而不是更通用的编程技能上。毫无疑问，随着时间的推移，系统变得越来越复杂，并且这种复杂性必须至少在某种程度上反映在我们的 IDE 和操作系统中。但这绝不是使简单任务变得复杂的借口。我的儿子，当时还在小学，更喜欢在我们的旧 Apple II 而不是在时髦的新 Macintosh 上学习编程。为什么？因为他只需要输入“command-B”，他就进入了 BASIC。然后他可以输入
PRINT “HELLO”
敲击回车并看到
HELLO
显示在屏幕上。他不必编写序言、打开窗口并指定其大小，也不必进行任何其他准备工作。他可以用四五行代码画出一幅图。IDE 几乎是透明的。一个简单的问题有一个简单的解决方案。他现在是一位精通六种语言的熟练程序员，并且能够应对极其混乱的 IDE。今天开始学习的人中，很少有人会坚持攀登陡峭的学习曲线，才能到达他们学会让算法表现正常的平台。
IDE 的设计是一个亟待修复的问题。Q
凋零的 Word
Microsoft Word 几乎惹恼了它的每一位用户。不幸的是，当面对重复的刺激时，我们大多数人学会了忽略它，无论它多么令人讨厌。我们大多数人都已经开始接受个人电脑偶尔崩溃是理所当然的事。这使得任何熟悉的软件包，无论多么糟糕，都显得可以接受。
Word 就是这样一种产品。它拥有一套臃肿的命令，需要一生才能完全掌握。它需要的鼠标点击和键盘敲击次数远远超过必要的需求。它使用内存就好像内存是免费的一样——我在用来写这篇专栏文章的文字处理器中的一个 8KB 的文件，当剪切并粘贴到 Word 中时变成了 50KB。许多令人震惊且难以撤消的副作用源于小的键盘输入错误。找到我们想要调整的系统参数通常会退化为在隐藏在菜单后面的数十个灰色选项卡式对话框中寻宝，而菜单的名称并没有暗示哪个菜单会包含我们的奖品。
我们很快就会厌倦当您最不想被打扰时弹出的回形针卡通。Word 是我们的图形界面如何误入歧途的一个例子。然而，即使是大多数界面专家也使用它。
JEF RASKIN 最著名的作品是他的著作《The Humane Interface》（Addison-Wesley，2000 年）以及在 Apple 创建 Macintosh 项目。他拥有多项界面专利，为世界各地的大型和小型公司提供咨询服务，并经常被邀请在会议、研讨会和大学发表演讲。他目前的项目 The Humane Environment (www.jefraskin.com) 正在计算机科学界和商界引起关注。
最初发表于 Queue 第 1 卷，第 3 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码散列函数的标准
虽然密码散列函数和非密码散列函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全需求，存在许多针对密码散列的标准，但在非密码方面，存在一定程度的民间传说，尽管散列函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 实践
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者直观地接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发效率
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技术来为商业和社会服务，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚的 whims 的影响，并且可能会忘记或忽略针对它面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入，后来被普及，是这些成熟的解决方案之一。
© 保留所有权利。