没有事情,错误1503_为什么依靠用户报告错误是您做过的最愚蠢的事情

没有事情,错误1503

by Nick Harley

尼克·哈利(Nick Harley)

为什么依靠用户报告错误是您做过的最愚蠢的事情 (Why relying on your users to report errors is the dumbest thing you’ll ever do)

We all love to code.

我们都喜欢编码。

When we think about coding, we are usually picturing ourselves building.

当我们考虑编码时，通常是在构想自己的建筑 。

Building features, new innovations, new functionality, and exciting updates that users will love. It’s that mental picture that gets us excited about the things we can build next.

用户喜爱的建筑功能，新创新，新功能和令人兴奋的更新。 正是这种心理印象使我们对接下来可以制造的东西感到兴奋。

But the romantic images in our heads are often not translated to reality.

但是，我们脑海中的浪漫意象往往无法转化为现实。

Software developers spend most of their time on tasks other than building. They attend meetings, discuss specifications, plan, and tidy up existing code. And of course, their favorite activity is fixing bugs.

软件开发人员将大部分时间都花在除构建之外的其他任务上。 他们参加会议，讨论规格，计划并整理现有代码。 当然，他们最喜欢的活动是修复错误。

I’ve yet to meet a developer who loves finding issues in their codebase. But this frustration likely stems from the fact that finding and reproducing errors takes a long time.

我还没有遇到喜欢在他们的代码库中发现问题的开发人员。 但是，这种挫败感可能源于发现和重现错误需要很长时间的事实。

Historically, software developers have had to search for the needle in the haystack. They’ve had to find the answers themselves, rather than relying on those screenshots from users posted in a Microsoft Word document.

从历史上看，软件开发人员不得不在大海捞针中进行搜索。 他们必须自己找到答案，而不是依靠Microsoft Word文档中发布的用户的屏幕截图。

What browser and version are you using? What OS? Can you tell me exactly where you clicked? Then what happened? What page were you on before? How did you even get to this screen?

您使用什么浏览器和版本？ 什么操作系统？ 您能告诉我您点击的确切位置吗？ 那怎么了 您之前在哪个页面上？ 您甚至是怎么进入这个屏幕的？

So many questions, so few (useful) answers.

这么多的问题，那么几个(有用的)答案。

Debugging an issue can take forever!

调试问题可能需要很长时间！

依靠用户报告问题 (Relying on users to report problems)

Many software development teams still rely on users to report problems with their applications.

许多软件开发团队仍然依靠用户来报告其应用程序问题。

Which is kinda crazy these days.

这些天有些疯狂。

It’s just like fast food restaurant chains. They put the onus on customers to clear their own tables by providing trays and trash disposal stations. The restaurant’s food might have been terrible. But the customer could’ve calmly cleared their table, dropped off their trash, and walked away. Unless they take the time to complain, staff assume another happy customer just left the restaurant.

就像快餐连锁店一样。 他们提供托盘和垃圾处理站，让客户有责任清理自己的桌子。 这家餐厅的食物可能糟透了。 但是客户本可以冷静地清理桌子，放下垃圾，然后走开。 除非他们花时间抱怨，否则工作人员会假设另一个快乐的顾客刚离开餐厅。

But they’ll never return.

但是他们永远不会回来。

Some developers expect users to fend for themselves when using their applications. After all, if nobody is reporting problems, we don’t have any — right? Putting the onus on your users to report the problems they experience is limiting. You will see around one percent of the total instances affecting your entire user base, and technical details will be thin and inconsistent.

一些开发人员期望用户在使用他们的应用程序时能自己照顾自己。 毕竟，如果没有人报告问题，那么我们就没有问题-对吗？ 限制用户报告自己遇到的问题是有限的。 您将看到影响整个用户群的实例总数的大约1％，而且技术细节比较薄弱且不一致。

Developers will spend more time trying to debug the problem — using small bits of information — than fixing it. That’s if they can find the problem at all.

与解决问题相比，开发人员将花费更多时间尝试使用少量信息来调试问题。 那就是说他们根本找不到问题。

您的软件不如您想像的好 (Your software isn’t as good as you think it is)

I was talking to a friend of mine who works for a large online retailer. He explained to me how they’d found a big problem in their online ordering system that nobody had known about.

我当时正在与我的一个朋友合作，该朋友为一家大型在线零售商工作。 他向我解释了他们如何在他们的在线订购系统中发现一个没人知道的大问题。

After several days of investigation they couldn’t pinpoint the problem. At that point, they decided to try out a dedicated tool to detect and diagnose errors in their application.

经过几天的调查，他们无法找出问题所在。 那时，他们决定尝试一种专用工具来检测和诊断其应用程序中的错误。

What they found was alarming.

他们发现令人震惊。

The tool identified that one of the eight servers was running out of memory and throwing errors. This caused the user’s checkout flow to grind to a complete halt.

该工具确定八台服务器之一已用完内存并引发错误。 这导致用户的结帐流程变得完全停止。

One in every eight user checkout sessions was broken.

每八个用户签出会话中就有一个被破坏。

Finding and fixing this issue resulted in an immediate uptick in sales of $20,000 a month! People were no longer running into problems during the purchase process.

找到并解决此问题后，每月销售额立即增加了20,000美元！ 在购买过程中，人们不再遇到麻烦。

They estimated that it had affected over 5,000 users — yet they had only received two support tickets about it.

他们估计它已经影响了5,000多名用户，但他们只收到了两张与此有关的支持票。

Although the team was happy to find the issue, there was also a crushing disappointment. An unidentified error had likely resulted in upwards of $100,000 in missed revenue.

尽管团队很高兴找到问题，但也有令人失望的失望。 一个无法识别的错误可能导致超过100,000美元的收入损失。

发生错误时通过电子邮件发送电子邮件给自己是一个愚蠢的主意 (Emailing yourself when errors occur is a dumb idea)

You can sit watching a live stream of problems happening in your code tailing logs. And you can hire a warm body to do so while you’re asleep. Or, you can email yourself when an unhandled exception occurs — seems like a great idea!

您可以坐下来观看代码尾注日志中实时发生的问题。 您可以在睡觉时雇用温暖的身体。 或者，当发生未处理的异常时，您可以给自己发送电子邮件-似乎是个好主意！

Until you do it.

直到您做到。

If you set this up, it might look like this:

如果进行了设置，则可能如下所示：

public void TryProcessLineNumber(int lineNumber){    try    {        ProcessLineNumber(lineNumber);    }    catch (Exception ex)    {        LetMyselfKnowViaEmail("Something went wrong: " + ex.Message);    }}

But beware of the problems it can create.

但是要当心它可能造成的问题。

Emailing errors might be suitable for smaller side projects and personal projects. But once you expand outside of that, things start to get messy. Very, very messy:

电子邮件错误可能适用于较小的副项目和个人项目。 但是，一旦超出此范围，事情就会开始变得混乱。 非常非常混乱：

• Diagnostic details are limited
  诊断细节有限
• It’s hard to set up notification rules and things start to get noisy
  设置通知规则很困难，事情开始变得嘈杂
• An exception caught in an infinite loop can send 50,000 emails to your inbox overnight
  陷入无限循环的异常可能会在一夜之间将50,000封电子邮件发送到您的收件箱
• Errors have no priority level or impact visibility and all appear equal
  错误没有优先级或影响可见性，并且所有错误看起来都相等
• After you reach more than one hundred emails, you give up reading them
  收到一百多封电子邮件后，您就放弃阅读它们

Not long after you start emailing yourself errors, you start ignoring them. Or you filter them into a folder because there is just so much noise and no signal.

在开始通过电子邮件向自己发送错误后不久，您就开始忽略它们。 或者您将它们过滤到一个文件夹中，因为有太多的噪音而没有信号。

You’re left to trawl through thousands of emails looking for the right error instance.

您将被浏览成千上万的电子邮件，以寻找正确的错误实例。

We need something smarter.

我们需要更聪明的东西。

ELMAH-记录您的异常 (ELMAH — logging your exceptions)

ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for recompilation or redeployment.

ELMAH(错误记录模块和处理程序)是应用程序范围的错误记录工具，可完全插入。 可以将其动态添加到计算机上正在运行的ASP.NET Web应用程序甚至所有ASP.NET Web应用程序中，而无需重新编译或重新部署。

ELMAH doesn’t support every programming language and platform. Since its functionality is fairly limited when drilling into the root cause of an issue, it’s usually used for smaller projects. It’s also not really in active development these days, but at least it’s something, and it’s free.

ELMAH并不支持每种编程语言和平台。 由于在探究问题的根本原因时其功能相当有限，因此通常用于较小的项目。 如今，它还没有真正处于积极的开发中，但是至少它是某种东西，并且是免费的。

ELMAH is basically a NuGet package for .NET web applications. It logs every exception that occurs on one or more websites to the storage you choose. Unlike other logging frameworks, ELMAH logs into every exception automatically when configured in its simplest form. Sure, there’s an API you can use to log custom errors. But most people only use the automatic part. In this tutorial we will only focus on the basic parts.

ELMAH基本上是.NET Web应用程序的NuGet程序包。 它将一个或多个网站上发生的所有异常记录到您选择的存储中。 与其他日志记录框架不同，ELMAH以最简单的形式配置后会自动登录到每个异常。 当然，有一个API可用于记录自定义错误。 但是大多数人只使用自动部分。 在本教程中，我们将只关注基本部分。

Here’s a great tutorial on how to get started.

这是一个很好的入门指南。

专用的错误和崩溃报告工具 (Dedicated error & crash reporting tools)

If you’re serious about handling errors and crashes in your applications, use a dedicated error monitoring tool. It detects and diagnoses problems affecting your users automatically by adding a provider to your application code.

如果您认真对待应用程序中的错误和崩溃，请使用专用的错误监视工具 。 通过将提供程序添加到应用程序代码中，它可以自动检测并诊断影响用户的问题。

It’s a few lines of code — thats all it takes.

只需几行代码，仅此而已。

Using a tool like this allows you to:

使用这样的工具，您可以：

• Cut out noisy exceptions and focus on the things that matter, like impacting users
  消除嘈杂的异常，并专注于重要的事情，例如影响用户
• Set up configurable notifications via email, Slack, or HipChat
  通过电子邮件，Slack或HipChat设置可配置的通知
• Use one tool to track multiple languages and platforms
  使用一种工具跟踪多种语言和平台
• Take advantage of error grouping for similar errors
  利用错误分组来处理类似错误
• Keep your whole team on top of errors and their resolution
  让您的整个团队始终掌握错误及其解决方案

Tools like these are not cheap or free like the other programs we’ve discussed, but what price do you put on your time? Say you use a free solution. Then you have to stop coding for three hours while you try to reproduce a bug. This is actually a very poor return on investment.

像我们讨论过的其他程序一样，这些工具并不便宜或免费，但是您花了多少时间呢？ 假设您使用免费的解决方案。 然后，在尝试重现错误时，必须停止编码三个小时。 实际上这是非常差的投资回报率。

Teams who are looking to move quickly and deliver new functionality to users would say that such professional solutions are worth every cent. They can cut the time developers spend fixing bugs and get them back to coding and building improvements.

希望快速行动并向用户提供新功能的团队会说，这样的专业解决方案值得每一分钱。 他们可以减少开发人员花在修复错误上的时间，并将它们重新用于编码和改进方面。

Even if you think your code is perfect, and users are not having any issues, plug in a tool like Raygun. You’ll be surprised at what you find.

即使您认为您的代码很完美，并且用户没有任何问题，也可以插入诸如Raygun之类的工具。 您会对发现的结果感到惊讶。

采取积极主动的态度并获得回报 (Take a proactive approach and reap the rewards)

We’d all love for technology to fix our software issues automatically. Unfortunately, I think we’re a while away from self-healing and self-aware software.

我们都希望能够自动修复软件问题的技术。 不幸的是，我认为我们距离自我修复和自我意识的软件还有一段时间。

You can also plug error monitoring solutions into developer workflows to make error and crash resolution easier. But data is often soiled and segregated from context in other systems.

您还可以将错误监视解决方案插入开发人员的工作流程中，以使错误和崩溃解决更加容易。 但是，数据经常在其他系统中被弄脏和与上下文隔离。

The future of error monitoring lies in making sure all teams — front end, back end, management or support — have complete visibility on every problem their users encounter. And then have the ability to solve it right away.

错误监视的未来在于确保所有团队(前端，后端，管理或支持)对用户遇到的每个问题都具有完全的可见性。 然后有能力立即解决它。

This also extends to upcoming trends in the continuous delivery and deployment space. You can apply fixes and ship to production within minutes of identifying the problem. You don’t have to wait weeks before the next major deployment.

这还扩展到了持续交付和部署空间中即将出现的趋势。 您可以在发现问题后的几分钟内应用修补程序并交付生产。 您不必等待下一个大型部署的几周。

Put the focus on your team when handling errors and crashes in your own applications. Discover problems before your users do, and don’t rely on them to report errors.

在您自己的应用程序中处理错误和崩溃时，请把重点放在您的团队上。 在用户遇到之前先发现问题，不要依靠它们来报告错误。

Because they won’t.

因为他们不会。

翻译自: https://www.freecodecamp.org/news/why-relying-on-your-users-to-report-errors-is-the-dumbest-thing-youll-ever-do-cca307fa67f0/

没有事情,错误1503