修复错误是一项不可或缺的编程活动。编写没有错误的代码是不可能的——你总是从一些东西开始，测试它，然后修复任何错误。在你自己做的项目和工作中的商业项目之间，处理 bug 的经验大不相同。在本文中，我将演示如何处理工作中的新错误。
错误来自哪里
我遇到的大多数错误都来自与客户密切合作的同事，他们担任服务台或客户成功角色。他们在帮助客户解决问题或实现目标的同时发现问题。某些问题的解决方案是调整应用程序中的设置或更新数据库中损坏的数据：在这种情况下，服务台人员会解决这些问题。当他们看不到自己解决问题的方法时，他们会写一张开发票。这些票最终会到达我的办公桌。
它甚至是一个错误吗？
与业务应用程序相关的错误可能非常微妙——以至于不能完全清楚给定行为是否正确。有时，它在很大程度上取决于上下文：也许一个客户有一个他们喜欢一种行为的工作流程，但当前行为对于其他客户来说是最佳的。
\ 在大多数情况下，触发创建工单的是某个特定客户的需求。因此，我们需要确保修复不会让所有其他客户不满意。为了避免这种回归，我们经常在更大的群体中讨论需要哪种行为。如果对不同的客户有不同的行为是必不可少的，那么我们可能需要在每个客户的基础上控制这部分。在这些情况下，错误报告成为功能请求。
重现错误
当我们同意某些行为是出乎意料的时，我需要一种方法来了解它是如何发生的。否则，我将更改代码而没有看到更改的影响。盲目地调整代码可能会导致引入更多错误。我们对应用程序的设置有点复杂：我可以在本地重现大多数问题，但对于某些问题，我需要使用外部服务器。
本地
在开发人员的机器上重现问题是最好的情况。这允许在处理工单时进行快速反馈循环。大多数系统都很好地独立地重新创建，以在我维护的应用程序中创建本地环境。当我可以在本地机器上重现有问题的行为时，我的更改会有一个简短的反馈循环，并且我能够快速迭代代码并修复错误，而不会浪费很多时间。
\ 不幸的是，我们的项目有些复杂，无法在本地重现一些错误。对于开发环境，系统的一些部分有所不同：
\
- 仅部分可用于非生产环境的遗留数据库，以及
- 我们为本地和测试环境关闭的第三方集成——比如在订单上订购包裹运输。
在测试服务器上
对于我的工作，我们为测试环境复制了一些客户数据，它比本地设置更接近实际应用程序。如果错误没有在本地发生，那么测试服务器是下一个要检查的地方。这样做远非完美。在我可以对它们进行实际测试之前，任何修复都需要很长的路要走。
\ 在专用测试服务器上进行测试比直接在生产环境中进行测试要好得多，因为如果出现严重问题，我们仍然可以在客户受到影响之前修复它们。
关于生产
最后的希望是亲眼看到错误。如果错误是客户特有的，则可能取决于他们帐户或数据中设置的确切组合。在产品上重现错误有助于保持理智：它可以确认错误报告没有错误。但是，即使是最细微的代码更改也将生产用作测试区域是一个坏主意——它很慢，如果我搞砸了，客户就会受到影响。
将票退还给作者
如果我自己无法重现该错误，那么我无能为力。在这种情况下，我要求票务记者提供更多信息，有时我什至会通过屏幕共享让他们通话，这样我们就不会花太多时间进行同步。
\ 许多事情都可能导致该错误。
\
- 可能票证遗漏了有关应该出现错误的场景的一些关键细节，或者
- 也许我错过了一些细节，或者
- 也许这只是一个小故障
另一种可能性是，自最初的错误报告以来，有人在此期间修复了该问题。
在代码中查找源代码
在讨论了预期的行为并看到了错误之后，我准备通过代码并调查它的工作原理。根据代码质量，这个任务在组织良好的项目中可能非常容易，如果我们有“意大利面条代码”的情况，则非常复杂。
修复 + 添加测试
最后一步是改变行为并测试改变。作为绝对最低限度，我需要看到我的错误已从应用程序中消失，因此我重复重现步骤并查看结果是否比以前更好。
\ 如果应用程序运行正常，那么下一步就是添加一些自动化测试。最直接的方法是在刚刚更改的方面添加一些单元测试。全面覆盖涉及通过端到端 (E2E) 测试检查用户体验变化。
\ 您可以在我的其他帖子中阅读有关测试各个方面的更多信息：
\
也在这里发布
\
原文： https://hackernoon.com/what-fixing-a-bug-looks-like?source=rss