[논문 리뷰] Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

Laerte Xavier, Fábio Ferreira외 2명|arXiv (Cornell University)|2020. 03. 20.

Software Engineering Research인용 수 7

한 줄 요약

이 논문은 개발자가 소스 코드 주석이 아닌 이슈 트래커 시스템에 '기술적 부채'와 같은 레이블을 사용하여 기술적 부채를 명시적으로 문서화하는 이슈 기반 자기인정 기술적 부채(SATD-I)를 소개한다. Microsoft Visual Studio와 GitLab을 포함한 다섯 개의 오픈소스 프로젝트에서 286개의 SATD-I 사례를 분석한 결과, SATD-I 사례의 29%만이 소스 코드 주석에도 기록되어 있으며, 이는 유사한 코드 찌그러짐 수준임에도 불구하고 더 오래 걸려 닫히는 경향이 있다. 이 중 45%는 조기에 출시하기 위해 도입되었고, 60%는 설계 결함과 관련이 있었다. 연구 결과는 이슈 기반 부채 추적 및 관리 도구의 필요성을 제안한다.

ABSTRACT

Self-admitted technical debt (SATD) is a particular case of Technical Debt (TD) where developers explicitly acknowledge their sub-optimal implementation decisions. Previous studies mine SATD by searching for specific TD-related terms in source code comments. By contrast, in this paper we argue that developers can admit technical debt by other means, e.g., by creating issues in tracking systems and labelling them as referring to TD. We refer to this type of SATD as issue-based SATD or just SATD-I. We study a sample of 286 SATD-I instances collected from five open source projects, including Microsoft Visual Studio and GitLab Community Edition. We show that only 29% of the studied SATD-I instances can be tracked to source code comments. We also show that SATD-I issues take more time to be closed, compared to other issues, although they are not more complex in terms of code churn. Besides, in 45% of the studied issues TD was introduced to ship earlier, and in almost 60% it refers to Design flaws. Finally, we report that most developers pay SATD-I to reduce its costs or interests (66%). Our findings suggest that there is space for designing novel tools to support technical debt management, particularly tools that encourage developers to create and label issues containing TD concerns.

연구 동기 및 목표

• 자기인정 기술적 부채(SATD)가 소스 코드 주석 외부, 특히 이슈 트래커 시스템에 기록되는지 조사하기.
• 실제 소프트웨어 프로젝트에서 이슈 기반 SATD(SATD-I)의 특성, 원인 및 동기를 이해하기.
• 코드 주석에 기록된 SATD(SATD-C)와 이슈에 기록된 SATD(SATD-I) 간의 겹침을 탐색하기.
• 개발자가 왜 SATD-I를 도입하고 정리하는지, 그리고 이러한 부채가 프로젝트 유지보수에 어떤 영향을 미치는지 평가하기.

제안 방법

• 연구자는 '기술적 부채' 또는 '부채'와 같은 용어로 레이블이 지정된 이슈를 식별하여 Microsoft Visual Studio와 GitLab을 포함한 다섯 개의 오픈소스 프로젝트에서 286개의 SATD-I 사례를 수집했다.
• SATD-C(코드 기반 자기인정 기술적 부채)를 동일한 프로젝트에서 탐지하기 위해 최신 기술 도구인 SATDDetector를 사용하여 SATD-I와 비교했다.
• 연구진은 문헌에서 유래한 10개의 기술적 부채 유형 범주에 따라 SATD-I 사례를 수작업으로 분류하였으며, 설계 결함 및 코드 중복과 같은 유형에 집중했다.
• SATD-I 정리를 담당한 30명의 개발자에게 설문 조사를 실시하여 부채 도입 및 정리 동기를 이해했다.
• 코드 찌그러짐을 측정하여 SATD-I와 비-SATD 이슈 간의 복잡도 차이를 평가하였으며, 시간이 오래 걸리는 이유가 높은 복잡도 때문이 아니라는 점을 확인했다.
• qualitative 및 quantitative 분석을 통해 SATD-I와 SATD-C를 비교하고, 부채 도입 및 정리의 이유를 분석했다.

실험 결과

연구 질문

• RQ1 RQ1: 연구 대상 프로젝트에서 SATD-C(코드 기반)와 SATD-I(이슈 기반) 사례 간의 겹침은 얼마나 되는가?
• RQ2 RQ2: SATD-I 사례에서 가장 자주 정리되는 기술적 부채 유형은 무엇인가?
• RQ3 RQ3: 개발자는 왜 자신의 프로젝트에 SATD-I를 도입하는가?
• RQ4 RQ4: 개발자는 왜 SATD-I를 정리하기를 선택하며, 정리의 동기는 무엇인가?

주요 결과

• 연구 대상 286개의 SATD-I 사례 중 29%만이 소스 코드 주석에도 기록되어 있어, 자기인정 기술적 부채의 상당 부분이 코드베이스 외부에 존재함을 시사한다.
• 유사한 코드 찌그러짐 수준을 보임에도 불구하고 SATD-I 이슈는 다른 이슈보다 유의미하게 오래 걸려 닫히며, 이는 이슈가 더 복잡하기 때문이 아니라 깊이 있는 설계나 아키텍처적 고려가 반영되어 있음을 암시한다.
• 45%의 경우에서 기술적 부채는 조기에 소프트웨어를 배포하기 위해 도입되었으며, 이는 시간 압박이 부채 축적에 기여한다는 점을 강조한다.
• 거의 60%의 SATD-I 사례에서 부채는 설계 결함과 관련이 있었으며, 그 중 44%는 코드 중복이나 낮은 응집도와 같은 메서드 수준의 설계 문제를 포함했다.
• SATD-I를 정리하는 데 가장 흔한 동기는 이자 비용을 줄이기 위함(44%)과 깔끔하고 유지보수 용이한 코드를 유지하기 위함(33%)이었으며, 이는 개발자가 장기적 유지보수 부담을 인식하고 있음을 보여준다.
• 이 연구는 개발자가 활발히 이슈 트래커를 활용하여 기술적 부채를 문서화하고 관리하고 있음을 확인하였으며, 이는 이슈 기반 추적 방식이 기술적 부채 관리에 실현 가능하고 아직 활용되지 않은 채널임을 시사한다.