我能给其他开发人员的最大建议

调试本身就很难。如果是全栈项目，那就更难了。

如果你正在调查React单页应用程序中的 bug，该应用程序会将数据发送到AWS上的无服务器后端，保存到数据库，然后刷新视图，那么你的架构中会有很多活动部件和不同的组件。即使重现 bug 并确定bug 所在位置也可能是一项艰巨的任务。

我在编写代码时（无论是实现新功能还是修复错误）遵循的口头禅，以及我在帮助初级（或更初级）开发人员时大多数时间都在重复的口头禅很简单：

缩小范围并加快反馈循环

这是什么意思？

缩小范围

• 将问题拆分成更小的问题
• 关注个别细微之处
• 对尽可能小的代码片段进行操作，并直接对其执行操作。

当然，你需要花一些时间来重现并彻底调查应用程序的异常行为。这很困难，但也非常有趣——这算是一项调查任务。
但一旦你找到了导致问题的代码片段——或者即使你只是有一些怀疑，也只需专注于那部分。其他的就不用管了。

提高生产力需要缩小范围，
消除杂乱。

关闭 React 应用程序的本地服务器，别再去检查 DBeaver 上的表了。别再想着检查 AWS 控制台的日志了。
你知道——或者你应该定义——你期望的输入和输出是什么。写一个单元测试来证明这一点。其他一切都不再重要了。

节省时间、点击和理智，只关注导致错误的代码。

加速反馈循环

简单地说，反馈回路就是让您了解刚刚更改的内容是否有效的循环。

• 重现错误
• 更改一些代码
• 检查错误是否仍然存在
• 再次更改一些代码
• 迭代直到错误消失

在执行此操作时，您不想花费大部分时间等待代码编译/热重载，您绝对不想浪费时间在应用程序中点击，用虚假数据填写表单（并在后端创建更多垃圾），您不想无聊地等待服务器响应。

你的反馈循环越短越快，你的效率就越高。你学习/精通编码的能力也就越强——因为你花更多的时间编写代码，而不是等待反馈循环或尝试重现导致 bug 的所有步骤。

不要一直重新加载应用程序，转到损坏的表单，填写它，等待后端的响应，然后读取所有地方的日志......

正如我所说的，您知道 - 或者您应该定义 - 您期望的输入是什么以及您想要的输出是什么。

如果可能的话，编写一个单元测试，或者如果有必要的话，编写一个集成测试（例如，如果您确实需要与 DB 交互）
只需打开 IDE，在调试模式下运行代码，设置断点并检查发生了什么。

（请不要依赖到处散布的 console.logs！）

进行一些修改，然后再次运行测试。
有时甚至不必是单元测试，一个简单的 js 文件调用你的方法，直接用 node 执行（始终打开调试器并设置断点）通常就足够了。
“但是……”你可能会说，“数据是从前端传入 Lambda 的，如果我每次不填写表单，我就不知道传入的数据是什么……”
好吧。那么，最后一次手动执行此操作，在网络控制台中检查发送的内容，或在 Lambda 日志中检查接收的内容（网关 API 总是将数据与其他内容包装在一起），将这些数据保存到文件中或在测试中对其进行硬编码，然后将其直接提供给行为异常的方法。

总结一下：

• 努力缩小问题的范围，
• 专注于较小的部分
• 找到每个快捷方式，让您快速重现错误并立即测试您的更改
• 加强反馈循环

调试愉快！

照片由Alexei Scutari、Paul Skorupskas和Jason Chen在 Unsplash 上拍摄