Abstract Background: In modern software systems’ maintenance and evolution, how to fix software bugs efficiently and effectively becomes increasingly more essential. A deep understanding of developers’/assignees’ familiarity with bugs could help project managers make a proper allotment of maintenance resources. However, to our knowledge, the effects of developer familiarity on bug fixing have not been studied. Aims: Inspired by the understanding of developers’/assignees’ familiarity with bugs, we aim to investigate the effects of familiarity on efficiency and effectiveness of bug fixing. Method: Based on evolution history of buggy code lines, we propose three metrics to evaluate the developers’/assignees’ familiarity with bugs. Additionally, we conduct an empirical study on 6 well-know Apache Software Foundation projects with more than 9000 confirmed bugs. Results: We observe that (a) familiarity is one of the common factors in cases of bug fixing: the developers are more likely to be assigned to fix the bugs introduced by themselves; (b) familiarity has complex effects on bug fixing: although the developers fix the bugs introduced by themselves more quickly (with high efficiency), they are more likely to introduce future bugs when fixing the current bugs (with worse effectiveness). Conclusion: We put forward the following suggestions: (a) managers should assign some “outsiders” to participate in bug fixing. (b) when developers deal with his own code, managers should assign more maintenance resource (e.g., more inspection) to developers.

中文翻译：

---

检查开发人员熟悉程度对错误修复的影响

摘要背景：在现代软件系统的维护和演进中，如何高效、有效地修复软件缺陷变得越来越重要。深入了解开发人员/受让人对错误的熟悉程度可以帮助项目经理正确分配维护资源。然而，据我们所知，尚未研究开发人员熟悉程度对错误修复的影响。目标：受开发人员/受让人对错误熟悉程度的理解的启发，我们旨在调查熟悉程度对错误修复效率和有效性的影响。方法：基于错误代码行的演变历史，我们提出了三个指标来评估开发人员/受让人对错误的熟悉程度。此外，我们对 6 个知名的 Apache 软件基金会项目进行了实证研究，其中确认了 9000 多个错误。结果：我们观察到 (a) 熟悉度是修复错误的常见因素之一：开发人员更有可能被指派修复他们自己引入的错误；(b) 熟悉度对 bug 修复有复杂的影响：虽然开发人员修复自己引入的 bug 更快（效率高），但他们在修复当前 bug 时更有可能引入未来的 bug（效率更差）。结论：我们提出以下建议： (a) 管理者应指派一些“局外人”参与错误修复。(b) 当开发人员处理自己的代码时，管理人员应该为开发人员分配更多的维护资源（例如，更多的检查）。我们观察到 (a) 熟悉度是修复错误的常见因素之一：开发人员更有可能被指派修复他们自己引入的错误；(b) 熟悉度对 bug 修复有复杂的影响：虽然开发人员修复自己引入的 bug 更快（效率高），但他们在修复当前 bug 时更有可能引入未来的 bug（效率更差）。结论：我们提出以下建议： (a) 管理者应指派一些“局外人”参与错误修复。(b) 当开发人员处理自己的代码时，管理人员应该为开发人员分配更多的维护资源（例如，更多的检查）。我们观察到 (a) 熟悉度是修复错误的常见因素之一：开发人员更有可能被指派修复他们自己引入的错误；(b) 熟悉度对 bug 修复有复杂的影响：虽然开发人员修复自己引入的 bug 更快（效率高），但他们在修复当前 bug 时更有可能引入未来的 bug（效率更差）。结论：我们提出以下建议： (a) 管理者应指派一些“局外人”参与错误修复。(b) 当开发人员处理自己的代码时，管理人员应该为开发人员分配更多的维护资源（例如，更多的检查）。(b) 熟悉度对 bug 修复有复杂的影响：虽然开发人员修复自己引入的 bug 更快（效率高），但他们在修复当前 bug 时更有可能引入未来的 bug（效率更差）。结论：我们提出以下建议： (a) 管理者应指派一些“局外人”参与错误修复。(b) 当开发人员处理自己的代码时，管理人员应该为开发人员分配更多的维护资源（例如，更多的检查）。(b) 熟悉度对 bug 修复有复杂的影响：虽然开发人员修复自己引入的 bug 更快（效率高），但他们在修复当前 bug 时更有可能引入未来的 bug（效率更差）。结论：我们提出以下建议： (a) 管理者应指派一些“局外人”参与错误修复。(b) 当开发人员处理自己的代码时，管理人员应该为开发人员分配更多的维护资源（例如，更多的检查）。(a) 管理者应该指派一些“局外人”参与错误修复。(b) 当开发人员处理自己的代码时，管理人员应该为开发人员分配更多的维护资源（例如，更多的检查）。(a) 管理者应该指派一些“局外人”参与错误修复。(b) 当开发人员处理自己的代码时，管理人员应该为开发人员分配更多的维护资源（例如，更多的检查）。