成为更好的错误修复程序

我喜欢成为一名程序员。在那里，我说了。但是，话虽如此，我最近才意识到我真的无法忍受错误修复。完全没有

实际上，在开发某些东西时，我的生产率非常高。即使编写单元测试和对开发进行自我测试，我通常还是非常有生产力的。我可以集中精力，并且可以完成任务。

但是，当质量检查时间到了并且我正在修复错误时，我的灵感得到了巨大的喘息。我必须采取非常极端的措施（例如，高BPM音乐，过量的咖啡因等）强迫自己完成所有工作。我的工作通常涉及到进入现有的大型项目并添加新功能或修复错误，因此我无法确切地告诉雇主我需要几个星期才能为他们的所有代码编写单元测试:)另外，我们经常使用的服务器技术对于单元测试和集成测试都是非常禁止的，因为它存在很多Java类加载器问题。我并不完全反对错误修复，有时它可能很有趣，但是一点也不有趣 当您必须进行细微更改并等待30秒到3分钟才能查看它们是否起作用时（由于系统的工作方式）。

修正错误时，如何提高工作效率和动力？这是大多数程序员处理的吗？

当您必须进行细微的更改并等待30秒到3分钟才能查看它们是否有效时，这一点都不好玩。

这是真正的问题。我知道这种感觉，当您必须等待这么长时间才能获得反馈时，您会感到无能为力。也许可以伪造更多服务并创建更好的测试工具，以便您可以立即获得反馈。

对遗留代码进行单元测试非常昂贵，或者可能涉及危险的重构。但是，创建更好的测试夹具可以让您在几秒钟内进行手动测试，而无需花费几分钟，可以得到与使用新的可单元测试代码几乎相同的生产率。

等待这么长时间的反馈很无聊且令人沮丧，而不是修复错误本身的行为。

错误修复是您应该学习的极其重要的技能。我在某处读到，通常一个人会花费80％的时间来修复应用程序中20％的问题。

我相信要从错误中学习，并且错误修复是从其他错误中学习的机会。您可以学习它，将来将成为更好的程序员。这是我开始修复大量错误并继续重构代码时的动力。

就个人而言，我发现停止将bug视为“小事情”很有帮助，而不是将bigtoptoppers与大型功能同等重要，尽管它们只是在调试数小时后才更改几行代码。这样，花费一整天时间杀死3个bug跟踪器条目就不会那么令人沮丧（此方法在某种程度上取决于您个人说服自己相信它的能力:-)。

也许与您的同事（例如，谁每天修复最多的错误？或者更糟糕的是，谁每天进行最少的修复？）一起使它成为一款游戏是有用的。）

我去过你的鞋子。尽可能在任何时间和地点构建自动化测试。不必一次全部。当发现错误时，请花一点时间尝试对测试用例进行编程。如果您无法编写测试用例，请在某个地方写一个关于如何手动测试的快速说明，例如单击此处，在其中键入内容等，然后将其放入某种知识库中。

调试可能非常繁琐，尤其是对于您未编写的复杂代码。提出一个目标，“在星期五之前修复Bug 13533”。如果您达到目标，“星期五晚上和我的同伴们喝一品脱”，那么就设置奖励。这将有助于使它更有意义。

除此之外，有时候工作就是……工作。

在这种情况下，您需要某种创造性的挑战。通常，它是在编写代码，但是这里不是。

但是，一切并没有丢失。努力解决您的元问题，并将精力投入其中。 为什么需要30秒到3分钟才能获得反馈？ 您如何缩短时间？（也许您可以编写一些未签入的脚本或实用程序应用程序来帮助您完成此操作）。那就是您的新问题领域-您的新创意挑战。

就个人而言，每当我处于缺陷修复阶段时，我都会确定最大的障碍，以快速而轻松地完成它，并且我需要自动化以消除这些障碍。这通常会提高生产力，并增加我的个人档案以供启动。

简而言之，我会说“一直在发展”。:)

您的问题是调试还是错误修复？如果您可以进行足够的调试以隔离导致问题的组件，则将其视为新的开发任务。

1. 编写仅用于破坏代码的一些单元测试。确保您已经进行了验证其所有所需功能的测试，以及一些特别能够隔离越野车行为的测试。
2. 编写通过您刚才编写的所有测试的新代码。
3. 将旧代码替换为新代码。
4. 运行一些集成测试。这是您要在三分钟内重新启动服务器的地方，但是如果您按照第1-3步做得很好，则应将其最小化。
5. 瞧！

也许您应该看一下Brian Hayes的“ Debugging Myself”（一篇于1995年发表在《美国科学家》上的文章）。您可以采取一些措施（例如，习惯性地使用Yoda条件）来减少或消除所产生的最讨厌的错误。

我认为调试虽然与编程相关，但与编程不同。特别是，调试多线程程序几乎与编写它们完全不同。

如果软件开发很无聊，那么您做错了。换句话说，这不是您的问题，而是您的平台和流程的问题。您是否考虑过使用动态语言（例如Python，Ruby，JavaScript）寻找职位，而不必等待服务器重启？

不幸的是，这是工作的一部分。您将有糟糕的项目和糟糕的雇主（我不是说这里是两种情况，只是概括一下）。

您可以针对他们的代码编写单元测试。尽你所能。一旦有了可以向老板展示的东西，您就可以扭转局面。

使用调试工具来修复速度慢的问题，使用单元测试来测试新代码，并使用它们来解决现有代码的问题以及将现有代码分解为更小的片段。

您可以应对挑战，并成为流程改进的英雄。而且，如果这行不通，您将有丰富的经验可以带给下一位雇主。

大多数程序员在职业生涯的某个时候都必须处理修正错误的个人问题。

正确的人与工作之间的距离对您的动力至关重要。不要过度或低估您的工作。如果您对自己的工作过于认同，那么您所描述的问题可能会浮出水面：您可能不太愿意修复这些错误，因为您有一半的时间都在指责自己。取得一些内在的距离，并找出如何合理地解决问题的方法。

关于平台上的特定问题，有几种方法可以减少较长的部署和测试时间（从侧面看，您的时间并不特别长）。

首先，测试时间越长，对货物崇拜的厌恶程度就越高。如果您进行更改，请考虑一下，直到您确信它将解决该错误为止。当然，自信程度取决于测试周期的长短。但是，如果您的测试周期变长，并且无法避免进行长时间的测试，请花更多的时间思考，您会在调试中得到回报并更加高兴，因为它更快并且具有“法式勒索”的美好时光。 ”。

其次，偏向于单元测试，而不偏向于集​​成测试。可以从难以调试的平台中消除所有故障点。

错误修复可以是“很棒的”或“乏味的”。我有一些游戏积分完全归功于修复了一个错误-其他人都无法修复的崩溃错误。但是Bugzilla的日常修饰令人麻木。小错误很乏味。重大错误值得。

这就是实现的事实：您拥有大量的次要错误列表，这本身就是一个主要错误。它只是不是代码错误。它是一个过程或管理错误。

找到该错误，并修复它。

在同事和熟人中，好的“调试器/错误修复器/问题解决者”发现的一件事是，他们通常喜欢解决难题。这可能意味着填字游戏，数字游戏（如数独）和逻辑谜题等。

因此，成为更好的错误修复程序的一种方法是花一些时间来解决问题或解决难题的技能。

这是一个Wikipedia链接，它可能是帮助您成为更好的问题解决者的良好起点。

提醒您，有些人更擅长解决问题，或者他们更喜欢解决问题。有些人根本不喜欢它，这使得强迫自己很难做-但请不要误会-如果您强迫自己学习成为一个难题解决者，那么将来变得更容易成为一个好的错误修复者。

修复错误通常感觉很麻烦，因为它可以使您感觉到错误占据了所有时间，并使您远离有趣的新事物。但是，现实是，错误修复是我们所做工作的很大一部分，而且它早于编写第一行代码并执行编译器就开始了。首次发布代码时，您可能已经花了数小时来修复错误，但似乎并不是那样，因为您在实现功能的过程中一直在修复它们。现实地说，无论您是多么优秀的程序员，bug都会渗入您的系统。

那么，如何使其变得有趣呢？好吧，我真的不能为您回答这个问题，因为我真的无法想象是什么使您的个人船只漂浮。对我来说，我有点工具迷，所以答案一直是拥有非常可靠的工具链和灵活的开发过程，所有这些都有助于减少错误的琐碎工作，而只是解决问题很快。我目前主要使用C＃进行开发，而且我一直在寻找可以消除编写软件的部分时间的乏味工具。我使用了一种称为TestQ的非常好的BDD API支持的测试优先开发方法。我使用Resharper来自动化大部分重构，并使用StyleCop限制诸如编码样式之类的事情。我对工具链的最新添加是包括NCrunch在我编写代码的同时在后台连续并同时运行我的测试，而事实证明，NCrunch确实改变了游戏规则。

所有这些工具的结合使我的工作效率近来得到了提高，因为我浪费很少的时间等待事物进行编译或执行。我在IDE中以视觉方式获得了即时反馈，以告知我有问题需要解决，并且以一种方式布置测试代码，使我可以在仅几行代码中精确地确定确切的位置。发生故障，但由于我从StoryQ收到的冗长的报告很可爱，导致发生故障的原因准确地告诉我测试的哪些部分通过，哪些失败以及失败在代码中的何处。由于将所有时间浪费在开发时间上，所以我很少花时间进行积极的调试，而将更多的时间用于解决问题以及编写测试和代码。高离职率使我很忙，并给我的任务带来很多变化。在工作期间，这也给了我很多时间去追求其他感兴趣的领域，以便我可以将新的和创新的想法注入到我们的产品线和流程中。