현재 내가 다니고 있는 회사에는 서버, 웹 클라이언트, 안드로이드등 여러 개발 직군들 별로 서브 챕터라는 이름으로 논리적인 팀이 구성되어있다. 현재 서버 서브 챕터 조직은 6명의 서버 개발자분들이 소속되어있으며, 우연치 않게 내가 서버 서브 챕터의 리더를 맡게 되었다.
나는 서버 서브 챕터원들이 협업하는데 있어서 문제가 없도록 프로젝트 설계 가이드라인을 작성하고, 사용할 개발 스택 선정하고 이를 각 챕터원들에게 공유했다.
최근 서버 개발자분들이 모두 투입되는 통합 프로젝트를 진행하고 있는데, 각 담당 서버별로 코드 리뷰와 API 설계를 검토하면서 컨벤션이 필요하다는 점을 느끼게 되었다. 프로젝트 설계에 대한 가이드라인은 제공하였기 때문에 구조를 파악하는데 힘이 들진 않았지만, 코드의 네이밍 규칙이 정해져있지 않아 작성된 코드의 기능을 오해하거나, 의미를 파악하는데 많은 시간이 드는 경우가 있었기 때문이다.
코드를 작성하는데 있어서 컨벤션이 잡혀있지 않다면 이는 소프트웨어 품질에도 영향이 갈 것 이라는 생각이 들었고, R&D 조직에서도 이러한 점을 잘 인지하고 있어 소나큐브(SonarQube)를 도입할 예정이라는 결정을 전달 받았다.
CI/CD 단계에서 소나큐브를 연동하여 정적분석을 통해 소프트웨어 품질을 관리하기 전에, 각 개발자분들이 개발 단계에서 자기가 작성한 코드에 대한 문제점을 인지하고 고칠 수 있는 환경이 제공되었으면 한다는 생각이 들었다.
사실 그러한 환경을 제공하는 여러 도구가 있고, 그 중 가장 많이 사용되는 도구가 lint다. NodeJS의 경우 ESLint, Typescript 환경일 경우에는 tslint, Python환경의 경우 Pylint 등 언어별로 여러 lint 도구가 있다. Java 환경에서 사용이 가능하고 SonarQube와
연동이 가능한 (각 규칙들을 통합적으로 관리하기 위해) 도구를 찾던 중 sonarlint라는 도구를 찾게 되었고 이를 사용하는 방법을 설명해 보겠다.
sonarLint는 오픈소스다. Intellij IDEA Ultimate(유로버전)의 경우 플로그인 기능을 사용할 수 있고, 마켓플레이스에 SonarLInt가 올라와 있어 간단하게 설치하는것으로 Intellij와 연동이 끝난다.
먼저 인텔리제이를 켜고, shift (window 기준)을 빠르게 두번 연타하여 검색창을 켜고, plugin 을 검색하면 action 목록에 플러그인을 설치할 수 있는 화면을 보여주는 항목이 나타난다.
plugins 항목을 클릭하거나, 엔터를 통해 누르면, 다음과 같이 마켓플레이스에서 플러그인을 검색하거나, 설치된 플러그인을 관리할 수 있는 화면이 나타나는데 거기서 SonarLint 라고 검색을 하면, 검색 결과가 뜬다.
Install 버튼을 클릭하여, 설치를 하면 다음과 같이 설치 버튼이 RESTART IDE 라는 문구로 바뀐다. 설치된 플러그인을 적용하기 위해 IDE를 재시작하라는 의미이다. 재시작을 하자.
IDE를 재시작하고, IDE 하단을 보면 아래 사진과 같이 SonarLint라는 탭이 새로 생긴것을 확인할 수 있다.
SonarLint 탭을 눌러 창을 띄우고, 소스파일 아무거나 눌러보면 다음과 같이 화면이 뜬다.
위와 같이 SonarLint 탭에서는 현재 소스 파일에서 문제가 있는 코드에 대한 문제점을 표시하며, 문제의 위험도를 표출해준다. 그와 동시에 해당 코드가 어떤 룰(규칙)에 위배되었는지 관련된 내용도 오른쪽 탭에 자세하게 표시해준다.
내용을 해석하자면, 람다 표현식 중에, 인자가 하나인경우 () 괄호를 지워줘야한다는 규칙에 위배되었다는 뜻이다.
@Bean
@StepScope
public ItemProcessor<Message, Message> deleteOldMessageProcessor() {
return (message) -> message; // SonarLint에서 문제로 삼은 코드
}
이를 다음과 같이 규칙에 맞게 변경해본다.
@Bean
@StepScope
public ItemProcessor<Message, Message> deleteOldMessageProcessor() {
return message -> message;
}
코드를 수정하고 IDE 하단에 있는 SonarLint 탭을 보면 다음과 같이 경고가 사라진것을 확인할 수 있다.
만약 회사에서 또는 부서에서 또는 팀에서 정하고 따르는 컨벤션 혹은 룰이 있다면 공통적으로 SonarQube 또는 SonarLint에 적용해보자. 구성원 모두가 동일 또는 비슷한 구조의 코드를 작성하게 되며 인수인계, 코드 리뷰, 결함 분석등에서 많은 시간을 아낄 수 있고 소프트웨어의 품질 또한 이전과 비교하여 더 향상된 수준을 보장할 수 있을 것이다.
만약, SonarLint를 적용하기 힘든 환경이라면 CheckStyle 도 확인해보면 좋다.
PS: 사내 서버 직군에 공통적으로 적용해보고 싶고, 기준을 정하고 싶고, 업무 능률을 향상 시킬 수 있을 것 같은 부분이 보이지만 막상 업무를 해결하느라 바쁘다😂 그리고 퇴근 후에는 여자친구랑 노느라 바쁘다! 여자친구가 최고다!😘
'Programming > Java' 카테고리의 다른 글
[Java] AES 256 암복호화 유틸클래스 (0) | 2020.07.15 |
---|---|
[Java] 사용하는 라이브러리의 라이선스 내용 출력하기 (0) | 2020.07.04 |
[Java8] Stream API 공부 정리 (1) (2) | 2020.01.16 |
[JPA , Hibernate] Add Prefixed Table Name (0) | 2019.12.13 |
[Gradle] Gradle 에서 Launch4j Plugin 사용해서 exe 실행파일 만들기 (0) | 2019.11.14 |