Finding your bug is a process of confirming the many things that you believe are true — until you find one which is not true.
—Norm Matloff
第一次接触网页开发是两三年前的事，那时我曾经问过计划带我入门前端的前辈：入门前端的标准是什么。他当时用一种极平和的语气和我说：学会dubug。几年后的今天我即便也写过一点网页工具，但还是依然没能入门。反思一下：一是 JavaScript 学的不好，二就是不敢说自己有多少 debug 的能力。
遂放弃。
最近因为需要又要涉及一点网页工具开发，同时因为需求整体和 R 交互比较多于是决定用 R 的 Shiny 来搞一搞。
写了一个多星期我感觉 Shiny 确实解决了不熟悉前后端交互的人写网页的大多数问题，但如何 debug 的门槛还是摆在那里。比如前几天一个高手和我吐槽写 Shiny 时不知道改了什么突然不能正确运行了，更糟心的是还没有任何报错信息。当然，后来经过讨论发现其实并非没有报错信息，只是那时他没有找到而已。
这篇文章就结合最近学习的一点资料，大致聊聊在 Shiny 中 debug 的一些方法。
Shiny debug 主要有三个步骤，分别是调试(Debugging)，追踪(Tracing)和错误处理(Error handling)。
- Debugging: 所谓的调试就是猜，然后在你认为可能有错误的地方设置一个断点，再执行接下来每个语句的时候就都可以检查程序当时所在的状态。
- Tracing：可以在运行程序的时候收集程序运行产生的信息而无需暂停程序，在诊断系统性问题时因为我们无法频繁的中断使用这一方式就比较合适。
- Error handling: 在客户端和服务器端找到错误的来源并确定原因。
Debugging 调试
breakpoints 断点
说到「断点」，我不由的想对 bug 说一句：
静静地陪你走了好远好远，连眼睛红了都没有发现。
如果你知道哪一行的代码有错（这话本身就像bug）或者猜测很可能是哪里不对，就可以直接在所在行设置一个断点。Rstudio 只需在行号左边点一下鼠标就会出现红点提示标记成功。开始运行 Shiny 程序后会在断点处停止执行，然后就可以开始逐步执行进行代码调试了。
如上图所示，我们在 40 和 41 行设置了两个断点，现在点击 Run App，代码运行会在 40 行处停下，绿色的箭头指向 41 行，并且在 console 中会有 browse输出，如下图所示
这个时候我们可以方便的查看环境中已有的变量，例如这里已经运行完毕的 x 变量。如果想继续运行，可以点击 console 里的 continue，程序又会向下运行。
现在环境中存在 x 和 bin 两个变量，同时在 console 的 browse[2]> 处你可以进行正常的 R 操作，例如查看变量内容或者做个加法运算，甚至你可以修改当前存在环境中的变量（当然不推荐这么操作）。
说到缺点，目前 breakpoints 只可以在 Rstudio IDE 中使用，而且只能用于ShinyServer函数中；另外如果代码很长显然不停的断点也很烦，同时它只能显示发生了什么但是无法告诉你为什么有些事情没有发生。
小结如下：
browser() 命令
其实从上面 console 的截图也可以看到，断点就是执行了一次类 browser() 操作。但和断点不同的是，browser() 本身可以被写到任何地方。写法如下图所示：
说明：你现在从简书看到的为本文的付费版本，如果需要可以付费继续阅读。当然，完整的文章可以在我的个人博客免费阅读，欢迎继续查看。
