error-reporting - 当报告的软件问题不是真正的软件问题时

Question

抱歉，如果这已经被覆盖，或者您认为它确实属于 wiki。

我是一家为生物科学行业制造微阵列印刷机的公司的软件开发人员。我主要参与通过 C++ 中的 GUI 开发与各种硬件（气动、液压、步进电机、传感器等）接口，以将样本吸出并打印到微阵列载玻片上。

加入公司后，我注意到每当出现与硬件相关的问题时，这都会导致整个设置冻结，没有人更清楚具体问题是什么 - 硬件/软件/滥用等。从那以后我已经改进了通过引入软件超时和异常处理来更好地识别和处理出现的任何与硬件相关的问题，例如 PLC 命令未成功完成、不适当的 FPGA 响应命令以及各种其他死锁类型条件等。此外，软件现在将记录总结具体问题，通知用户并优雅退出线程。该软件不是嵌入式的，只是使用串口连接。

尽管已经取得了成就，非软件人员仍然没有完全理解在这些情况下，他们向我报告的“软件”问题并不是真正的软件问题，而是软件正在报告问题，但不会导致它。不要误会我的意思，我最喜欢的莫过于像一堆砖头一样解决软件错误，并寻找以任何方式提高健壮性的方法。我现在对这个系统已经足够了解了，我几乎对这些东西有了第六感。

无论我试图解释多少次，都没有真正深入人心。他们仍然将本质上的硬件问题（最终得到修复）报告为软件问题。

我想听听其他有过类似指责经历的人，以及他们用什么方法来处理它们。

更新 这里的一些很棒的回应几乎是从同一张赞美诗中唱出来的：更具描述性。我猜想在硬件故障时识别命令并彻底轰炸是第一阶段，但仍然不够。下一阶段将把对外行相当无意义的 PLC 命令映射到更具暗示性的东西上。“PLC 命令 M71 超时”变为“无法初始化注射器系统。检查是否达到了足够的真空度”等等......

Answer 1

您可以尝试将错误消息标记为“硬件问题”。可能会明白你的意思。

Answer 2

也许在将问题作为消息报告给用户或日志文件中的条目时，您需要明确说明问题出在硬件上：

“步进电机无响应”。

不幸的是，因为人们看到并与之交互的是软件，所以他们认为软件就是一切。

Answer 3

系统中不存在非软件问题。软件是老板，老板不能把失败归咎于工具。

如果底层硬件出现故障，它应该向用户报告哪个组件到底出了什么问题。如果没有，那就是软件问题。

例如，TCP 断开连接意味着它必须重新连接。如果是 FPGA 响应，它应该准确地告诉用户输入和输出是什么，以及谁应该受到责备。如果不是，这是一个软件问题。

Answer 4

我同意其他海报，但我想补充另一个观点：情况可能会更糟。他们可能会尝试解决硬件问题几天或几周，然后发现，当每个人都在枪口下并且一直因为没有得到修复而疯狂时，他们正在解决错误的问题，事实上，软件问题。所以数数你的祝福。如果他们总是将其归类为软件问题，那么至少您对此有所了解。只有这样，您才能进行故障排除，可能会添加额外的问题解决或问题识别代码，并使系统变得更好一点。

此外，这与世界各地的每个软件开发人员所面临的几乎相同。除了通常是软件与用户，而不是软件与硬件。在这种情况下，似乎没有已知的解决方案。解决问题的方法很多，但没有办法解决。因此，描述如何在不粗鲁的情况下责备用户的首字母缩略词列表不断增加：ID-10-T 错误、PICNIC、PEBKAC 等。

Answer 5

“如果你正在做的事情不起作用，请停止这样做并尝试其他方法”

正如其他评论中指出的那样，这是一个沟通问题，在较小程度上是感知问题。人们会更容易责怪他们不了解 FAR 的东西，让自己觉得自己是受害者。电机可能会因某人严重超载馈线而引发火花、起火和爆炸（每条警告都不要贴满它）——但如果该软件停止响应，猜猜是什么导致了问题？

因为给每个用户一个 EE 和 CS 等级或 10 级是完全不可能的，所以依靠良好的 ole 沟通。其基础是 4 件事（主要是我的观点），没有特定的顺序——你观察到的，你的感受，你的想法和应该做什么。所以有了这个想法，我将通过给出这个回应来付诸实践。

当某些底层硬件是关键问题时，您的用户似乎喜欢责怪软件（观察）。试图向用户解释这一点是不切实际的，而且是浪费时间，这不是他们的工作，他们中的大多数人都不会关心（感觉）。您可能想要尝试的是与工程团队讨论他们正在使用的部件，并研究一般情况下更适合软件的东西。也许从未考虑过输入的一些限制？（想想）更换硬件或只是更好地理解它可能是真正的答案以及更有针对性的错误和对这些用户的反馈（完成）。

Answer 6

谁在报告问题？

如果是最终用户，我认为这不是问题。他们只知道他们正在尝试做的事情是行不通的。诊断问题不是用户的责任。他们所知道的是，“我试图做 X，Y 应该发生，但 Z 发生了。” 除此之外的一切都是你的问题。

如果硬件人员坚持认为问题出在软件上，而软件人员坚持认为问题出在硬件上，那么您需要增强软件以更准确地诊断错误，正如 ChrisF 和其他人所指出的那样。

如果上级指责软件组的问题是硬件组的责任，而你厌倦了为别人的错误承担责任，好吧，我明白这一点。同样，作为软件专家，您有能力创建更精确的错误消息。如果您可以明确地说“步进电机没有响应”或其他任何内容，那么您就有“道德权威”坚持要求有人对步进电机进行诊断。只是说，“我很确定这是硬件问题”不会赢得争论。

Answer 7

面向测试的开发（不一定意味着“测试驱动”）是您应该提供的资源。

基本上，每个子系统都应该有一套相当彻底的单元测试，以便在集成之前识别问题。每次出现问题时测试硬件，这样您就可以确定（或几乎确定）这是硬件问题。这意味着必须以可以彻底测试的方式设计硬件。

我是我大学机器人团队的整合负责人，这种策略很有帮助。

希望这可以帮助。

Answer 8

首先，确保您的用户更有可能阅读和理解您的错误消息。显示“FPGA 命令 GS_WIDGIT_FROB 返回无效响应 0xFF45001C。关闭控制器 id 576D。（错误 1Xf）”可能对您很好。但是，用户可能会在不阅读的情况下点击“确定”。即使他们确实阅读了它，它也不会告诉他们任何有用的信息。无论哪种方式，你都会接到一个电话。显示“Widgit Frobber 需要维护”，但仍将所有繁重的细节记录在某处，您可能会接到更少的电话。

其次，您知道这是硬件问题，所以请采取一些措施！让您的软件电子邮件硬件支持，或任何解决问题的方法。如果用户被迫决定采取什么行动来修复它，你可以打赌他们至少在某些时候会出错。如果用户看到“Widgit Frobber 需要维护。已通知硬件支持（票证 #234）”，他们就知道他们不必做任何事情。