你还在等着用户反馈BUG?

译者按: 等待用户反馈 BUG，一切都晚了！实时监控线上应用才是王道。

本文采用意译，版权归原作者所有

我们热爱 coding。

当我们 coding 的时候，就如同从零建造一栋大楼。新的特性、新的功能、绝佳的设计都在每一次更新后被用户所使用，期待他们的喜爱和赞美。这样的一个过程让我们感到心灵上的慰藉和拥有为数不多的成就感。

然而，现实并没有想象中美好。

如果 debug 是移除 bug 的流程，那么编程就一定是将 bug 放进去的流程。

软件工程师将大量时间花在了其它事情上。他们需要参加各种会议、讨论需求、制定计划、将现有的冗余代码重构，以及还有一项花费时间很多的工作：修复 bug。

我还没有遇到过一位喜欢在代码中去找 bug 的工程师，大概因为查找和复现一个 bug 往往要花费很多时间。

一直以来，debug 就像大海捞针一样。他们需要亲自去发现问题的原因然后寻找解法，而不是依赖于用户的截屏反馈。

用户的截屏并不能告诉你足够的信息，往往你会问更多。

你用的哪个浏览器，什么版本，操作系统是哪个，可以具体一点告诉我刚刚你是怎么操作的吗，你之前在哪个页面，你是怎么到这个页面的？

就算问了用户这么多问题，也不一定能解决问题。

Debug 总是要花很多时间，然而还是一头雾水。

坐等用户反馈真的好吗？

很多开发团队依然依靠用户反馈来改进产品，这其实是很荒谬的。

在快餐连锁店，客户用餐完毕之后，需要自己将没吃完的食物和用过的餐巾纸扔到垃圾桶。快餐店的食物可能一点也不好吃，客户没吃几口就扔到垃圾桶然后直接走掉。除非客户真的是一个爱抱怨的人而且恰好有时间，才会如实评价。否则，你只会认为一个客户吃完饭满意的离开了。

然而，他再也不会来这里吃了！

一些开发者会这么认为：如果没有用户反馈问题，那就代表我们的产品棒棒哒，对不对？认为“如果用户使用产品遇到问题，用户就会反馈”是比较局限的。最终你会发现只有 1%的用户会反馈问题，然而事实上多得多。

开发者依靠很有限的信息去尝试 debug 一个问题，往往不能解决。

你开发的软件并没有你想象的那么完美！

一个在大型线上零售店工作的朋友跟我聊过他们解决公司线上订单系统的一个重大问题的故事。他们经过好几天的排查，都没有发现问题所在。最后决定使用一个专用工具来监控和诊断应用错误。

最终的发现令人惊恐！

八个服务器中的一个内存不足然后报错，导致用户的订单流程失败。也就是说：“每八个用户中有一个收到影响”。

发现和解决这个问题使得一个月的销售额提高了 2 万美元。事后评估发现总共影响了 5000 名用户，但是只收到 2 个用户反馈。虽然解决了 bug 大家都很开心，但这个错误导致了 10 万美元损失。

你可以坐在电脑面前盯着错误日志流。当你休息的时候，可以雇一个小伙伴这么做。或则，当异常出现的时候，给自己发报警邮件（貌似是个不错的主意）。直到你真的这么做了，你就不会这么想了！

你需要意识到：对于小的个人项目，一有错误就通过邮件报警还可以。但如果业务量起来了，访问量打了，事情就会变得一团糟：

你会开始忽略这些邮件，甚至把它们归类到一个单独的文件夹然后发现无从下手而很少去碰。毕竟，从几千封邮件中找到严重的问题并解决很不容易。

ELMAH (Error Logging Modules and Handlers) 是一个错误记录服务。它可以动态地加入到一个 ASP.NET 项目中，而不需要重新编译或则重新部署。ELMAH 不支持所有的程序语言，他提供的功能也有点局限。ELMAH 适用于小型的个人项目。

如果你想认真对待应用 BUG，可以使用一个专业的 BUG 监控服务，比如国外的Raygun（或则我们Fundebug）。一个专业的 BUG 监控服务可以帮你：

如果你使用简单的方案(直接邮件报警)，那么你需要停下手头的工作，花费两三个小时去复现一个 bug。这是非常浪费时间，非常低效的做法！如果一个团队注重快速迭代，那么他们会愿意为开发者节省花费的 debug 上的时间，去开发产品的新功能、新特性。

我们希望技术实现自动修复软件 BUG。不过，软件自愈依然还有一段距离。你可以使用一些错误监控服务来使得整个 debug 更加简单和高效。

在你的用户发现问题之前发现，并且不要单纯依赖用户反馈问题！

Fundebug专注于JavaScript、微信小程序、支付宝小程序线上应用实时BUG监控。自从2016年双十一正式上线，Fundebug累计处理了80亿+错误事件。欢迎大家免费试用！

转载时请注明作者 Fundebug以及本文地址：
https://blog.fundebug.com/2017/08/30/rely-on-users--to-report-error-is-not-good/

您的用户遇到BUG了吗？