대부분의 코드 품질 도구들은 개별적인 문제들을 찾아내는 데 매우 능숙합니다.

이 도구들은 다음과 같은 것들을 알려줍니다:

• 데드 코드 (Dead code)
• 사용되지 않는 의존성 (Unused dependencies)
• 복잡한 함수 (Complex functions)
• 거대한 파일 (Large files)
• 스타일 위반 (Style violations)

이것들은 모두 유용하며, 저 또한 이러한 도구들을 많이 사용합니다.

하지만 더 큰 코드베이스 (codebases)에서 작업하면서, 무언가 빠져 있다는 것을 깨달았습니다.

이 도구들은 무엇이 잘못되었는지(what)는 알려줍니다.

하지만 코드베이스가 왜 점점 유지보수하기 어려워지는지(why)를 설명해 주는 도구는 거의 없습니다.

문제점

프로젝트를 열었을 때 다음과 같은 상황을 마주한다고 상상해 보세요:

분석기는 다음과 같이 알려줍니다:

• 180개의 데드 코드 위치
• 47개의 과도하게 큰 함수
• 12개의 의존성 핫스팟 (dependency hotspots)
• 4개의 순환 의존성 (circular dependencies)

이것은 유용합니다.

하지만 개발자로서 저의 다음 질문은 항상 이렇습니다:

왜 이러한 문제들이 나타나는가?

개별 경고 그 너머를 바라보기

기술 부채 (Technical debt)는 단순히 함수가 길어지는 것만을 의미하지 않습니다.

때로는 진짜 문제가 구조적인 데에 있습니다.

예를 들어:

• 하나의 모듈이 애플리케이션 전체의 의존성 허브 (dependency hub)가 됩니다.
• 독립적이어야 할 기능들이 서서히 강하게 결합 (tightly coupled)됩니다.
• 모든 새로운 기능이 그곳에 추가되면서 단일 파일이 계속 커집니다.
• 원래 분리되어 있던 모듈들 사이에 순환 의존성 (Circular dependencies)이 나타납니다.

이러한 패턴들은 파일을 개별적으로 읽어서는 알아차리기 어렵습니다.

내가 AST 분석을 선택한 이유

정규 표현식 (regular expressions)으로 소스 코드를 검색하는 대신, 프로젝트를 추상 구문 트리 (Abstract Syntax Tree, AST)로 파싱 (parse)합니다.

이를 통해 분석기는 다음과 같은 것들을 이해할 수 있습니다:

• 함수 (Functions)
• 모듈 (Modules)
• 임포트 (Imports)
• 호출 (Calls)
• 타입 정의 (Type definitions)
• 파일 간의 관계 (Relationships between files)

파일을 단순한 텍스트로 취급하는 대신.

분석기가 찾는 것

현재 구현된 버전은 다음과 같은 패턴을 감지합니다:

• 데드 코드 (Dead code)
• 비대해진 함수 (Oversized functions)
• 의존성 핫스팟 (Dependency hotspots)
• 순환 의존성 (Circular dependencies)
• 복잡도 핫스팟 (Complexity hotspots)
• 프로젝트 전반의 구조적 관계 (Structural relationships across the project)

고립된 경고를 보고하는 대신, 전체적인 아키텍처의 그림을 그려내고자 합니다.

기존 도구들도 여전히 훌륭합니다

이것이 Clippy, cargo-udeps 또는 SonarQube와 같은 도구들을 대체하려는 의도는 아닙니다.

해당 도구들은 서로 다른 문제들을 매우 잘 해결합니다.

저의 목표는 다릅니다.

저는 다음과 같은 질문에 답하고 싶습니다:

• 왜 이 모듈은 계속해서 커지기만 하는가?
• 왜 모든 기능이 동일한 파일들을 건드리는가?
• 아키텍처의 어느 부분이 병목 현상 (Bottleneck)이 되고 있는가?
• 기술 부채 (Technical debt)가 명확해지기 전에 어디에 쌓이고 있는가?

구축하기

이 분석기는 Rust로 작성되었으며, 현재 PunamIDE의 일부입니다.

가장 흥미로운 도전 과제는 Rust 구문을 파싱 (Parsing)하는 것이 아니었습니다.

단순히 더 많은 경고를 생성하는 것이 아니라, 어떤 구조적 지표 (Structural metrics)가 실제로 기술 부채를 나타내는지 결정하는 것이었습니다.

유용한 통찰력과 정보 과부하 사이에서 적절한 균형을 찾는 것은 또 다른 린터 (Linter)를 만드는 것보다 훨씬 어렵습니다.

향후 계획

저는 추가적인 아키텍처 지표를 실험하고 결과가 시각화되는 방식을 개선하는 작업을 계속하고 있습니다.

또한 다른 개발자분들의 의견도 듣고 싶습니다.

기술 부채를 생각할 때, 여러분의 도구가 자동으로 감지해주기를 바라는 패턴은 무엇인가요?