凭着世界上最好的意志，无论我们(和我)编写什么软件，都会有某种缺陷。

作为开发人员，我该怎么做才能使支持部门(第一线，第三线和开发)更容易诊断，解决和解决用户遇到的问题。

笔记

• 我期待的答案本质上是技术性的，但是我希望还有其他答案。
• "不要在软件中发布错误"是一个很好的答案，但我已经知道了。

解决方案

技术特点：

• 在桌面应用程序的错误对话框中，包括一个可单击的按钮，该按钮可打开并发送电子邮件，并添加堆栈跟踪和日志，包括系统属性。
• 在Web应用程序的错误屏幕上，报告时间戳，包括纳秒级和错误代码，PID等，以便可以搜索服务器日志。
• 允许在运行时动态更改日志级别。必须重新启动服务器才能执行此操作。
• 记录有关执行环境的尽可能多的详细信息(可能在启动时)。

非技术：

• 在文档中提供一个已知问题部分。如果这是一个网页，那么它对应于错误跟踪器中的经过分类的错误列表。
• 根据听众，为问题跟踪提供某种界面。
• 同样，根据受众，为用户提供一些论坛以互相帮助。
• 可用性先解决问题，再解决问题。明智的，非吓人的错误消息通常使用户可以找到自己的问题的解决方案。

过程：

• 看你的日志。对于服务器端产品，定期检查日志将是即将发生问题的良好预警信号。当我们认为前方有麻烦时，请确保支持人员知道。
• 留出时间为支持部门编写工具。这些可能会作为开发人员的调试工具开始，成为进入应用程序内部状态以获取支持的窗口，甚至可能成为将来版本的强大工具。
• 为开发人员留出一些时间与支持团队一起度过；在支持电话上倾听客户的声音，在现场外出等等。确保开发人员不允许做出任何承诺。完成此操作后向开发人员汇报-那里可能有一些主意。
• 在适当的地方提供用户培训。阻抗不匹配会导致用户感觉到软件问题，而不是用户的软件思维模型。

• 记录有关执行环境的详细信息(可能在启动时)。
• 给异常赋予有意义的名称和消息。它们可能仅出现在堆栈跟踪中，但这仍然非常有用。
• 为支持团队分配一些时间来编写工具。他们几乎肯定会超出用户或者开发人员的需求。
• 与支持团队一起坐了半天，以了解他们要做的事情。观看重复的任务-他们甚至可能不会有意识地注意到重复。
• 定期与支持团队会面-确保他们永远不会激怒我们。

• 提供一种机制来捕获问题发生时用户的行为，日志记录或者跟踪功能，可以和同事提供数据(引发了什么异常，堆栈跟踪，程序状态，用户的行为等) 。)，以便我们可以重新创建问题。
• 如果我们尚未将开发人员自动化测试纳入产品开发中，请考虑这样做。

类似于jamesh答案的组合，我们针对网络应用执行此操作

• 提供"报告错误"链接，以便用户即使不生成错误屏幕也可以报告错误。
• 该链接打开一个小对话框，该对话框随后通过Ajax提交到服务器上的处理器。
• 处理器将提交内容与正在报告的脚本及其PID关联，以便我们可以找到正确的日志文件(我们通过脚本/ pid组织我们的日志文件)，然后将电子邮件发送到我们的错误跟踪系统。

确保可以使用自动更新来部署应用程序。支持小组的头疼问题之一就是将客户升级到最新的和最大的客户，以便他们可以利用错误修复，新功能等优势。如果升级过程是无缝的，则可以减轻支持小组的压力。

如果服务器上至少有一部分应用程序正在运行，请确保监视日志中是否有错误。

当我们首次实现每日脚本时，该脚本会捕获ERROR / Exception / FATAL并通过电子邮件发送结果，我感到惊讶的是我们之前没有注意到多少个问题(大多数是微小的)。

这将以某种方式，让我们自己注意一些问题，然后再将其报告给支持团队。

提供已知问题文件
对应用程序进行培训，以便他们知道其应如何工作
提供简单明了的日志行，他们将理解或者创建错误代码以及描述错误的相应文档

一些想法：

• 尽最大努力立即验证用户输入。
• 尽早并经常检查错误或者异常。在问题产生后，在产生"跳弹"效果之前，更容易跟踪和修复问题。
• 只要有可能，请在错误消息中描述如何解决问题。用户对出了什么问题不感兴趣，仅对如何继续工作不感兴趣：

BAD:  Floating-point exception in vogon.c, line 42

  BETTER: Please enter a dollar amount greater than 0.

• 如果我们无法提出解决问题的建议，请在致电技术支持之前告诉用户要做什么(或者不应该做什么)，例如："单击帮助->关于以查找版本/许可证号"或者"请在屏幕上留下此错误消息。"
• 与支持人员联系。询问常见问题和宠物烦恼。让他们回答这个问题！
• 如果网站带有支持部分，请在错误消息中提供超链接或者URL。
• 指出错误是由于暂时的还是永久的情况，因此用户将知道是否要重试。
• 在每条错误消息中都输入手机号码，并确定自己是开发人员。

好的，最后一项可能不切实际，但是会不会鼓励更好的编码实践呢？

有改善事物的心态。每当我们修复问题时，请询问：

• 将来如何避免类似的问题？

然后尝试找到解决该问题的方法。