早晨到达时，即使您昨天晚上离开时，软件仍然无法运行。

你是做什么？您首先要检查什么？您如何做才能停止生气并开始解决您的问题？您会怪您的同事，然后直接去找他们吗？如何避免出现这种情况？

通常的嫌疑人是：

• 您以为它在昨天工作了，但是经过一整天的工作，您却盲目地意识到它没有用。

• 今天早上，您不再可以参考昨天的IDE高速缓存中的内容。

• 工作站已于昨晚重新启动，或进行了每晚维护操作/ tmp目录。

• 代码库中的某些内容发生了变化：检查某人（可能是您自己）是否在昨天的最后一次编译和今天的最后一次编译之间提交了更改。

• 支持库中的某些更改：检查这些库是否已重新编译或升级。原因可能是特定库的项目内部，也可能是由于部署了看似独立的软件包的新版本而导致的外部原因。

• 测试环境发生了一些变化：虚拟机的新版本，已修改的存根，远程数据库服务器中的更改...

• 编译链中发生了一些变化：Makefile，IDE的新版本，编译器和标准库中的更改...

1）如果今天不工作，那么昨天也不工作。

您以为它在工作，但是没有。

2）有一个问题，必须解决。

不要考虑谁对此负责或指责别人。

如果昨天和今天之间没有任何变化（例如我想阅读您的问题），则意味着您在实际声明其工作之前，应该在测试代码方面做得更好。

为了避免这种情况，您必须进行适当的测试和调试。

定义“工作”并测试代码例程的边界。

• 尝试成为将使用您的程序或代码功能的用户之一。
• 将您的代码推送到允许的限制和更高的范围，并实际检查它是否中断。

一种方法是在夜间运行一套自动化的全面测试，以便您在第二天就可以检查是否出了问题并解决问题。

试图找到某人来承担责任是没有建设性的，不能解决问题。不要这样

如果某件事情昨天起作用而现在不起作用，那么要么您具有不确定性行为（例如种族条件），并且昨天起作用了只是运气，或者从那时到现在，事情已经发生了变化，那么您需要找出它的作用。是。

您如何确切地确定哪种情况以及如何解决取决于情况的具体情况，但这始终有助于系统地消除原因，即不要一次更改5件事并停止寻找是否有帮助-找出导致问题的具体原因，并写下解决方法，以便在3周后再次发生时进行查找。

使用适当的诊断工具（调试器，探查器，网络分析工具）也可以带来很大的不同。

我曾经处理过似乎在一夜之间发生更改的代码，但一段时间后我得出结论，这是由于恶​​意小精灵在夜间爬入我的代码库并以某种方式进行了更改，尽管事实上它在昨天仍然有效，但现在根本不起作用。确实，在经典的Schroedinbug风格中，它不仅现在不起作用，而且清楚地表明，它不可能有。

随着时间的流逝，我已经意识到，实际上小精灵可能与它无关，而且我的“回家的时间，这将足够好”的最后一个构建并没有得到应有的详细测试和关注。 。

我在早上遇到此问题时的第一个假设是，这可能是我的错，因为我通常是负责自己的功能或正在开发的软件工作的人。我的第二个假设是我现在也应该喝咖啡。如果不是很明显地可以看出猴子（有时是猴子），那么我就很有可能设法将其拖入旧版本的库中，错误地回滚了不需要滚动的文件退回或在某些地方缓存了某些内容，将其带入了构建而不检查它。进行我最近的Source Control活动往往会揭示我已完成的工作，清理构建通常会删除错误的缓存版本。

有时候，这与我无关。有人更新了一个依赖关系而没有提及它，WindowsUpdate安装了一些更改了环境的东西，因此我的代码无法正常工作。有很多背景方面的可能性，但通常情况是有人举手接受，就像大多数人一样，我基本上是个白痴。

使用版本控制。进行比较，或使用VCS的责备功能。

• diff：每个VCS。向您展示了不同版本的区别
• blame：例如git。逐行显示更改了哪些内容的人

如果没有版本控制，除了它是您自己的错误或老板的过错之外，您还可以查看文件的更改日期，还可以查看操作系统的日志记录功能。

除此之外：重新编译所有内容，确保还重新编译辅助库。

当然：如果您发现错误的根源，请保持冷静，询问为什么要进行更改，解释您的问题，并提出使双方都满意的解决方案。不要对她/他大喊大叫，这会损害您的工作效率。

如果根本没有更改，那么该查看系统上已更改的内容了。例如，最近Mac OS计算机已更新到Apache的新版本，从而导致某些配置无效。

好吧，这是一个真实的代码示例，它“在昨天工作”而不是在今天工作……它来自本月初。

有问题的应用程序按日期从数据库中获取信息，默认行为是获取当天的数据。8月8日工作正常，但9日失败。尚未对此进行过测试。它也可以在9月9日和10月10日工作。

另一个线索是我们在英国，有问题的数据库在美国。

因此，对于您首先要检查什么的问题，我的答案是仔细检查日期的格式，因为如果您将日期和月份字段混合使用，则可以很好地工作，但每月仅工作1天：-)

修复该错误（但是您通常会这样做）。然后，如果您发现是谁造成的，请向他们发送一封礼貌的电子邮件，让他们知道出了什么问题。

每个编码员都会犯错，如果您开始责备他人，那么下次您做同样的事情时，它将严重地适得其反。（可能甚至是您的错误）

只有当您怀疑它们过于粗心时，您才应该从几个错误中做出很多贡献。

...您进行回归测试，并专注于失败的测试。

实际上，这是您昨天离开之前忘记要做的事情，它发生了。

你没有吗 好..你在说什么？责备？好吧... 那可能行得通

当某些事情停止工作时，要做的第一件事就是问自己-有什么不同？有什么变化？

当某件事昨晚工作但今天早晨失败时，显然已经改变的一件事是- 日期和时间 :)

我会尝试思考我正在处理的逻辑中是否有任何部分取决于日期，并且可能会受到时间流逝的影响。令人惊讶的是，造成这些问题的原因是多少次。

如果失败，那么您绝对应该遵循此处提供的其他出色建议。

一个简短的答案（写），但想要得到它的要点是一个漫长的：为什么程序失败： Andreas Zeller的系统调试指南（可能看起来有点学术性，但不是）

当单元测试失败时，您可以在Continuous Integration引擎发送的邮件之后查看您的邮箱（如果您没有注意到该特定问题，请查看日志页面），然后查看在此构建之前谁进行了检入。

然后去和他或她说话。

您的代码今天失败，但昨天仍然有效的原因只有两个。

看数据

您没有测试和/或考虑的数据中有某些东西。直到未曾预料到的逻辑情况发生，否则数据没有得到正确验证或逻辑错误才被发现。这意味着该漏洞是昨天存在的，但是在有效数据下它对您隐藏了。

我曾经有一些订单输入代码可以正常运行数周。我有一天回家，死了。第二天的调查显示，我在函数调用链中隐藏了一个错误。在弱类型语言中，当我应该使用long int时，我声明了一个整数。该语言自动在两者之间进行转换，直到无法进行转换为止，因为该数字超出了整数所能容纳的范围。系统因订单号32768而失败。

看看发生了什么变化

看看自从工作以来发生了什么变化。IT部门是否发布了操作系统更新？另一个编码器是否修改了程序使用的代码？用户的权限是否发生变化？通常，如果您发现更改了，就会发现该错误。

二元印章

对于难以处理的JavaScript错误特别有效。基本上注释掉一半的代码，看看是否得到错误，如果出错，则在代码的那一半中。再把一半再继续。

如果您的代码得到了很好的封装，这将是一个很棒的，省时，省力的工具。

找到有罪的代码后，通常值得在其自己的测试页上隔离错误。

当然，可以采取什么措施避免出现这种情况？

要解决此问题，您可能需要研究持续集成（CI）。简而言之：CI是开发人员经常（一天多达几次）集成和测试所有代码的过程。这样做的想法是，可以迅速找到对一个模块的更改而使另一个模块中断。

实际上，大多数使用CI的团队都使用CI服务器（请参阅：Wikipedia的列表）。通常将CI服务器设置为监视SCM存储库并在看到更改时开始构建。构建完成后，它将运行一系列自动化测试，并通过电子邮件和/或构建和测试的网页发布结果，以及导致构建的更改。希望当某些事情确实破坏了构建或测试时，您只需要查看很小的更改，因此可以更快地解决。

关于使用哪个CI服务器，这里还有其他问题，因此，我将让您有兴趣地找到它们。就个人而言，我是詹金斯的忠实拥护者。

[我该怎么办？

正如其他人已经说过的那样，找出导致问题的原因并尝试对其进行修复。花费时间试图怪罪是花费在解决问题上的时间。

我的自然反应是总是责备别人，但是随着时间的流逝，我逐渐意识到通常是我自己的错。除了上面所有出色的评论外，重要的是您自己记录一下最终原因。无论您使用与其他团队成员共享的Wiki，私人Twiki，Evernote，日志还是美好的回忆都没关系。重要的是，目前您找到答案（并且想恢复工作！）是记录原因。

如果它不再起作用，则可能是您已识别出它不起作用的症状，即它挂起或向用户返回了特定的错误对话框。

如果对问题的唯一描述是“它不起作用”，那么您要做的第一件事就是收集有关问题症状的更多信息。

然后，您开始寻找可能的原因，无论是通过日志还是尝试重现问题，或者两者兼而有之-我想这取决于您系统的设置方式。

然后，您将它们排除在外。

那是我休假时通常发生的事情:-)

更严重的是，我先告诉他们：

• 我将对其进行调查，以了解问题所在以及可能的根源

• 一旦有机会看到发生了什么事，我将在30-60分钟内触及基地

在那之后，我可能会估计一下可能发生的情况，以及如果尚未修复将花费多长时间进行修复的估计值，以及（如果适用）我们可能会丢失的数据的估计（但是我有很好的备份，因此永远不会发生）希望）。

至于责备部分：

• 如果这只是同事的错别字，那就不用说了：狗屎发生了，臭虫吓坏了，很可能教了他一堂课，希望他不会再做。

• 如果他有意做些我告诉他不要做的事（例如，将生产服务器的根密码提供给新人，并告诉他在没有监督的情况下直接对其进行修改）（是的，那已经发生了……），那么我不得不提。

如果您通常的错误跟踪方法不起作用，并且一切都一团糟，那么拥有一个可以轻松还原的备份会很棒。

这是我在本地运行的，每小时8am至6pm自动运行：

rdiff-backup /path/to/mystuff /path/to/mybackup

简单吧？

如果您必须还原任何内容，请使用

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff进行备份只存储了不同的文件。您可以在Linux，Mac和Win上使用rdiff-backup。

当然，这不应该是您唯一的备份。但是，拥有本地备份是一种非常简单且便宜的方法。

现在，我不建议您将其作为正常的错误修复方法，但是，如果其他所有方法均失败，则这是一个后备方法。

该错误可能已经存在，但由于外部因素或深层的系统问题而被隐藏。

这发生在我身上。在我们的项目的两个版本之间开发了一个错误。从字面上看，我们所做的唯一更改是将基础库之一更新为最新版本。

当然，我们责怪他们。但是他们所做的唯一更改是重构了一些标头以加快编译速度。我同意那不应该破坏系统。

许多调试后，它原来，问题是，已在潜伏了一个流氓指针错误我的代码多年。直到它们的重构改变了可执行文件的排列之后，它才以某种方式从未被触发。

由于它已被正确使用，因此它昨天可以正常工作。

您会发现其他人使用事物的方式似乎不是打破事物的好方法。

在一天中的早些时候更新代码始终是一件好事，因为这为您提供了一个良好的测试环境。

备份！

我发现设置断点来暂停和检查我的数据非常有帮助，可以准确地指出发生问题的地方和情况。