ACM通信

实践

静态分析驱动开发工具的以人为中心的方法

由扎纳迪姆
ACM通信，2022年3月，第65卷第3期，第38-45页
10.1145 / 3486597
评论

在开发工具的设计中正确地利用静态分析技术依赖于对人类直觉的理解。该领域的研究进展不断打开了关于可以派生出关于程序运行时行为的信息类型的可能性。将这些信息提炼成一组对开发人员有价值的见解，不仅取决于问什么是计算上可行的，而且还取决于问什么是在解决复杂问题的背景下直观和有用的。

通过静态分析可以得到几种结果，包括但不限于检测异常、安全漏洞、死代码和其他可能的优化。理解如何将这样的输出转化为有效的界面——增强软件工程的经验、人机工程学和可用性——直接影响静态分析研究在未来软件开发中的成功应用。

通过应用属于静态程序分析的几种技术，用于创建软件的工具和过程可以从根本上改变。考虑到软件对我们世界的净影响，改进开发工具可以加快人类进步的步伐，但前提是要基于对人类心理的深思熟虑的理解。

考虑到软件工具、抽象和语言设计的总体经济、社会、政治和环境影响，在不以人为中心的方法为基础的情况下推进面向静态分析应用程序的开发人员的机会成本太高，不容忽视。开发人员工具有助于人们进行决策。创建有效的工具是基于对用户及其需求、挑战和盲点的清晰认识。

虽然用户行为通常不是推进静态分析的中心，但不使用以人为中心的方法开发的应用程序可能会重现(如果不是加剧)当前工具的局限性。清晰度的提高提高了代码的技术严谨性，从而使重点更多地转移到代码底层的思想和这些思想传播的速度上。减少繁琐的工具或低效的工作流程带来的认知负荷，可以让人类自由地进行更高层次的思考和推理。因此，静力分析应用的进展应以支持人类决策为目标。

回到顶部

软件工程越来越复杂

自20世纪50年代初开始以来，编程语言已经发生了巨大的变化，在它们的发展过程中，出现了一门致力于创建软件的完整学科。软件工程继续成熟，不仅作为一种实践，而且在工具、过程、艺术状态、专业性、经济和文化方面也是如此。在这一点上，很明显现代软件工程已经变得多么复杂。这种复杂性是许多因素共同作用的结果，更广泛地说，是行业中的一种趋势，即倾向于积极的发布周期，而不是深思熟虑地关注对最终用户的预期和防止后果。

在构建面向开发人员的工具的环境中，最终用户是软件工程师，新工具和技术进入生态系统的速度可能很高。这些工具通常会向工作流引入特定的微优化，以换取更高的整体复杂性。服务的激增、现成的api、不一致的标准以及开发人员每天必须跨越的语言边界，使得现代开发工作流站不住脚。

具有讽刺意味的是，越来越多的工具和服务试图帮助开发人员，但却常常带来更多的噪音、混乱、移动部件和复杂性。更糟糕的是，这种复杂性在智力上并不丰富。执行简单的操作需要工具之间的大量协调。这种忙碌的工作利用了有限的认知资源，并已被证明在面对更重大的问题时，会导致更大的决策疲劳。²⁸

复杂性的风险远远超出了它对软件工程师工作条件的影响。设计用于大规模操作的安全关键系统可能会因代码复杂性而产生意想不到的后果。2003年，一份针对丰田的诉讼揭露了一个不可维护、不可测试的代码库是如何导致失效安全缺陷，导致车辆在运行过程中失去油门控制，从而导致意外加速。²⁷产生这种结果的原因是代码中的几个反模式，例如使用10,000个全局变量和单点故障。系统的复杂性使得代码不仅难以调试，而且也不可能规范。由于该系统的复杂性，美国国家公路和交通安全协会无法调查该系统。

然而，诉讼正在演变。最近，一家法院裁定，被告有权检查用于提供不利于被告的证据的源代码。⁵随着法律后果的增加，企业承担起了更大的压力，需要对自己的法规负责。

可以使用静态分析应用程序来增强开发人员工具，以管理这种复杂性。这里有一些问题需要回答:程序是否有安全漏洞?程序最坏情况下的执行时间是多少，它还能进一步优化吗?是否存在任何常见的运行时错误，例如除零或数值溢出?

静态分析在运行时为所有可能的输入提供关于计算机程序行为的问题的答案，而不运行它们。

回到顶部

以人为本的设计与程序行为理解

关于代码的更多信息是有用的，但人类需要的是一个与他们的直觉相匹配的界面。长期以来，面向消费者的应用程序一直奉行尽可能贴近人类本能直觉的做法。为了构建直观的应用程序，开发人员通常借鉴用户体验(UX)、可用性、用户界面(UI)设计、人机交互(HCI)和认知科学等领域的研究和最佳实践。尽管在过去的几十年里，这些学科已经有了相当大的发展，但在面向开发人员的工具领域，设计思维的缺乏是显而易见的。这通常是在理解人类如何思考方面优先投资的结果，这可以说是正确利用静态分析的最重要的先决条件。

这些学科对设计的影响各不相同。用户体验定义了个人与系统交互产生的整体感知、情感和判断。²³这种感知受到许多方面的影响，比如它有多令人愉快，以及它的可用性:一个系统能够多么容易地实现它的预期目的。可用性被定义为有效性、效率和满意度的度量。¹³它通常通过一组启发式方法进行评估，比如Jakob Nielsen的界面设计10个可用性启发式方法。²²用户界面指的是用户可能与之交互的任何东西，如视觉元素、键盘按钮、声音和灯光。为此，UX包括但不限于可用性和UI。人机交互是一个学术研究领域，通过结合心理学、认知科学和人为因素，应用实证研究来更好地理解用户体验。¹⁴理解这些领域之间的差异可以确保适当地应用每个学科的相关技术。

人机交互和静态分析的交集很重要，因为软件工程需要对程序行为的理解。随着软件范围的扩大，代码容错、可靠和高质量的标准也在不断提高。然而，高质量软件到底意味着什么仍然是一个备受争议的话题。考虑到语言的广度、问题领域、程序以及与每种语言相关的不同程度的复杂性，定义质量可能会有很大的不同，因此认为最好的工具和过程可以实现它。无数的“最佳实践”淹没在软件工程经典中，以跟上迅速出现的新技术和新语言的步伐，这些新技术和语言得到采用，而且常常相互矛盾。

考虑到什么是正确的流动性和什么是错误的不确定性，程序员必须保持警惕，以确保正确地确定当前的优先级，并确定将这些优先级转换为实现的最佳方法，以平衡潜在的质量因素，如性能、可读性、大小、成本、可维护性、安全性和其他竞争的权衡。要做到这一点，程序员必须理解每个决策的含义，这需要理解程序行为。然而，由于各种各样的原因，理解程序行为仍然是困难的。

回到顶部

上下文切换是理解程序行为的障碍

阻碍开发人员理解程序行为的一个障碍是生产所需的大量上下文切换。软件工程师花费更多的时间来构建心智模型和检查假设，而不是编写代码，但是在这个过程中，他们通常没有足够的工具来支持他们。决策所需的信息可能很难识别，更不用说访问了。当程序员确切地知道哪些信息是相关的时，这些信息往往分散在各种不相关的来源中，这些来源必须被参考，并以一种最能反映问题的方式融合在一起。

众所周知，语境切换会增加错误率，降低工作效率，因为它会在连贯的思路中造成危险的中断。任务切换已被证明会降低主要任务的性能，导致更高的错误率，或花费更长的时间来完成任务，或两者兼而有之。分散注意力对记忆的编码和提取都有破坏性的影响。²⁹现代软件工程不仅需要重要的上下文切换来实现任何有意义的事情，而且这个信息寻找之旅经常被分散注意力和毫无结果的兔子洞所困扰，即使是在这方面经验最丰富的人也可能陷入其中。

考虑到上下文切换的影响，伴随表格展示了所使用的数字和物理工具的融合，有时是同时进行的，以促进软件开发。

表格用于促进软件开发的工具。

在这个信息寻找之旅的最后，即使程序员在跨越多个上下文时以某种方式成功地保持了连贯的思路，检索到的信息本身可能是不正确的或不足的。这个过程不断重复，直到获得足够的信息，从而对正在发生的事情和接下来必须做的事情有一个合理的理解。然而，如果缺乏足够的工具，程序员可能会使用这些信息来做出不正确的评估。当程序员只是想可视化控制流或评估依赖关系之间的影响时，复杂的代码路径、不可靠的验证系统、不靠谱的测试和乏味的过程留下了很多不足。

支持创建心智模型的糟糕接口也扩大了生成的源代码和生成结果所需的劳动力之间的差距。在跨越平台和语言的问题上，状态和控制流的可见性也降低了，因为每种语言都有自己的工具集支持。虽然语言服务器协议(LSP)是为语言编译器之间通信提供一种通用语言的一种尝试，但由于所需的开销，很少有编辑器支持解锁LSP跨平台能力的集成。

由于没有文件，这种资料分散或不足的问题更加严重。记录一切通常太过繁琐，因此它成为了仅次于编写代码的活动。在这种情况下，决定的理由仍然不清楚。代码库新手积累信息的效率要低于使用现有工具更好地进行学习时的效率。

背景切换已经增加，尤其是在高频协作已成为常态的情况下。虽然异步通信工具是为了帮助连接工作人员而设计的，但它们通常被同步地用于实时对话。这导致了工作场所的文化，有形的活动往往与生产力相结合。持续不断的通知不仅创造了一种人为的紧迫感，而且也破坏了编程所需要的深度专注。研究一致表明，当任务被打断时，个体会经历明显更多的压力、焦虑和易怒。²¹研究还表明，在被打断后，员工有41%的时间不会继续他们的主要任务。²⁴平均而言，试图在中断后恢复一项主要任务需要多花25分钟。¹⁹当上下文切换的认知负荷很高时，正确性和安全性自然会受到影响。

回到顶部

设计良好的抽象改进人机交互

任何设计良好的系统(不仅仅是软件)的目标都是确保相关知识在适当的时间和地点可用。纵观其历史，计算机科学通过抽象的设计和实现来解决这一目标。抽象有助于将大量信息分发到子系统中，其中每个组成子系统都有一个专用的目的。一层层的抽象填补了人类和机器之间的鸿沟，每一层都将概念概念转化为1和0。

设计良好的抽象和语言可以帮助阐明程序行为。抽象将重点放在与问题域最相关的层，隐藏被认为不重要的信息。不幸的是，确定什么是重要的就像“质量”和“最佳实践”的话题一样有争议。正因为如此，抽象的设计往往更像是一门艺术，而不是一门科学。创建正确的边界并在每一层表达适当的信息对于提供最适合上下文的有用信息至关重要。抽象也可能适得其反。他们可能太不透明了，为了提高什么是最重要的信号，他们最终隐藏了太多。

“抽象的目的不是模糊，而是创造一个新的语义层次，在这个层次上人们可以绝对精确。”——Edsger W. Dijkstra《卑微的程序员》，1972年ACM图灵讲座

抽象设计的压力就像那些使用静态分析来构建开发人员工具的压力。突出适当的细节是很重要的。虽然某些上下文需要更细粒度的精度，但更详细的内容并不总是有利于更容易地导航和检查大量代码。一方面，用户可能会被淹没在大量的指标中，这些指标可能会导致决策瘫痪，或者将注意力引导到没有意义的数据上，从而导致牦牛剃毛和微优化。另一方面，也存在隐藏重要信息或引入产生不良结果的自动化的风险。细节和概括性之间的张力是每个问题所特有的，必须这样协商。

回到顶部

为什么HCI被剥夺优先权?

虽然很难准确地指出为什么在面向开发人员的工具的设计中以人为中心的方法不那么重要，但下面的猜测探讨了可能发挥作用的文化方面。

偏向于编译器和编程语言。专注于静态分析的学者往往是编译器研究人员和编程语言理论家，他们的兴趣和专长倾向于研究语言能力、表达代数、解释器和算法设计。由于它们的专门化，对可用性和HCI的讨论往往是有限的。此外，静态分析的思想在计算机科学文献中存在的时间比研究人员在现代系统中探索其局限性的时间要长得多。因此，专注于从代码中提取什么见解的研究与这种见解可以缓解的UX挑战之间存在脱节。

虽然越来越多的积极研究关注于使用HCI来帮助人们更好地理解代码，但这项研究大部分仍然与静态分析应用程序无关。¹⁰在任务分析方面的研究，虽然能够描述过程性知识来衡量各种接口的有效性，但仍然与开发人员工具中的静态分析技术的实现分离。

不太可能精通设计的工程师。前端工程师可能在设计方面有更多的专业知识，或者产品工程师可以熟练地构建一个商业案例来证明他们的工作，与此不同的是，致力于将静态分析工具推向市场的工程师通常来自学术界的角落，他们受雇于的角色往往更局限于算法设计、规模和基础设施。考虑到他们的专业知识，他们可能不会优先考虑利用经验用户研究或可用性来验证他们的假设的设计过程，导致不那么直观的实现。

由于他们的专业性，他们还优先考虑技术正确性，而不是与领导者和涉众沟通业务价值主张，沟通可以带来更多的组织支持和设计资源。除非它对用户和业务的价值被清楚地传达，否则以概念证明形式存在的功能代码体是毫无意义的。即使大量的工程投资被投入到一个原型中，对这些工作的有效性的怀疑也会增加，这样的项目可能会因为缺乏必要的外部支持而成为孤儿。由于大多数静态分析技术也很昂贵且难以扩展，因此这项工作的合理性就降低了。

缺乏一致性和标准。现代软件工程提供了独特的调试挑战，这源于缺乏一致性和标准。尽管开源软件在历史上因缺乏标准化而受到指责，专有软件也同样造成了不一致性。这是因为标准在受到市场力量的青睐时才会有机地出现，而不是通过标准委员会系统地制定协议。²

---

在一个充斥着快速变化的api的跨平台世界里，实现有用的图形用户界面变得非常困难。

---

在竞争激烈的市场中，这意味着公司会有更大的动机去发布经济上最可行的内容，即使最终的开发者体验结合了各种越来越不相关的工具。考虑到广泛的标准化和领域特异性之间固有的紧张关系，实现一致性也很困难。应用领域的多样性，以及硬件技术新发展的步伐，使得开发一种算法世界语变得困难和不切实际，因为不同的抽象意味着服务于特定目的的问题。¹¹

软件工程就是关于代码的。软件工程需要大量的非编码任务，但是代码的产生本身比支持高质量产品所需的中间工件更重要。一心一意地编写代码会产生一种生产力的错觉，并在局部最大值范围内掩盖次优的方法。结果，支持更细致的思考和更好的软件开发的辅助练习，如产品规划、项目管理、文档或以人为本的设计，如果有的话，做得很差。

当前期系统设计很少甚至没有时，体系结构就不太可能有清晰的界面来分离功能并允许更容易的调试。由于将代码结构成专用组件的组织较少，工程师需要维护更广泛系统的心智模型，这增加了人为错误的风险。当执行设计和规划任务时，它们通常没有像编写代码那样被赋予那么多的重要性，并且得到的投入和时间也较少。当低质量的结果反映了非编码任务优先级的降低时，它只会助长业界的确认偏见，即所有代码之外的工作都是徒劳的“自行车屏蔽”。可以支持非编码软件工程任务的工具受到了阻碍，考虑到使用它们会带来耻辱，这并不奇怪。

速度和迭代重于质量和战略思考。当最重要的成功衡量标准是发货速度时，质量就会退居二线，捷径就会得到回报。通过任何必要的方式部署到生产中比进行任何初步的尽职调查更有价值，这可以为团队节省几个月(如果不是几年的话)的时间和精力。在他的书中,高输出管理在美国，安迪•格鲁夫(Andy Grove)将这种现象描述为“活动大于产出”(activity over output)问题，即忙碌与富有成效的结果混为一谈。⁹Joel Brandt等人在他们的论文“机会编程:在实践中如何快速构思和原型”中描述了迭代如何导致短视的选择。当代码迭代比任何事情都重要时，研究表明文档、系统架构和代码重用会受到影响。⁴

虽然快速迭代、快速交付和收紧的开发周期可以提供对用户行为的巨大洞察，并开辟一条渐进的前进道路，但预先应用的设计思维不足也会损害进展。目光短浅会导致更多的bug，更大的技术债务，以及对内部开发人员经验的有限思考。迭代还施加限制，并将系统的演化困在局部最大值内。我们可以在John Conway的纸牌游戏“生命”中看到迭代如何影响结果中看到这种局部最大值的类比。初始状态决定了模式如何在后代中进化。⁸虽然像“快速行动，打破常规”这样的陈旧口号已经被越来越多的人所接受，因为简化主义的措辞可能会造成危险的疏忽，但我们需要一个重大的意识形态转变来重视长期关注和深思熟虑的类型，这将在某一天逐渐成为给予开发人员经验的更高优先级。

HCI等同于表面的一层油漆。HCI及其子字段与表面层次的视觉细节(如图标、颜色和字体)错误地合并在一起。当然，HCI远不止于此;它与用户遇到和感知的一切有关。HCI定义了显示什么信息;它是如何构成的;它的意义、用途和时机;以及什么时候可以对它做出回应。HCI还包含了研究实现有效性的技术，这可能包括它的可学习程度，特定的任务由于给定的实现而变慢或变快多少，以及用户会犯什么错误以及他们遇到这些错误的频率。

对黑客文化的颂扬。随着几家行业先锋企业将自己的成功归因于“颠覆性”做法，这些做法与传统的官僚主义背道而驰，一种对流程和结构的强烈蔑视开始出现。虽然放弃某些形式的僵化对公司很有好处，但将组织流程视为与创造力对立的东西会带来不同的问题。创业公司不仅挑战了职场规范，还表明传统教育的重要性降低了。减少对资格认证的强调是积极的，可以从比以前更广泛的人才库中抽取人才。但是，对教育的漠视也扩大了企业和学术机构之间的差距。

随着时间的推移，这导致了对计算机科学研究的更大的无知，并减少了与现有的学术思想谱系的联系。长期问题的解决方案往往是半生不熟的，而且与几十年的研究无关。这导致开发人员工具被构建为一系列微调整和反应，而不是整体系统。当E.F. Codd提出关系设计模型时，他的建议得到了坚实的理论支撑。⁶现代开发实践提供了很少的例子来演示计算机科学研究的原则性应用。

看门人文化。一些代码库依赖口述传统，使得知识转移很困难。因此，参与一个给定的系统更具挑战性。当工程师有动机保持复杂性作为一种工作安全的手段时，糟糕的组织动态可能会放大这一现象。当没有其他人能够仔细检查一个给定的系统时，它就不太可能受到质疑，而那些真正熟悉它的人可以利用它成为不可或缺的。在需要工程师在头脑中储存更多信息的系统中工作，被视为一种荣誉勋章，而不是设计失败。

UID的挑战。底层技术挑战影响用户界面设计(UID)一个充满快速变化的api的跨平台世界使得实现有用的图形用户界面变得困难。命令行界面(cli)的设计有其自身的挑战，因为在根据开发人员已经熟悉的遗留系统和标准(如Linux)进行设计(即使这意味着继续存在已建立系统的UI失败)与构建新系统(这减少了认知开销，但迫使用户学习新东西)之间的持续紧张关系。

如果没有考虑周到的设计来平衡一致性和可用性，就会有强加简化方法的风险，这会增加障碍。这方面的一个例子包括一个面向对象UI的提议，它通过将计算框架应用于图形表示，扭转了以人为中心的设计思想。¹⁷即使面向对象框架是基于拟物化的时尚，以类似于人类日常生活中与之交互的对象来表示信息，它也与人类的经验相差了几度。不是所有的问题都是面向对象的。这再现了一个问题，即采用一个框架并将其与人类认知相适应，而不是对心理过程的直觉。

非常复杂的生物。无论应用领域如何，理解我们自己的神经症本身都是一项困难的任务。在承认人类心理多样性的同时，对像编程这样复杂多样的活动这样做就更加困难了。

回到顶部

以人为中心的数据

以人为本设计的重要性有很多证据。复杂信息的框架和表达会影响人们理解信息的速度和解决问题的效率。这些想法在数据可视化领域已经被接受了很长时间，该领域的重点是推动统计数据的图形表示，最好地映射出人类直观的思维方式。

弗洛伦斯·南丁格尔(Florence Nightingale)的工作是一个著名的历史例子，它展示了数据可视化的力量。1854年克里米亚战争期间，南丁格尔是一家野战医院的护士长，负责调查异常高的死亡率。她指出，死亡原因是卫生条件差、排水不良和水污染。她的工作最引人注目的不是数据收集或统计分析，而是她展示自己发现的方式。她开发了一种现在通常被称为饼状图或极地区域图的数据可视化类型，在报告中阐述了患者死亡率的来源，印度皇家委员会(1858 - 1863)。传统的统计报告不太可能被有影响力的领导人或忙碌的政治家理解，他们可以根据这些信息采取行动，但由于这张图表以一种易于使用的格式有效地传达了密集的数据，Nightingale的工作推动了卫生设施的变革，导致死亡率从42%下降到2%(见附件)数字)．¹⁵

图。1858年由弗洛伦斯·南丁格尔绘制。

这个例子表明，更多的信息并不总是足够的。即使静态分析展示了代码的“事实”，它也不会提高工程师根据这些事实采取行动的能力。为了最有效地交付关于软件系统的信息，必须很好地理解人与代码之间交互的动态。这样做需要加深对认知和记忆的理解，并识别现有的信息是如何通过糟糕的设计选择变得不透明的。

《牛津在线词典》对认知的定义是“通过思想、经验和感觉获得知识的心理活动或过程”(https://en.oxforddictionaries.com/definition/cognition)．认知过程包括看、听、读、写、记、学和做决定。记忆是人脑编码、存储和检索信息的过程，是逻辑推理和语言关系发展所必需的。由于关于人类记忆如何工作有不同的理论，比如记忆的双重理论，一些程序员遇到了短期记忆的局限性，¹我们需要问的问题是:如何理解认知和记忆理论，并将其整合到支持软件开发的交互设计中?

工具使隐性知识变得明确。学习新的编程语言和熟悉新的工具或代码库通常需要克服陡峭的学习曲线。理解概念和变得富有成效所需的努力会随着时间和实践而减少。在与编程相关的任务中，暴露问题，以及与实践相伴随的经验是至关重要的，因为这些无形的隐性知识很少通过工具显现出来。

隐性知识指的是支持编程任务所需的直觉、肌肉记忆和洞察力，它们通过经验深深嵌入大脑，很少出现在意识中。这意味着经验丰富的程序员可能知道什么工作,但不是为什么而不能把这种智慧转译给别人。相比之下,显性知识是被有意识地认可并转化为指导方针的信息。最佳实践就是显性知识的一个例子。

开发人员工具可以通过使隐性知识更加明确来促进程序员的行为。但是什么是好的软件工程的最佳实践，以及如何将这样的行为结果设计到工具中?可用性启发法是弥合这一差距的一种方法。¹²

“电脑擅长遵循指令，但不擅长读心术。”—Donald Knuth的TeXbook, 1984年

使隐性知识显式的一种方法是将可获得但对用户隐藏的数据显示出来。这包括大多数语言的编译或解释步骤所需的信息。使用HCI提出这些信息可以阐明许多工具和语言设计中的疏忽所导致的许多歧义，例如错误消息和前端cli的设计。错误消息通常要求用户推断出比他们应该推断的多得多的内容。在诊断错误和适当地对错误作出反应方面的熟练程度会影响您在代码库中的生产效率，但是这种技能的大部分是通过大量的实践逐步建立起来的。

与其要求开发人员手工筛选冗长的日志，将错误源与解决方案连接起来，并随着时间的推移学习模式匹配，还不如应用可用性原则来提高信噪比并改善调试体验。在这个设计领域有几个活跃的项目。旨在改善开发者体验的项目包括重新思考Elm中的终端用户体验，⁷Lambdabot被用来为Haskell提供教学指导，¹⁸或Agsy，一个外部程序，用于帮助搜索语言Agda中满足规范的程序。^3.

编程语言的选择对思想的形成也有巨大的影响。几项研究表明，自然口语和思维模式之间有很强的关系。^20.心理语言学是一门研究语言如何习得、使用和理解的学科，该领域的见解适用于口语和计算机语言。类似地，给定的计算机编程语言的表达能力可以决定程序员完成什么以及如何完成。语言选择会影响思维过程，并决定您拥有哪些信息以及在操作这些信息时控制的粒度。¹⁶

虽然各种编程语言的相对优势存在许多争论，但大多数语言社区都有旨在以某种方式改善用户交互的活跃项目。类型化语言经常被吹捧为具有编译时保证的优势，并且能够通过IDE中的提示和文档提供更清晰的信息。

然而，类型本身是不够的。它们只在利用它们提供的信息的用户体验方面发挥作用。如何有效地使用和交流类型信息可以减少对复杂静态分析的需求。比较Haskell的错误消息与Rust或Elm提供的错误消息在体验上的差异，可以看出用户体验的不同，而不是类型系统的不同。还有一些用于可视化动态语言的执行信息的工具示例，如Python Tutor²⁵或者Rust Analyzer，它提供关于Rust代码的洞察，并支持编辑器功能，比如自动完成和跳转到定义，并提供与状态相关的语义信息。²⁶

回到顶部

未来取决于良好的人机交互

在人类历史上相对较近的发展中，软件已经产生了惊人的影响。随着这种影响的扩大，人为错误的风险也会加剧。在这个世界上，复杂和不透明的系统根本无法伸缩。开发工具和实践的以人为中心的方法对于确保软件的安全扩展是至关重要的。对人类行为的深入了解可以提高可靠性，扩大贡献者的范围，并提高结果的质量。

静态分析可以揭示关于程序行为的重要信息，但获取这些信息的目标不应该是积累吹毛求疵的细节。确保信息和过程的相关性和有效性需要对人类行为的敏锐意识和对开发人员工作流程中现有挑战的承认。

HCI可以帮助将静态分析技术引导到面向开发人员的系统中，这些系统结构信息，并将关系体现在紧密反映程序员思想的表示中。所有好的工具都可以扩展您的能力，开发人员工具可以被看作是人类思维的假肢。

就像交流对人类的进化生存至关重要一样，伟大的软件的生存依赖于编程语言，这些语言支持而不是抑制交流、推理和抽象思维。长期以来，人们一直认为编程促进了交流，不仅是人与机器之间的交流，而且是人与人之间的交流。使用以人为中心的框架来利用静态分析技术可以将现有开发人员工作流程的参差、断开的碎片平滑为更连贯、无缝的体验。

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2022 ACM股份有限公司

---

没有发现记录