Kode Vicious - @kode_vicious
PDFKode Vicious: 返回
一个态度强硬的程序员，KV 回答你的问题。他可不是礼仪专家。
编码问题让你抓狂，同事让你发疯？别害怕，Kode Vicious 来啦——解答你的问题，解决你的难题，让世界变得更美好。
亲爱的 KV，
每当我的团队审查我的代码时，他们总是抱怨我没有检查系统调用的返回值。我可以理解需要检查常规函数调用，因为我不信任我的同事，但是系统调用是由懂行的人编写的——而且，此外，如果系统调用失败，我也做不了什么来恢复。何必费心呢？
无意义的返回值
亲爱的无意义，
虽然你可能认为那些编写操作系统的人是编程之神，是生活在更高层面的女神，但我可以根据我的亲身经历告诉你，你大错特错了。编程的首要规则之一，也是大多数编程课程似乎都遗漏的一条规则是：不要相信任何人！编写你正在调用的系统调用的人早就领了你正在使用的代码的工资，如果他们幸运的话，正在从事其他工作。
事实是，返回值和错误检查是有原因的。没有人能够预料到一段代码可能被使用的所有可能方式。因此，如果程序员是聪明的，他们会编写并清楚地记录（提示，提示）他们的例程可能失败的所有可能方式，并确保向调用者返回合理的错误值。
事实证明，不检查返回值是软件中非常常见的错误。你在编写代码时可能会想，“嗯，如果这个失败了，系统反正都崩溃了，所以我最好忽略返回值，因为它无关紧要。” 但是，当你想要调试崩溃的系统时呢？如果你在代码中留出一个位置来存放返回值，那么当你凌晨 2 点坐在那里，累得无法思考，盯着调试器时，你可以直接找出返回值是什么。否则，你必须添加该变量，重新编译系统，然后再次检查。在某些系统中，达到错误条件需要数小时甚至数天，提前进行适当的错误检查可以为你节省很多麻烦。
顺便说一句，我不得不赞同那些认为过度的错误检查会使代码变得丑陋的人。显然，这个问题尚未解决，因为每十年我们都会有一种新的方式来表示错误检查。曾经是 if/then 语句，然后我们添加了异常，现在大多数语言都有 try/except 语句。这些方法似乎都不令人满意。如果有人能指出一些不会让我的代码超出屏幕边缘的东西，我很想知道是什么。
回到主题。将检查返回代码视为一种安全带。当然，你今天可能不会发生事故，但如果你最终被甩出挡风玻璃，你会感觉自己很蠢。
KV
亲爱的 KV，
我刚加入一家构建大型 Web 服务平台的公司，目前正在与其 QA 团队合作。我目前的工作是为系统编写单元测试，并将它们连接到我们的每晚回归测试套件中。团队中有很多程序员抱怨说我的测试毫无意义，我只是在浪费时间。这些程序员自己实际上并不编写测试，所以他们怎么知道呢？我有点厌倦了被这些人抨击。你写测试吗？还是只编码？你怎么知道你编写的测试是好的？
爱测试的测试员
亲爱的爱测试的，
首先，所有优秀的程序员都会编写测试。没有哪个值回票价的程序员会整天只顾埋头写代码，而不去看看它是否有效！所以，回答你的第一个问题，是的，我写测试。实际上，我暗地里很喜欢为别人的代码以及我自己的代码编写测试。为别人的代码编写测试是了解系统以及程序员如何思考的一种有趣方式。为我自己的代码创建测试只是确保我看起来不像个白痴的一种方式。我讨厌看起来像个白痴。
你的问题的真正核心可能需要比我在这里所拥有的时间更多的时间来回答，所以我会简要地介绍一下我个人认为什么是好的测试创建。也许最容易创建的测试集，也是我认为大多数程序员都熟悉的测试集，是你在他人在发现你犯了一个轻微的……好吧，为了好听点，我们称之为错误之后编写的测试。你只需浏览错误数据库，为存在的每个错误创建一个测试，将它们连接到某种自动化工具中，然后就可以开始了。
这是一种让你在老板面前看起来不错的非常简单的方法。你有一大堆工作可以展示，你可以表明产品不会以之前崩溃的方式崩溃。我坚信，我知道其他人不同意，这些类型的测试应该由修复错误的程序员编写，而不是由编码团队之外的人编写。你弄坏的？你修复它！你测试它！你确保它绝对不会再次崩溃，就这样。不幸的是，通过将这项工作交给程序员，我从 QA 团队手中夺走了这项工作。抱歉。
我不完全确定，从你的信中，你的同事在你的测试中看到了什么问题，但我可以告诉你过去我与测试团队合作时让我恼火的事情。其中第一个是愚蠢测试综合症（STS，简称）。 STS 通常是由仍然相信通过代码行数而不是工作质量来衡量工作的管理者引起的。这些管理者要求测试一切，而从不考虑应该测试什么，或者权衡风险。因此，发生的情况是，QA 团队开始埋头苦干，为系统中的每个可能的旋钮编写测试，从某个任意点 A 开始，一直工作到产品发布。最终，测试变得如此繁琐，以至于需要整夜才能运行，而且它们很少发现任何严重的错误。这种方法无效的原因是 QA 团队不被允许使用他们的大脑——一项重要的资产——来编写能够发现对系统用户来说最糟糕的错误的测试。
避免 STS 需要一些东西。它需要一个大脑，我相信你拥有，因为你成功地给我写了信。它需要的第二个东西是与系统设计和实现人员的良好工作关系。你必须能够提出问题，以便你可以将你的努力导向风险最高的领域。测试一个执行简单且易于理解的库接口几乎没有意义，而有 10,000 行实验性的，或者只是纯粹奇怪的代码，这些代码是公司的秘密武器，也需要进行测试。避免 STS 所需的最后一件事是管理者或管理链，他们了解进行良好测试的意义。如果你为那些 LOC（代码行数）人员工作，你就会处于不利地位，你将不得不绕过他们来编写好的测试。但是，几个月后，编写好的测试将会得到回报，因为你将成为小组中发现最多、最严重问题的人。
另一个让我恼火的事情，也可能是你的同事抱怨的根源，是随意散落在各处的，没有连贯组织的随机测试。我坚信良好的测试工具。让程序员更容易编写测试，他们就会为你编写测试；他们甚至会在发布代码之前运行它们。如果你的测试位于你的主目录中，并且需要大量设置，你可以忘记获得任何帮助来处理它们。测试不应是一次性的；它们应该像你正在测试的软件一样，成为系统的一部分。
因此，如果要么你患有 STS，要么你的测试只是零零散散的片段，你就知道你的同事为什么抱怨了。以我的经验，编写好的测试所需的技能与编写好的代码所需的技能有些不同，但同样有价值。在很大程度上，编写好的测试需要大脑、好奇心和破坏事物的癖好。
KV
KODE VICIOUS，凡人称之为 George V. Neville-Neil，为了乐趣和利润而从事网络和操作系统代码的工作。他还教授与编程相关的各种主题的课程。他的兴趣领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行者，自 1990 年以来一直以旧金山为家。
© 2004 1542-7730/04/1200 $5.00
最初发表于 Queue 第 2 卷，第 9 期—
在 数字图书馆 中评论本文
更多相关文章
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 年引入并在后来普及，就是这些行之有效的解决方案之一。
© 保留所有权利。