SQ Official Doc Link: https://docs.sonarqube.org/display/SONAR/Fixing+the+Water+Leak

누수(water leak)란 무엇인가?

머릿속에 한가지 상상을 해보겠습니다.

어느날 집에 들어왔더니 부엌 한 가운데 물 웅덩이가 있습니다. 그 웅덩이를 보고 있는 동안, 웅덩이는 계속 커집니다.

대걸레를 가지고 닦고 말겠습니까? 아니면, 물이 새는 원인을 찾아서 수리하겠습니까? 선택은 분명합니다. 물이 새는 원인을 찾아서 고치는 것입니다!

그런데 코드 품질에 관해서는 왜 같은 일을 하지 않을까요? SonarQube를 사용해 애플리케이션을 분석하고, 엄청난 양의 기술 부채가 있다는 것을 깨닫고, 무릎을 망치로 때린 듯한 반응을 보이는 것처럼 기술 부채의 완화를 시작하는 것이 일반적입니다--혹은 기술 부채를 완화할 계획을 세웁니다. 하지만 이는 물이 새는 원인을 찾지 않은 채, 대걸레로 바닥을 훔치는 것과 대처에 지나지 않습니다.

전통적인 접근 방식에서는 일반적으로, 릴리즈 직전에 일정 기간동안 코드 품질 오딧(audio)을 수행하고, 개발자들이 릴리즈 이전에 그 결함을 고치도록 강제합니다. 이 방법은 매니지먼트의 강력한 지원이 있는 경우 단기적인 효과를 얻을 수 있으나, 중장기적으로 볼때는 실패할 수 밖에 없습니다:

코드 리뷰가 프로세스 상에서 너무 늦은 시기에 이루어지면, 그 어떤 이해관계자도 문제를 수정하는데 의지를 보이지 않습니다. 왜냐하면 모든 사람들이 새로운 버전을 릴리즈하기 원하기 때문입니다.
개발자들은 프로젝트의 컨텍스트를 알지 못하는 외부팀이 만든 권장사항을 달가워하지 않습니다. 아무튼, 리뷰를 수행했던 코드는 이미 쓸모없어졌기 때문입니다.
이러한 방법으로는 코드 품질에 대한 명확한 오너십을 찾을 수 없습니다. 누가 품질을 소유합니까? 그 누구도 소유하지 않습니다!
전체 애플리케이션이 프로덕션 단계에 가기 전, 리뷰를 통해 얻은 결과는 모든 애플리케이션에 동일하게 적용할 수 없습니다. 프로젝트 별로 적정한 협의가 이루어저야 하는데, 이는 프로세스의 신뢰도를 무너뜨릴 수 있습니다.

대신 집에서 하는 것과 마찬가지로 코드 품질을 관리하는 간단한 논리를 적용해 보는 것은 어떨까요? 누수를 수리한다는 것은 "새로운" 코드에 집중하는 것을 의미합니다. 즉, 지난번 릴리즈 이후 추가되거나 변경된 코드에 집중한다는 것입니다. 이는 훨씬 더 쉬운 접근 방식입니다:

품질 게이트를 매일 실행하고, 원하는 기준을 매일 달성한다면 릴리즈 시점에 당황하는 일이 발생하지 않습니다.
개발자들에게 과거에 유입된 결함을 수정하도록 강제하는 것은 매우 어렵습니다. 대신, 코드가 여전히 깨끗할 떄 문제를 수정하는 것은 일반적으로 쉽습니다.
코드 품질에 대한 소유권이 명확합니다.
진행/중단에 대한 기준을 애플리케이션에 지속적으로 적용할 수 있으며, 이 기준은 팀 내에서 공유됩니다. 애플리케이션이 무엇인지에 관계없이, 신규 코드는 신규 코드일 뿐입니다.
개발 프로세스의 일부로 적용할 수 있으므로, 개선 비용이 매우 작습니다.

부수적으로, 가장 많이 변경된 코드의 유지보수성이 가장 높으며, 가장 적게 변경된 코드의 유지보수성이 가장 낮아집니다. 소프트웨어 특성 및 지속적인 변경의 결과, 기술 부채는 자연스럽게 낮아집니다. 기술부채가 없다면 값을 필요도 없습니다.

어떻게 하는가?

SonarQube는 누수 해결을 지원하는 두 가지 도구를 제공합니다:

Leak Period 메트릭: 현재 코드와 특정 시점의 코드(일반적으로 previous_version) 지표들을 비교할 수 있습니다.
품질 게이트: 코드 분석 지표값에 대한 불리억(boolean) 임계값을 설정할 수 있습니다. 차분 지표(differential metrics)와 함께 품질 게이트를 사용하여 개발 흐름에 따라 코드 품질이 나아지고 있음을 확인할 수 있습니다.

Browser not supported