论文标题

自动识别持有的自我吸收的技术债务

Automated Identification of On-hold Self-admitted Technical Debt

论文作者

Maipradit, Rungroj, Lin, Bin, Nagy, Csaba, Bavota, Gabriele, Lanza, Michele, Hata, Hideaki, Matsumoto, Kenichi

论文摘要

现代软件是在相当大的时间压力下开发的,这意味着开发人员经常不必在编写良好的代码方面诉诸妥协,而代码的代码和仅能完成工作的代码。在过去的几十年中,这导致了“技术债务”的概念,这是一种短期黑客,可能会产生长期维护问题。自我吸收的技术债务(SATD)是一种特殊的技术债务形式:开发人员有意识地执行黑客攻击,但也通过添加评论作为提醒(或作为罪恶感的录取)来将其记录在代码中。我们专注于特定类型的SATD,即“持有的” SATD,其中开发人员在评论中记录了由于其工作范围之外的条件而停止实施任务的必要性(例如,必须在实施函数之前关闭开放问题)。我们基于正则表达式和机器学习提出了一种方法,该方法能够检测代码注释中引用的问题,并自动将检测到的实例分类为“ hold”(引用该问题表明需要在完成任务之前等待其解决方案),或称为“交叉参考”(例如,参考编号的代码),以解释代码,以解释该实施条件,以此为作品。我们的方法还挖掘了项目的问题跟踪器,以检查持有的SATD实例是否“多余”,并且可以删除(即,引用的问题已关闭,但SATD仍在代码中)。我们的评估证实,我们的方法确实可以确定相关的现有SATD实例。我们通过确定原始开发人员确认的开源项目中的多余的SATD实例来说明其有用性。

Modern software is developed under considerable time pressure, which implies that developers more often than not have to resort to compromises when it comes to code that is well written and code that just does the job. This has led over the past decades to the concept of "technical debt", a short-term hack that potentially generates long-term maintenance problems. Self-admitted technical debt (SATD) is a particular form of technical debt: developers consciously perform the hack but also document it in the code by adding comments as a reminder (or as an admission of guilt). We focus on a specific type of SATD, namely "On-hold" SATD, in which developers document in their comments the need to halt an implementation task due to conditions outside of their scope of work (e.g., an open issue must be closed before a function can be implemented). We present an approach, based on regular expressions and machine learning, which is able to detect issues referenced in code comments, and to automatically classify the detected instances as either "On-hold" (the issue is referenced to indicate the need to wait for its resolution before completing a task), or as "cross-reference", (the issue is referenced to document the code, for example to explain the rationale behind an implementation choice). Our approach also mines the issue tracker of the projects to check if the On-hold SATD instances are "superfluous" and can be removed (i.e., the referenced issue has been closed, but the SATD is still in the code). Our evaluation confirms that our approach can indeed identify relevant instances of On-hold SATD. We illustrate its usefulness by identifying superfluous On-hold SATD instances in open source projects as confirmed by the original developers.

扫码加入交流群

加入微信交流群

微信交流群二维码

扫码加入学术交流群,获取更多资源