开发人员经验在编程语言研究中的作用是什么？

2018年，当我在卡内基梅隆大学(Carnegie Mellon University)担任终身教职的两年时，我看到了软件界正在发生的事情。2018年，《剑桥分析》问世；不久之后，GDPR成为法律。大多数在行业中创办公司的学者之所以这样做，是因为他们正在将一个特定的项目商业化；我离开秋田软件公司是因为我看到，现在是构建我想要构建的工具的正确时机-那些可以帮助提高软件质量和安全性的工具。在过去的两年里，我一直致力于为现代网络应用构建API级别的开发工具。

因为技术问题在我创办秋田的时候还不是板上钉钉的，所以我在公司工作的第一年里一直在做产品和用户研究工作。我的学术生涯训练我有原则地解决问题。在启动和运行秋田的过程中，我学会了如何有原则地选择问题。这一点很重要，因为我的努力的成功第一次被定义为我解决的问题有多好，人们非常关心这些问题，愿意为这些问题付钱。以下是我学到的东西。

当我从事研究时，我花了很多时间与程序员“在野外”交谈，以了解他们存在的问题。所以我认为我是在做问题选择方面的功课。在过去的两年里，我了解了用户研究，并意识到我在学术界的问题选择本可以更有条理、更有原则！

当您试图了解确切的问题时，有一些原则性的方法可以了解用户的痛苦-即使您的用户是程序员，而您正在处理像编程语言和工具这样复杂的事情。你不能用数学来证明它们，也不能像你对待编译器性能那样测量它们，但你仍然可以是科学的，例如，通过应用严格的方法。这是人机界面领域已经做了很长时间的事情，人们一直在倡导将更多的东西与编程工具相结合，但仍然没有涉及到大多数编程语言的研究。(例如，请参阅本文“程序员也是用户：改进编程工具的以人为本的方法”和Sarah Chasins的“构建以用户为中心的编程工具”的教学大纲。)。

关于用户研究，我学到的一件主要事情就是严格要求我问用户问题的方式。最直接的方式是在相同的条件下，以相同的顺序问所有用户相同的问题。同样重要的是，不要问引导性问题，也不要直接问用户他们想要什么--有句名言说，如果亨利·福特(Henry Ford)问人们他们想要什么，他们会说马跑得更快。如果你的假设是，系鞋带是出门时的一个痛点，那么直接问：“系鞋带有问题吗？”这不是个好主意。要做到这一点，更好的方法是让用户告诉你当他们离开家时会发生什么，并询问他们的痛点是什么。(有关这方面的更多信息，您可能会对“上下文查询原理”感兴趣。)。

我在用户研究中学到的另一个重要经验是缩小。以前，当我在做编程语言研究时与用户交谈时，我的对话通常围绕着开发人员围绕我正在处理的具体问题而感到的痛苦。在做用户研究时，我学到的是将用户作为一个整体来理解，以更大的动机和激励来完成，并理解我解决的问题如何符合他们的目标、希望和梦想。例如，在了解更多关于用户研究的知识之前，我问了以下几个问题：

以下是我创建Akita时我们问了几十个用户的一些问题，这些问题与我们正在构建的特定工具几乎没有什么关系：

给我讲讲你工作中的一天。你在用什么工具？你是怎么打发时间的？

什么问题会让你超时工作？

告诉我你是如何与工程学的其他部门打交道的。你们那里有什么摩擦？(这是一个给安全工程师的问题。)。

作为一名编程语言研究人员，我在选择问题的过程中肯定没有以一致和有纪律的方式提出这些问题--如果真的有的话。例如，通过问这些问题，我了解到，开发人员的采用对安全工具成功的影响比安全工程师认为的任何东西都要大得多。而开发者的采用往往更多地取决于可操作性，而不是准确性。这些认识不仅使我们完全改变了我们认为我们的产品应该是什么样子(我们一开始专注于API的安全/隐私相关用法，但后来转向了通用用例)，而且也永远改变了我对构建编程语言和工具的看法。

采用上述方法使我们正在做的事情发生了重大变化。当我开始创建Akita时，我认为我们要构建的是一个相当于应用程序性能监控工具的应用程序性能监控工具，用于跟踪数据，面向安全和隐私团队。我是在与高层人士交谈后得出这个初步结论的，这些人认为问题是什么，以及他们认为需要什么。通过用户研究，我们决定构建低摩擦的集成工具，以针对API规范进行推断和测试，并将我们的解决方案从专门针对安全或隐私的方向转移。以下是导致这种情况的一些教训：

安全工程师打发时间的最重要方式是改善他们与软件工程的关系。当我们询问安全工程师如何晋升和/或提高他们在组织中的影响力时，我们一遍又一遍地问道，安全团队的好坏取决于听取他们意见的工程师。这让我们相信构建开发人员工具是正确的选择，因为它们的影响力要大得多！

安全工程师面临的最大挑战之一是让软件工程师修复他们的漏洞。当我们要求安全工程师带领我们完成他们最终花费了大量时间的事情时，这涉及到说服工程师修复问题。例如，与我交谈过的一位工程师花了大量时间想出例子来说服工程师，他们写的东西是不安全的。另一个团队更进一步，雇佣了渗透测试员，只是为了证明某些安全/隐私控制对他们的工程团队的重要性。这项用户研究的结果让我们相信，仅仅向安全部门提供出错的报告是不够的；更强大的工具不仅可以帮助识别可能的问题，还可以帮助开发人员确定问题的优先顺序并进行修复。(我们的发现与这项研究的结果相符。)。作为一个开发工具团队，这正合我们的胃口，引导我们开始构建有助于提供上下文和可重现性的工具。

一体化摩擦很重要。当我们询问用户是什么原因导致他们选择当前使用的工具时，他们一次又一次地提到集成到现有工具链的简单性，以及该工具需要多少配置。对于安全工程师来说尤其如此，因为每当他们向其他团队提出要求时，他们就会消耗社会资本。我们意识到，如果我们不开发一个易于集成的工具，就很难被采用。

构建安全的开发人员工具意味着构建开发人员/安全差距。在我们产品的第一年工作过程中，我们意识到我们的产品设计和投放市场需要跨越安全工程团队和软件工程团队之间的沟通和激励差距。在了解了每一方的观点，开发商似乎对关闭它并不是很感兴趣后，我们最终决定需要选择一方。我们选择成为一个有安全用例的开发工具，而不是相反。如果没有做过我们已经做过的用户调查，选择就不会那么明显了！

在做这个用户研究的过程中，我也学会了放弃我在学术界的许多假设：

健全可能不是正确的目标。在学术界，让静态程序分析变得合理通常是一个目标：如果没有报告一个bug，那么这个bug应该是不可能的。关于静态分析的一个常见抱怨是，由于误报，它们实际上在很多时候都没有多大帮助。例如，这是一个问题的一个原因是，安全团队向开发人员报告的错误越多，修复这些错误的可能性就越小。在学术界，我认为错误错误是非错误的；许多行业开发人员会将低优先级错误称为“假阳性”。数量惊人的工程师(对我来说)表示，他们宁愿不知道所有的错误，而是被告知可能修复的错误子集。彼得·奥赫恩(Peter O‘Hain)的“不正确逻辑”论文就是解决这一问题的一篇论文。

“遗产因素”可能比担保或业绩更重要。更广泛地说，人们想要做出的权衡并不是你可能会想到的，所以它们是值得探索的。例如，当我更深入地挖掘我的问题时，我了解到，进入的障碍往往是说服人们采用工具，而这些工具更多地与集成和学习曲线有关，而不是数学或性能。如果人们从来没有意识到一个工具的优点，他们就不会欣赏这个工具！这绝对不同于我在学术界的观点，当时我的重点是构建新功能的干净版本，把采用作为一种练习留给读者。虽然要求所有的学术工作都担心领养问题肯定会抑制很多创新，但将领养视为“不是学术界的问题”可能会抑制产生影响的机会。鉴于与遗留工具链的无摩擦集成会产生令人惊讶的挑战性技术问题，并可能对影响产生不成比例的影响，因此应该在学术界给予更多关注。

我学习用户研究的经历让我重新审视了我之前思考了很多的问题：我们应该如何评估编程语言研究论文？虽然一篇论文的导言首先会让评审者对论文感兴趣，但评估部分给了冠军评审员必要的弹药，让他可以在项目委员会会议上奋力拼搏。由于这种能力，评估部分中显示的内容决定了在整个领域中需要完成的工作类型。

我坚信，编程语言研究并不重视可用性，因为目前还没有令人满意的、达成一致的评估方法。语义评估保证了诸如健全性、完整性和类型安全等属性，但它们并没有说明是否有人会真正关心这些保证或语言。根据样例程序，基准测试决定了工具的运行速度。基准测试对于已知语言的编译器来说是非常好的，但通常不适合不关注性能的语言或工具设计论文。我们经常看到的长达一小时的用户研究常常不足以评估复杂的语言和工具。(Coblenz等人最近提交了一份Tochi报告，概述了评估过程中存在的一些缺陷，并提出了一个新的过程。)。

语言或工具设计中与开发人员经验有关的部分--对于很多论文来说，这是一大堆事情--最终只出现在导言和整篇论文的各种假设中。这意味着这些部分不会被直接评估。当我们不直接评估可用性声明时，会发生两件事。首先，专注于以深思熟虑的方式提高可用性的工作不一定有更好的机会得到积极的同行评议。其次，可用性声明没有得到严格的审查，这意味着该领域不太可能转向改善开发人员体验的解决方案。现在，当一篇论文的主要优势是可用性时，它通过同行评议的时间就更差了，因为这取决于具体的评审者是否欣赏它。

这是一个我想向这个领域提出的问题：在PL论文的问题选择上应用严格的评估，而不是对结果进行案例研究，会是什么样子？对于那些提出提高开发人员生产率的论文，为什么不对照采访/调查来评估它们，看看开发人员到底在哪里苦苦挣扎呢？为什么不让这些标准(例如，健全性或性能)成为需要通过用户研究来证明的东西呢？“Soundness”是一种正式声明，表示分析根据一些感兴趣的语义属性尊重语义，例如没有运行时失败或没有信息。例如，通过用户访谈来证明这一属性本身是合理的，看起来会是什么样子？

I d

最后一句话：我们应该小心，不要让追求任何特定类型的评估主导一个领域，包括以用户为中心的评估。一方面，我喜欢在高度技术性的编程语言论文中增加以人为中心的评估部分的想法。我一直认为编程语言研究是人的因素与数学和代码的结合--这些评估部分最终会反映出这一结合。另一方面，学术界不是行业是有原因的。我们需要为假设提供空间。我们对评估的要求越高，就越难证明伴随着真正新奇发现的直觉是合理的。虽然我认为，在类似于以语义为中心或以绩效为中心的评估的基础上考虑以人为中心的评估将推动该领域向前发展，但我们应该谨慎对待任何一种必需的评估。

简介：Jean Yang是API工具公司Akita Software的创始人兼首席执行官。她之前是卡内基梅隆大学计算机系的助理教授。

致谢：感谢威尔·克莱顿对本文草稿的评论和建议！

免责声明：这些帖子是由个人撰稿人撰写的，目的是为了社区利益在SIGPLAN博客上分享他们的想法。本博客中所代表的任何观点或观点均为个人观点，仅属于博客作者，不代表ACM SIGPLAN或其上级组织ACM的观点或观点。