变成更好的Bug-Fixer

Question

我喜欢做程序员。好了，我说了。然而，尽管如此，我最近意识到我真的无法忍受错误修复。完全没有。

事实上，当我在开发一些东西的时候，我的生产力是非常高的。即使在编写单元测试和对我的开发进行自我测试时，我通常也很有效率。我能很好地集中注意力，也能完成任务。

然而，当QA时代到来时，我正致力于修复bug，我的灵感就急剧下降。我不得不强迫自己采取非常极端的措施(你知道，高BPM音乐，过量的咖啡因等等)做任何事。我的工作通常涉及进入一个现有的大规模项目，添加新特性或修复bug，所以我不能确切地告诉我的雇主我需要几周的时间来为他们的所有代码编写单元测试:)此外，我们经常使用的服务器技术对于单元测试和集成测试都是非常困难的，因为它存在相当多的Java类加载问题。我并不完全反对错误修复，有时它可能很有趣，但是当你必须做一些小的改变，等待30秒到3分钟才能看到它们是否工作(因为系统的工作方式)时，这一点都不好玩。

我如何提高我的生产力和动力，当错误修复？这是大多数程序员都要处理的问题吗？

Answer 1

当你必须做一些小的改变，等待30秒到3分钟才能看他们是否工作的时候，这一点都不好玩。

这才是真正的问题。当你不得不等待很长时间等待反馈的时候，你会觉得没有效率，我知道这种感觉。也许可以伪造更多的服务并创建更好的测试工具，这样您就可以立即得到反馈。

单元测试遗留代码很昂贵，或者可能涉及危险的重构。但是，与分钟相比，创建更好的测试夹具可以让您在几秒钟内完成测试，并且您可以获得与使用新的单元可测试代码几乎相同的工作效率。

等待反馈太久是无聊的，令人沮丧的，而不是修复错误本身的行为。

Answer 2

错误修复是你应该学习的一项非常重要的技能。我在某个地方读到，通常一个人花80%的时间来解决应用程序中的20%的问题。

我相信从错误中吸取教训，而错误修复是一个从别人的错误中吸取教训的机会。你可以把它作为一个学习，并将有助于成为一个更好的程序员在未来。这就是我开始修复大量bug并着手重新分解代码时的动机。

Answer 3

就我个人而言，我发现停止将but视为“小事情”是有帮助的，而是将其视为与巨大特性同样重要的大型展示器，尽管它们只需要在调试几个小时后更改几行代码。这样的话，花一整天时间杀死3个bug跟踪器条目就不那么令人沮丧了(这种方法在一定程度上取决于你说服自己相信它的能力:-)。

也许这有助于让它成为一个游戏，例如，和你的同事一起(谁每天修复最多的bug)？或者更糟糕的是，谁每天做的重建次数最少？)