PDF以人为中心的静态分析驱动的开发者工具
未来取决于良好的人机交互。
Ayman Nadeem，GitHub
在开发者工具的设计中正确运用静态分析技术，依赖于对人类直觉的理解。该领域的研究进展不断开启关于程序运行时行为可推导信息的可能性。将这些信息提炼成对开发者有价值的见解，不仅取决于计算上的可行性，还取决于在解决复杂问题时什么是直观且有用的。
通过静态分析可以实现多种结果，包括但不限于异常检测、安全漏洞、死代码和其他可能的优化。理解如何将这些输出转化为有效的界面——一种能够提升软件工程体验、其人体工程学和可用性的界面——直接影响着静态分析研究在未来软件开发中的成功应用。
通过应用静态程序分析这一广泛范畴下的多种技术，可以从根本上改变用于创建软件的工具和流程。考虑到软件对我们世界的净影响，改进开发者工具可以加速人类进步的步伐，但这只有在基于对人类心理学的周全理解之上才能实现。
鉴于软件工具、抽象和语言设计的总体经济、社会、政治和环境足迹，在没有以人为中心的方法为基础的情况下推进面向开发者的静态分析应用的机会成本太高而不能忽视。开发者工具促进人类决策。创建有效的工具的前提是对用户及其需求、挑战和盲点有清晰的认识。
虽然用户行为通常不是推进静态分析的核心，但在没有使用以人为中心的方法开发的应用中，存在重现甚至加剧当前工具局限性的风险。提高清晰度可以增强代码的技术严谨性，从而使焦点更多地转移到代码背后的思想以及这些思想的传播速度上。减少繁琐的工具或低效的工作流程带来的认知负荷，可以使人类从事更高阶的思考和推理。因此，静态分析应用的进步应旨在支持人类决策。
软件工程的复杂性日益增长
自20世纪50年代初诞生以来，编程语言已经取得了巨大的发展，并且伴随着它们的发展，一个专门致力于软件创建的学科也应运而生。软件工程不断成熟，不仅在实践方面，而且在其工具、流程、最新技术、专业性、经济性和文化方面也是如此。在这一点上，现代软件工程变得多么复杂是显而易见的。这种复杂性是多种因素共同作用的结果，更广泛地说，是行业内一种趋势，即倾向于激进的发布周期，而不是周全地关注预测和预防对最终用户的后果。
在构建面向开发者的工具的背景下，最终用户是软件工程师，进入生态系统的新工具和技术的速度可能很快。这些工具通常引入特定的微优化来改进工作流程，但代价是更高的总体复杂性。开发者每天必须跨越的服务爆炸式增长、现成的API、不一致的标准和语言边界，使得现代开发工作流程变得难以维持。
具有讽刺意味的是，越来越多的旨在帮助开发者的工具和服务常常导致更多的噪音、混乱、活动部件和复杂性。更糟糕的是，这种复杂性在智力上并不丰富。执行简单的操作需要工具之间进行大量的协调。这种无意义的忙碌会消耗有限的认知资源，并且已被证明会在面对更重要的问题时导致更大的决策疲劳。28
复杂性的风险远远超出了它对软件工程师工作条件的影响。旨在大规模运行的安全关键系统可能会因代码复杂性而产生意想不到的后果。2003年对丰田提起的诉讼揭露了不可维护、无法测试的代码库如何导致故障安全缺陷，这些缺陷导致车辆运行期间油门失控，从而导致意外加速。27 这种结果是由于代码中存在许多反模式造成的，例如使用了10,000个全局变量和一个单点故障。系统复杂性不仅使代码难以调试，而且也无法监管。美国国家公路交通安全管理局因其复杂性而无法调查该系统。
然而，诉讼正在发展。最近，一家法院裁定，被告有权检查用于产生对其不利证据的源代码。5 随着法律影响的增长，公司更有压力成为其代码的负责任的管理者。
可以使用静态分析应用程序来增强开发者工具，以管理这种复杂性。以下是一些需要回答的问题：程序是否存在安全漏洞？程序的最坏情况执行时间是多少，是否可以进一步优化？是否存在常见的运行时错误，例如除以零或数值溢出？
静态分析提供了关于计算机程序运行时行为的答案，针对所有可能的输入，而无需实际运行它们。
以人为中心的设计和理解程序行为
关于代码的更多信息是有用的，但人类真正需要的是一个符合他们直觉的界面。面向消费者的应用程序长期以来一直秉持着尽可能贴近人类原生直觉的做法。为了构建直观的应用程序，开发者通常借鉴用户体验 (UX)、可用性、用户界面 (UI) 设计、人机交互 (HCI) 和认知科学领域的研究和最佳实践。尽管这些学科在过去几十年中发展迅速，但在面向开发者的工具领域，设计思维的匮乏是显而易见的。这通常是由于对理解人类思维的投资不足，而理解人类思维可以说是正确利用静态分析的最重要的先决条件。
这些学科以不同的方式为设计提供信息。用户体验 定义了个人与系统交互所产生的总体感知、情感和判断。23 这种感知受许多方面的影响，例如它的愉悦程度，以及它的可用性：系统在多大程度上能够实现其预期目的。可用性 被定义为衡量有效性、效率和满意度的指标。13 它通常通过一组启发式方法进行评估，例如 Jakob Nielsen 的界面设计的 10 个可用性启发式方法。22 用户界面 指的是用户可能与之交互的任何事物，例如视觉元素、键盘按钮、声音和灯光。为此，用户体验包括但不限于可用性和用户界面。人机交互 是一个学术研究领域，它应用实证研究，通过结合心理学、认知科学和人类因素来更好地理解用户体验。14 理解这些领域之间的差异确保了每个学科的相关技术都得到适当的应用。
人机交互和静态分析的交叉点很重要，因为软件工程需要理解程序行为。随着软件覆盖范围的扩大，对代码的容错性、可靠性和高质量的要求也随之提高。然而，高质量软件 甚至意味着什么，仍然是一个备受争议的话题。鉴于语言、问题领域、程序以及与每个领域相关的不同复杂程度的广度，质量 的定义可能会有很大差异，并且认为最好实现质量的工具和流程也可能大相径庭。“最佳实践”层出不穷，涌入软件工程领域，以跟上新技术的快速涌现和语言的普及，而这些最佳实践常常相互矛盾。
鉴于 什么是正确的 的流动性和 可能出错 的不确定性，程序员必须保持持续的警惕，以确保正确识别当前的优先级，并确定将这些优先级转化为实现的最佳方法，从而平衡质量的基本因素，例如性能、可读性、大小、成本、可维护性、安全性和其他相互竞争的权衡。为了做到这一点，程序员必须理解每个决策的含义，这就需要理解程序行为。然而，由于多种原因，理解程序行为仍然很困难。
上下文切换是理解程序行为的障碍
阻止开发者理解程序行为的一个障碍是高效工作所需的大量上下文切换。软件工程师花费更多的时间构建心智模型和检查假设，而不是实际编写代码，但他们通常没有足够的工具来支持他们完成这个过程。做出决策所需的信息可能难以识别，更不用说访问了。当程序员确实知道哪些信息是相关的时，这些信息通常分散在各种不相关的来源中，必须进行查阅并将它们融合在一起，以最佳方式映射到问题。
众所周知，上下文切换会增加错误率并降低生产力，因为它可能会对连贯的思路造成危险的干扰。任务切换已被证明会降低主要任务的绩效，导致更高的错误率、完成任务所需的时间更长，或者两者兼而有之。分散注意力对编码记忆以及检索都有破坏性影响。29 现代软件工程不仅需要大量的上下文切换才能完成任何有意义的事情，而且这种信息查找之旅常常充斥着干扰和徒劳的兔子洞，即使是那些技艺最精湛的人也可能陷入其中。
为了考虑上下文切换的影响，请参考表 1，该表显示了有时同时使用的数字和物理工具的混合，以促进软件开发。
在信息查找之旅的最后，即使程序员在跨多个上下文跳转时设法保持了连贯的思路，检索到的信息本身也可能是错误的或不充分的。这个过程会重复，直到获得足够的信息来合理地理解正在发生的事情以及下一步必须做什么。然而，由于缺乏足够的工具，程序员可能会使用这些信息做出未经适当评估的决策。复杂的代码路径、不可靠的验证系统、不稳定的测试和繁琐的流程在程序员只想可视化控制流或评估跨依赖项的影响时，留下了许多不足之处。
支持心智模型创建的糟糕界面也扩大了产生的源代码与产生该结果所需的工作量之间的差距。跨平台和语言的问题进一步降低了状态和控制流的可见性，因为每种语言都由自己的一组工具支持。虽然 LSP（语言服务器协议）是一种尝试为语言编译器之间通信提供通用语言的方法，但很少有编辑器支持解锁 LSP 跨平台功能的集成，因为需要额外的开销。
在缺乏文档的情况下，这种信息分散或不足的问题会更加严重。记录所有内容通常过于繁重，因此它成为编写代码的次要活动。在这种情况下，决策的理由仍然不清楚。与现有工具能够更好地促进学习相比，代码库的新手收集信息的效率较低。
上下文切换有所增加，尤其是在高频协作变得常态化之后。虽然异步通信工具旨在帮助连接工作者，但它们通常被同步地用于实时对话。这导致了工作场所文化，在这种文化中，可见的活动常常与生产力混淆。持续不断的消息通知不仅营造了一种人为的紧迫感，而且还损害了编程所需的深度专注。研究一致表明，当任务被打断时，个体经历的压力、焦虑和烦躁感明显增加。21 研究还表明，在被打断后，工作人员在 41% 的时间内不会恢复其主要任务。24 平均而言，在中断后尝试恢复主要任务需要的时间延长了 25 分钟。19 当上下文切换的认知负荷很高时，正确性和安全性保证自然会受到影响。
精心设计的抽象改进人机交互
任何精心设计的系统（不仅仅是软件）的目标都是确保在适当的时间和地点提供相关的知识。纵观计算机科学的历史，它通过抽象的设计和实现来解决这个目标。抽象有助于将大量信息分配到子系统中，其中每个组成子系统都有专门的用途。抽象层填补了人与机器之间的鸿沟，每一层都将概念性的想法转化为 0 和 1。
精心设计的抽象和语言可以帮助阐明程序行为。抽象在与问题域最相关的层面上提供焦点，隐藏被认为不重要的信息。不幸的是，识别什么是重要的与“质量”和“最佳实践”等主题一样具有争议性。正因为如此，抽象的设计通常更像是一门艺术，而不是一门科学。创建正确的边界并在每一层表达适当的信息对于提供最有用且恰好适合上下文的信息至关重要。抽象也可能适得其反。它们可能过于不透明，并且为了提高最重要信息的信号，它们最终隐藏了太多信息。
“抽象的目的不是含糊不清，而是创建一个新的语义级别，在这个级别上可以绝对精确。”
— Edsger W. Dijkstra，《谦逊的程序员》1972 年 图灵讲座
抽象设计的基本张力与使用静态分析构建开发者工具相关的张力相似。重要的是展现适当的细节层次。虽然某些上下文需要更精细的精度，但更多的细节并不总是有利于更轻松地导航和检查大量的代码。一方面，用户可能会被压倒性的指标淹没，这些指标可能会麻痹决策或将注意力引导到不太有意义的数据上，从而导致无休止的细枝末节和微优化。另一方面，存在隐藏重要信息或引入自动化并产生不良结果的风险。细节和通用性之间的张力对于每个问题都是独一无二的，必须据此进行协商。
为什么人机交互被边缘化？
虽然很难准确指出为什么以人为中心的方法在面向开发者的工具设计中不太受重视，但以下推测探讨了可能起作用的文化方面。
倾向于编译器和编程语言
专注于静态分析的学者往往是编译器研究人员和编程语言理论家，他们的兴趣和专长倾向于研究语言功能、表达代数、解释器和算法设计。由于他们的专业化，对可用性和人机交互的讨论常常受到限制。此外，关于静态分析的想法在计算机科学文献中存在的时间比研究人员探索其在现代系统中的局限性的时间要长得多。因此，在关注可以从代码中提取哪些见解的研究与这些见解可能在实际应用中缓解的用户体验挑战之间存在脱节。
虽然越来越多的积极研究关注使用人机交互来帮助人们更好地理解代码，但这项研究仍然主要与静态分析应用程序脱节。10 任务分析方面的研究虽然能够将程序性知识描述为衡量各种界面有效性的一种方式，但也仍然与开发者工具中静态分析技术的实现脱节。
不太可能精通设计的工程师
与可能在设计方面更有专长的前端工程师或擅长构建证明其工作合理性的商业案例的产品工程师不同，负责将静态分析工具推向市场的工程师通常来自学术界，并且倾向于被聘用到更狭隘地专注于算法设计、规模和基础设施的角色中。鉴于他们的专长，他们可能不会优先考虑借鉴实证用户研究或可用性来验证其假设的设计过程，从而导致不太直观的实现。
由于他们的专业化，他们也优先考虑技术正确性，而不是向领导者和利益相关者传达业务价值主张，而这种沟通可能会带来更多的组织支持和设计资源。除非其对用户和业务的价值得到清晰的传达，否则以概念验证形式存在的功能代码主体毫无意义。即使对原型投入了大量的工程投资，对这类工作有用性的怀疑也会增加，并且这些项目可能会因缺乏将其推向生产所需的外部支持而变成孤儿项目。由于大多数静态分析技术也成本高昂且难以扩展，因此这项工作的理由也会减少。
缺乏一致性和标准
现代软件工程提出了独特的调试挑战，这些挑战源于缺乏一致性和标准。虽然开源软件在历史上曾被指责缺乏标准化，但专有软件也同样导致不一致。这是因为标准是在市场力量的推动下自然而然地产生的，而不是通过标准委员会系统地制定协议产生的。2
在竞争激烈的市场中，这意味着公司更有动力发布在经济上最可行的任何东西，即使由此产生的开发者体验结合了越来越不相关的工具的混合。鉴于广泛标准化和领域特异性之间固有的张力，也很难实现一致性。应用领域的多样性，以及硬件技术新发展的步伐，使得开发一种算法世界语变得困难且不切实际，因为不同的抽象旨在服务于特殊用途的问题。11
软件工程完全关于代码
软件工程需要大量的非编码任务，但代码本身的生产比支持高质量产品所需的中间工件更重要。对代码生产的片面痴迷可能会产生一种虚假的生产力感，并掩盖局部最大值内的次优方法。因此，支持更细致的思考和更好的软件开发的辅助工作，例如产品规划、项目管理、文档或以人为中心的设计，即使有做，也做得不好。
当几乎没有或根本没有前期系统设计时，架构不太可能具有干净的接口来分离功能并允许更轻松的调试。由于将代码组织成专用组件的组织性较低，工程师需要维护更广泛系统的心理模型，这增加了人为错误的风险。当执行设计和规划任务时，它们通常不像编写代码那样重要，并且被给予更少的投入和时间。当低质量的结果反映了非编码任务的优先级降低时，这只会助长行业对所有代码之外的工作都是徒劳的“自行车棚效应”的确认偏差。考虑到参与非编码软件工程任务所涉及的污名，可以支持非编码软件工程任务的工具发展受阻也就不足为奇了。
速度和迭代超过质量和战略思考
当最重要的成功指标是交付速度时，质量就会退居其次，而走捷径会得到奖励。不惜一切代价部署到生产环境比进行任何可能为团队节省数月甚至数年时间和精力的初步尽职调查更受重视。安迪·格鲁夫在他的著作《高产出管理》中将这种现象描述为“活动超过产出”问题，即忙碌的工作与富有成效的结果混淆。9 在他们的论文“机会主义编程：快速构思和原型如何在实践中发生”中，Joel Brandt 等人描述了迭代如何导致短视的选择。当迭代代码比任何事情都重要时，研究表明文档、系统架构和代码重用会受到影响。4
虽然快速迭代、快速交付和缩短的开发周期可以为用户行为提供巨大的洞察力，并开辟一条通往进步的渐进式道路，但预先应用的设计思维不足也会阻碍进步。目光短浅的关注可能会导致更多的错误、更大的技术债务以及对内部开发者体验的有限思考。迭代还施加了限制，并将系统的演进困在局部最大值内。约翰·康威的单人纸牌游戏“生命”中可以看到迭代如何影响结果的类比。初始状态决定了模式在未来几代人中的演变方式。8 虽然诸如“快速行动，打破陈规”之类的陈词滥调正在被淘汰，并且人们越来越接受简化短语会如何造成危险的疏忽，但需要进行重大的意识形态转变才能重视长期关注和深思熟虑，而这种关注和深思熟虑有一天会渗透到对开发者体验的更高优先级中。
人机交互等同于肤浅的表面装饰
人机交互及其子领域被错误地与表面视觉细节混淆，例如图标、颜色和字体。当然，人机交互远不止于此；它关系到用户遇到和感知到的一切。人机交互定义了呈现哪些信息；信息的结构方式；信息的含义、用途和时机；以及对信息的可用响应及其时间。人机交互还包括调查实现效果的技术，其中可能包括它的可学习性、特定任务由于给定的实现而变慢或变快多少，以及用户犯的错误以及他们遇到这些错误的频率。
黑客文化的赞美
由于行业中几家开创性公司将其成功归因于违反传统官僚主义的“颠覆性”实践，因此对流程和结构产生了强烈的蔑视。虽然放弃某些形式的僵化对公司有利，但将组织流程视为与创造力背道而驰会产生不同的问题。初创公司不仅挑战了工作场所规范，还表明传统教育的重要性降低了。减少对资格认证的强调是积极的，并且允许从比以前更广泛的人才库中汲取人才。然而，对教育的漠视也扩大了公司与学术机构之间的差距。
随着时间的推移，这导致了对计算机科学研究的更大程度的无知，并减少了与现有学术思想谱系的联系。长期存在的问题的解决方案通常是不成熟的，并且与数十年的研究脱节。这导致开发者工具被构建为一系列微调和反应，而不是整体系统。当 E. F. Codd 提出关系设计模型时，他的提议得到了坚实的理论基础的加强。6 现代开发实践提供的例子很少能证明计算机科学研究的原则性应用。
守门文化
几个代码库依赖于口头传统，使得知识转移变得困难。因此，参与给定的系统更具挑战性。当工程师有动机维持复杂性作为工作保障的手段时，糟糕的组织动态可能会放大这种现象。当没有人能够审查给定的系统时，它就不太可能受到质疑，而那些确实非常熟悉它的人可以利用它变得不可或缺。在需要工程师在脑海中记住更多信息的系统中工作被视为荣誉勋章，而不是设计失败。
UID 的挑战
潜在的技术挑战影响着 UID（用户界面设计）。充满快速变化的 API 的跨平台世界使得实现有用的图形用户界面变得困难。CLI（命令行界面）的设计提出了其自身的挑战，因为在根据开发人员已经熟悉的 Linux 等遗留系统和标准进行设计（即使这意味着延续已建立系统的 UI 缺陷）与从头开始构建（这减少了认知开销，但迫使用户学习新事物）之间存在持续的张力。
如果没有平衡一致性和可用性的周全设计，也存在施加增加障碍的简化方法的风险。这方面的一个例子包括对象导向 UI 的提议，它通过将计算框架应用于图形表示来颠倒以人为中心的设计理念。17 即使对象导向框架是基于一种拟物化时尚，该时尚以类似于人类日常生活中与之交互的对象来表示信息，但它与人类体验也相差甚远。并非所有问题都是面向对象的。这重现了问题，即采用一种框架并使其适应人类认知，而不是对心理过程直观。
极其复杂的生物
理解我们自身的神经官能症本身就是一项艰巨的任务，无论应用领域如何。对于像编程这样复杂多变的活动，同时承认人类心理多样性，这样做就更加困难。
以人为中心的数据
有大量的证据表明以人为中心的设计的重要性。复杂信息的框架和呈现方式会影响信息被理解的速度以及问题被有效解决的程度。这些想法早已被数据可视化领域所接受，该领域的重点是驱动统计数据的图形表示，使其最佳地映射到人类直观的思维方式。
一个众所周知的历史例子证明了数据可视化的力量，它涉及到弗洛伦斯·南丁格尔的工作。在 1854 年的克里米亚战争期间，南丁格尔是一名军事野战医院的首席护士，负责调查异常高的死亡率。她证明死亡的原因是恶劣的卫生条件、不良的排水系统和受污染的水源。她工作中最remarkable的不是数据收集或统计分析，而是她呈现调查结果的方式。她开发了一种现在通常被称为饼图或极坐标区域图的数据可视化类型，说明了患者死亡率的来源，该图发表在报告《印度皇家委员会》（1858-1863 年）中。传统的统计报告不太可能被有影响力的领导人或可以根据信息采取行动的繁忙政客理解，但由于这张图表以易于理解的格式有效地传达了密集的数据，南丁格尔的工作促使了卫生方面的改变，导致死亡率从 42% 降至 2%（见图 1）。15
这个例子表明，更多信息并不总是足够的。即使静态分析呈现了代码的“事实”，它也不会提高工程师根据所述事实采取行动的能力。为了最有效地传递关于软件系统的信息，必须充分理解人类与代码之间交互的动态。这样做需要加深对认知和记忆的理解，并识别已经可用的信息如何因糟糕的设计选择而变得不透明。
《牛津在线词典》将认知定义为“通过思想、经验和感官获取知识的心理活动或过程”[oxforddictionaries.com]。认知过程包括看、听、读、写、记忆、学习和决策。记忆是指人脑用于编码、存储和检索信息的过程，是逻辑推理和语言关系发展的必要条件。由于关于人类记忆如何运作存在不同的理论，例如记忆的双重理论，并且一些程序员遇到了短期记忆的局限性，1 因此需要提出的问题是：认知和记忆理论如何被理解和整合到支持软件开发的交互设计中？
工具使隐性知识显性化
学习新的编程语言和熟悉新的工具或代码库通常涉及到一个陡峭的学习曲线。理解概念并变得高效所需的工作量会随着时间和实践而减少。接触问题以及伴随实践的经验在与编程相关的任务中至关重要，因为工具很少能浮现不可见的隐性知识。
隐性知识指的是直觉、肌肉记忆和洞察力，这些是支持编程任务所需的，它们通过经验深深地嵌入在脑海中，以至于很少浮出意识层面。这意味着经验丰富的程序员可能知道什么有效，但不知道为什么，并且无法将这种智慧传达给他人。相比之下，显性知识是指有意识地识别并转化为指南的信息。编纂成文的最佳实践是显性知识的一个例子。
开发者工具可以通过使隐性知识更显性化，从而在促进程序员行为方面做得更多。 必须问：优秀软件工程的最佳实践是什么？如何将这些行为结果设计到工具中？ 可用性启发法是弥合这一差距的一种方法。12
“计算机擅长遵循指令，但不擅长阅读你的心思。”
— 唐纳德·克努特，《TeXbook》，1984 年
使隐性知识显性化的一种方法是呈现用户可获得但隐藏的数据。 这包括大多数语言的编译或解释步骤所需的信息。 利用 HCI 提升这些信息可以阐明许多工具和语言设计中的疏忽所造成的许多歧义，例如错误消息和前端 CLI 的设计。 错误消息通常要求用户推断的内容远超他们应该推断的范围。 熟练诊断错误并对错误做出适当反应会影响你在代码库中的生产力，但这项技能大部分是在长期的实践中积累起来的。
与其要求开发人员手动筛选冗长的日志，以将错误来源与解决方案联系起来，并随着时间的推移学习模式匹配，不如应用可用性原则来提高信噪比并改善调试体验。 在这个设计领域有几个活跃的项目示例。 旨在改善开发者体验的项目包括重新思考 Elm 中的终端用户体验，7 Lambdabot 用于为 Haskell 提供教学指导，18 或者 Agsy，一个外部程序，用于帮助在 Agda 语言中搜索满足规范的程序。3
编程语言的选择对想法的形成也有着巨大的影响。 几项研究表明，自然口语语言和思维模式之间存在着密切的关系。20 心理语言学是一门研究语言如何习得、使用和理解的学科，该领域的见解适用于口语和计算机语言。 同样，给定计算机编程语言的表达能力可以塑造程序员完成的工作以及完成方式。 语言选择会影响思维过程，并决定你拥有的信息以及在操作这些信息时所具有的控制粒度。16
虽然许多因素影响着关于各种编程语言相对优越性的辩论，但大多数语言社区都有旨在以某种方式改善用户交互的活跃项目。 类型化语言通常因其编译时保证以及能够通过 IDE 中提供的提示和文档提供更多清晰度而被吹捧为有利的。
然而，仅凭类型本身是不够的。 它们的作用范围仅限于利用它们提供的信息的用户体验。 如何有效地使用和传达类型信息可能会减少对复杂静态分析的需求。 比较 Haskell 的错误消息与 Rust 或 Elm 提供的错误消息之间的体验差异，可以证明用户体验的差异，而不是类型系统的差异。 还有一些工具用于可视化动态语言的执行信息，例如 Python Tutor25 或 Rust Analyzer，后者提供有关 Rust 代码的见解，并启用编辑器功能，例如自动完成和跳转到定义，并提供与状态相关的语义信息。26
未来取决于良好的人机交互
对于人类历史上相对较近的发展，软件已经产生了惊人的影响。 随着这种影响的扩大，人为错误的风险也随之加剧。 在这个世界中，复杂而不透明的系统根本无法扩展。 以人为中心的方法来发展工具和实践对于确保软件安全可靠地扩展至关重要。 更深入地了解人类行为可以提高可靠性，扩大贡献者范围，并提高结果质量。
静态分析可以揭示有关程序行为的重要信息，但导出此信息的目标不应是积累吹毛求疵的细节。 确保信息和流程的相关性和有效性，需要敏锐地意识到人类行为，并承认开发人员工作流程中现有的挑战。
HCI 可以帮助指导静态分析技术应用于面向开发人员的系统，这些系统构建信息，并在紧密反映程序员思维的表示中体现关系。 所有好的工具都能扩展你的能力，而开发者工具可以被认为不亚于人类思维的假肢。
正如沟通对于我们物种的进化生存至关重要一样，伟大软件的生存取决于支持而非抑制沟通、推理和抽象思维的编程语言。 长期以来，人们已经认识到编程促进了沟通，不仅在人与机器之间，而且在人与人之间。 使用以人为中心的框架来利用静态分析技术，可以将现有开发者工作流程中参差不齐、脱节的碎片化转变为更连贯、无缝的体验。
参考文献
1. Altmann, E. M. 2001. 近期记忆在编程中的应用：基于模拟的分析。《国际人机交互研究杂志》54(2), 189–210; https://www.sciencedirect.com/science/article/abs/pii/S1071581900904075.
2. Asay, M. 2016. 开源不应为缺乏行业标准而受到指责。 TechRepublic; https://www.techrepublic.com/article/open-source-is-not-to-blame-for-a-lack-of-industry-standards/.
3. 自动证明搜索 (Auto)。 2017. Agda; https://agda.readthedocs.io/en/v2.5.3/tools/auto.html.
4. Brandt, J., Guo, P. J., Lewenstein, J., Klemmer, S. R. 2008. 机会主义编程：实践中快速构思和原型设计的发生方式。《第四届终端用户软件工程国际研讨会论文集》，1–5; https://doi.org/10.1145/1370847.1370848.
5. Claburn, T. 2021. 被指控的凶手赢得权利，可以检查警方使用的 DNA 检测套件的源代码。《The Register》（2 月 4 日）； https://www.theregister.com/2021/02/04/dna_testing_software/.
6. Codd, E. F. 1970. 大型共享数据库的关系数据模型。《 通讯》13 (6), 377-387; https://dl.acm.org/doi/10.1145/362384.362685.
7. Czaplicki, E. 2015. 为人类设计的编译器错误。 Elm; https://elm-lang.org/news/compiler-errors-for-humans.
8. Gardner, M. 1970. 约翰·康威的新单人纸牌游戏“生命”的奇妙组合。《科学美国人》223, 120–123; https://web.stanford.edu/class/sts145/Library/life.pdf.
9. Grove, A. S. 1995. 《高产出管理》，第二版。 Vintage。
10. Guo, P. 2020. Philip Guo - 加州大学圣地亚哥分校。 https://pg.ucsd.edu/.
11. Harel, D. 1987. 《算法学：计算的精神》。 Addison-Wesley。
12. Henley, A. Z. 2021. 为什么很难看到 5 分钟前的代码？ 《黑客新闻》; https://web.eecs.utk.edu/~azh/blog/yestercode.html.
13. 国际标准化组织。 2018. ISO 9241-11:2018: 人机系统交互的人体工程学—第 11 部分：可用性：定义和概念； https://www.iso.org/standard/63500.html.
14. Jacko, J. A., ed. 2012. 《人机交互手册》，第 3 版。 CRC Press。
15. Karimi, H., Masoudi Alavi, N. 2015. 弗洛伦斯·南丁格尔：护理之母。《护理与助产研究》4(2), e29475; https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4557413/.
16. Knuth, D. E. 1984. 文学编程。《计算机杂志》27(2), 97–111; https://academic.oup.com/comjnl/article/27/2/97/343244.
17. Lamb, G. 2001. 使用面向对象的技术改进你的 UI 设计流程。 Microsoft 开发人员网络，Visual Basic 开发人员； https://web.archive.org/web/20130814153652/http://msdn.microsoft.com/en-us/library/aa227601(v=vs.60).aspx.
18. Lambdabot。 2021. Haskell; https://wiki.haskell.org/Lambdabot.
19. Mark, G., Gonzalez, V. M., Harris, J. 2005. 没有任务被遗漏？ 考察碎片化工作的性质。《人机交互系统 SIGCHI 会议论文集》，321–330; https://dl.acm.org/doi/abs/10.1145/1054972.1055017.
20. Mou, B. 1999. 汉语的结构和本体论的见解：集体名词假说。《东西方哲学》49(1), 45–62; https://www.jstor.org/stable/1400116.
21. Naveh-Benjamin, M., Guez, J. (2000). 分散注意力对编码和检索过程的影响：注意力成本评估和成分分析。《实验心理学杂志：学习、记忆和认知》26(6), 1461-82; https://psycnet.apa.org/record/2000-12254-009.
22. Nielsen, J. 1994. 用户界面设计的 10 条可用性启发法。 尼尔森·诺曼集团; https://www.nngroup.com/articles/ten-usability-heuristics/.
23. Norman, D. 2013. 《日常物品的设计》。 纽约州纽约市：Basic Books。
24. O'Conaill, B., Frohlich, D. 1995. 工作场所的时空：处理中断。《人机交互系统会议伴侣》，262-263; https://doi.org/10.1145/223355.223665.
25. Python Tutor。（未注明日期）。 可视化代码执行； http://pythontutor.com/.
26. Rust-analyzer。（未注明日期）; https://rust-analyzer.github.io/.
27. Safety Research & Strategies Inc. 2013. 丰田汽车意外加速和大碗“意大利面条”代码（11 月 7 日）； https://www.safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/.
28. Sierra, K. 2013. 你的应用程序让我发胖。 Serious Pony (7 月 24 日); http://seriouspony.com/blog/2013/7/24/your-app-makes-me-fat.
29. Weinschenk, S. 2012. 多任务处理的真正成本。《今日心理学》（9 月 18 日）； https://www.psychologytoday.com/us/blog/brain-wise/201209/the-true-cost-multi-tasking.
艾曼·纳迪姆是 GitHub 的高级软件工程师，致力于构建大规模缓解滥用的安全基础设施。 她热爱探索人类语言和编程语言如何被思想和计算机解读。
版权所有 © 2021，由所有者/作者持有。 出版权已许可给 。
最初发表于 Queue vol. 19, no. 4—
在 数字图书馆 中评论本文
更多相关文章
凯瑟琳·海耶斯，大卫·马龙 - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。 出于各种安全要求，加密哈希存在许多标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。 虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
妮可·福斯格伦，埃里尼·卡利亚姆瓦库，艾比·诺达，米凯拉·格雷勒，布莱恩·豪克，玛格丽特-安妮·斯托里 - DevEx 行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。 技术领导者凭直觉接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。 然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
若昂·瓦拉霍，安东尼奥·特里戈，米格尔·阿尔梅达 - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。 低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。 本文报告了程序和协议、结果、局限性以及未来研究的机会。
伊瓦尔·雅各布森，阿里斯泰尔·科克本 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和技巧不断涌现，以服务于商业和社会，但它也很健忘。 在其快速前进的匆忙中，它容易受到时尚的摆布，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。 用例于 1986 年首次引入，并在后来普及，就是这些成熟的解决方案之一。
© 保留所有权利。