정적 분석(Static Analysis)
정적 분석이란 소스코드의 실제 실행 없이 소프트웨어를 분석하여 문제를 찾는 것을 말한다.
개발을 하는 우리 모두 소위 말하는 냄새 나는 코드(Code Smell)를 작성해본 경험이 있을 것이다. 우리는 다양한 이유로 냄새나는 코드를 만들어왔다. 아직 경험이 부족해서 코드의 냄새를 맡지 못해서일 수도 있고, 일정 등의 외부 요인으로 냄새를 맡았지만 참고 넘겼을 수도 있다. 문제는 소프트웨어를 지속적으로 발전시켜나가야하는 우리들, 혹은 회사의 입장에서 이는 고스란히 부채로 남아 자신이나 팀원들에게 돌아오게 된다는 것이다.
그렇다면 어떤 코드가 냄새나는 코드일까? 마틴 파울러 형님의 말씀에 따르면 코드 냄새는 문제 자체가 아니라 코드 어딘가에 문제가 있을 수 있다는 지표이다.
- 중복코드
- God Class
- 단일 책임 원칙을 지키지 못한 메소드
- 기능의 변경이 생겼을 때 많은 부분을 수정해야하는 코드
- 모호한 변수명
- ...
등등 냄새를 풍기는 코드는 Clean하지 못한 코드라고 볼 수 있을 것 같다.
냄새나는 코드를 다시 Clean하게 만들기 위해서 우리는 코드리뷰를 하기도 한다. 하지만 냄새나는 코드의 유형은 위와 같이 어느 정도 정형화가 되어있고 우리의 시간은 언제나 부족하기 때문에 정적 분석 도구의 도움을 받는다면, 우리는 다음과 같은 이점들을 얻을 수 있을 것 같다.
- 도메인이나 비즈니스적인 부분에 더 집중할 수 있다. 코드의 형태와 별개로 비즈니스적인 접근이 필요한 부분은 분명히 존재한다. 기본적인 컨벤션이 맞춰져있다면 코드 리뷰 때 이러한 부분을 검증하는 데 있어 더 집중할 수 있을 것이다.
- 냄새 나지 않는 코드를 넘어 향기가 나는 코드를 만들게끔 하는데 시간과 노력을 더 쏟을 수 있다.
- 프로젝트의 품질 하한선을 끌어올릴 수 있다. 나는 품질 유지에 구성원 간의 원칙이 잘 Align 되어있는지가 큰 영향을 끼친다고 생각한다. 정적 분석 도구는 팀원들이 공유하는 원칙을 세워줌으로서 더 적은 시간으로 프로젝트 품질을 일정 수준 이상 유지하는 데 도움을 줄 것이다.
- 새로운 팀원이 들어왔을 때 컨벤션을 맞추는 데 들어가는 비용을 최소화할 수 있다.
- 프로젝트 중간에 도입했을 경우, 어느 부분에 기술 부채가 쌓여있는지 파악하고 개선할 수 있다. 프로젝트가 어느 정도 진행된 상태라면, 미래의 누군가에게 미뤄왔던 냄새나는 코드의 리팩토링을 더 늦기 전에라도 진행할 수 있을 것이다. 나중은 오지 않는다는 르블랑의 법칙을 정적 분석 도구의 도움을 받아 깨보도록 하자.
eslint나 preittier같은 lint 툴부터 시작해서 Sonarqube같은 조금 더 전문적인 소프트웨어까지 다양한 정적 분석 도구가 있다. 상황에 맞는 적정 도구를 선택한다면 우리가 쌓아가는 기술 부채들을 조금은 더 줄일 수 있지 않을까?
Reference
https://martinfowler.com/bliki/CodeSmell.html http://wiki.c2.com/?CodeSmell https://ko.wikipedia.org/w/index.php?title=코드_스멜&action=edit§ion=1