개요
코드 리뷰에서 코딩 스타일이나 규칙에 대한 지적은 반복적이고 기계적인 작업입니다. 이런 부분을 도구에 맡기면 코드 리뷰 시간을 줄이고, 리뷰어가 기능이나 로직 같은 본질적인 문제에 집중할 수 있습니다.
현재 코드 리뷰에서 코딩 스타일에 대한 지적이나 수정에 꽤 많은 시간이 소요되고 있습니다. 팀 내에서 합의된 코딩 규칙 중 도구로 자동 검사할 수 있는 것들은 도구에 맡기고, 코드 리뷰를 효율화하는 방법에 대해 알아보겠습니다.
코드 스타일 통일의 장점과 단점
코드 리뷰에서 코딩 스타일을 검사하지 않으면 리뷰 시간이 줄어들겠지만, 코드 스타일을 통일하는 것에는 여러 장점이 있습니다. 코드 스타일 통일의 장점과 단점을 살펴보겠습니다.
장점
코드의 가독성 향상
개발자는 새로운 코드를 작성하는 시간보다 기존 코드를 읽고 이해하는 데 훨씬 많은 시간을 사용합니다.
- Robert C. Martin (“Clean Code”): 개발자는 작업 시간 중 10%만 새로운 코드를 작성하는 데 사용하고, 90%는 기존 코드를 읽고 이해하는 데 사용한다.
- Camille Fournier (Software Engineering at Scale): 개발자가 코드를 읽는 시간이 코드를 작성하는 시간보다 3배 많다.
- IEEE와 ACM의 연구 결과: 코드의 가독성이 개선되면 개발 속도와 유지보수 효율성이 대폭 향상된다.
코드 스타일이 통일되면 기존 코드를 읽고 이해하는 시간이 줄어들기 때문에, 전체 개발 생산성이 향상됩니다.
유지보수 효율성 향상
- 코드를 추가하거나 수정할 때, 기존 코드를 이해하는 시간이 줄어듭니다.
- 디버깅이나 리팩토링 시 혼란을 줄여 효율적으로 작업할 수 있습니다.
협업 효과 향상
- 팀 멤버 간 코드 스타일이 통일되면 코드 리뷰 시간이 줄어들어 생산성이 향상됩니다.
- 코드 스타일에 관한 논의 시간을 줄이고, 기능이나 논리적 문제에 집중할 수 있습니다.
온보딩 시간 단축
- 새로운 멤버가 프로젝트의 코드베이스를 이해하고 기여하기까지의 시간이 줄어듭니다.
- 학습 비용이 감소합니다.
에러 감소
- 통일된 코드 스타일로 개발하면 작성 시 실수가 줄어들어 버그를 줄일 수 있습니다.
단점
초기 도입 비용
- 코드 스타일을 통일하기 위해 스타일 가이드를 작성하거나, 기존 코드를 리팩토링해야 합니다.
- Linter나 Formatter 도구를 설정하고 적용하는 데 시간이 걸리며, 이 기간 동안 생산성이 다소 저하될 수 있습니다.
규칙 합의에 시간 소요
- 어떤 스타일을 채택할지 결정하는 데 시간이 걸립니다.
- 모든 멤버가 만족하는 스타일을 찾는 것이 어렵고, 논의 시간이 길어질 수 있습니다.
창의성 및 유연성 제한
- 엄격한 스타일 가이드가 있으면 개인적인 코딩 스타일이 제한됩니다.
- 개발자가 자신만의 효율적인 방법을 시도하기 어려울 수 있습니다.
기존 코드와의 호환성 문제
- 이미 작성된 코드가 많은 경우, 새로운 스타일 가이드와 불일치하여 코드베이스에 두 가지 스타일이 공존할 수 있습니다.
- 기존 코드를 수정하는 데 추가 시간이 필요합니다.
Linter/Formatter 오버헤드
- Linter나 Formatter에서 에러가 여러 번 발생하여 수정에 시간이 걸릴 수 있습니다.
- Linter나 Formatter의 실행 시간이 추가됩니다.
코드 리뷰 자동화 도구
코드 리뷰에서 코딩 스타일이나 규칙을 Linter 등의 도구로 검사하면 코드 리뷰 자동화를 실현할 수 있습니다. 다음은 대표적인 도구들입니다.
- ESLint: JavaScript/TypeScript 코드의 문법 및 스타일 검사 도구
- 공식 문서: https://eslint.org/
- Stylelint: CSS/SCSS 등 스타일시트 코드의 문법 및 스타일 검사 도구
- Semgrep: 정규식 기반의 커스텀 규칙으로 코드 검사가 가능한 정적 분석 도구
참고로 Google도 스타일 가이드 문서와 도구를 운용하고 있습니다.
ESLint와 Stylelint 룰 추가
Linter로 검사할 수 있는 코딩 규칙이 있다면, Linter 룰을 추가하여 자동으로 검사할 수 있도록 하는 것이 좋습니다. Linter 룰을 추가하는 방법에 대해서는 아래 블로그 포스트를 참고하시기 바랍니다.
ESLint 룰 추가 예시:
Stylelint 룰 추가 예시:
Semgrep이란
Semgrep은 코드의 보안, 품질, 스타일을 자동으로 검사하고 개선하기 위한 정적 분석 도구입니다. 주로 소스 코드를 분석하여 보안 취약점, 버그, 코드 품질 문제를 찾아내는 데 사용됩니다.
Semgrep은 사용자 정의 규칙을 정규식으로 작성할 수 있어서, Linter로는 검사하기 어려운 부분도 검사할 수 있습니다.
예를 들어, 다음과 같이 주석에서 설명을 작성하지 않은 -가 있는 경우, Linter로는 검사할 수 없지만 Semgrep을 사용하면 검사할 수 있습니다.
잘못된 예시:
/**
* Add two numbers
* @param {number} a - number for addition
* @param {number} b -
* @returns {number}
*/Semgrep의 설치 및 사용 방법에 대해서는 아래 블로그 포스트를 참고하시기 바랍니다.
코딩 규칙 추가 프로세스
코드 리뷰 자동화를 효과적으로 운용하기 위해서는, 코딩 규칙을 추가하는 프로세스를 정립하는 것이 중요합니다. 다음은 코딩 규칙 추가 프로세스입니다.
1. 코딩 규칙 검토
코드 리뷰 시 코딩 스타일 통일이나 규칙으로 만들고 싶은 것이 있는 경우, 티켓을 만들어 팀 내에서 공유하고 규칙화할지 검토합니다.
2. 코딩 규칙에 추가
결정된 규칙을 코딩 규칙 문서에 기재합니다.
3. Linter 규칙 추가 확인
규칙화하기로 결정되면, 먼저 Linter(ESLint, Stylelint 등)로 검사할 수 있는지 확인합니다. 검사할 수 있는 경우, 해당 규칙을 추가합니다.
Linter를 Git 커밋 시 자동으로 실행하려면 Git Hooks 도구를 활용할 수 있습니다.
4. Semgrep 규칙 추가 확인
Linter 규칙으로 검사할 수 없는 코딩 규칙 중, 정규식으로 검사할 수 있는 것은 Semgrep 규칙을 추가합니다.
5. 코딩 규칙에 링크 추가
코딩 규칙 문서에 자동 검사 도구의 규칙 링크를 추가해 둡니다. 자동으로 검사할 수 있는 것은 문서에 기재하지 않아도 될 수 있지만, Google의 스타일 가이드처럼 문서로 남기는 것도 좋은 방법입니다.
Semgrep 활용 예시
다음은 Semgrep을 활용하여 주석에서 설명이 빠진 파라미터를 검사하는 규칙 예시입니다.
rules:
- id: missing-param-description
severity: ERROR
message: 【코멘트 에러】 올바른 코멘트를 추가하거나, 코멘트의 `-` 문자를 삭제해 주세요.
languages:
- javascript
- typescript
patterns:
- pattern-regex: \*\s*@.*-\s*(\n|\r\n|$)이 규칙은 다음과 같은 경우를 검사합니다.
잘못된 예시:
주석에서 - 뒤에 설명을 작성하지 않은 경우 에러가 발생합니다.
/**
* Add two numbers
* @param {number} a - number for addition
* @param {number} b -
* @returns {number}
*/올바른 예시:
모든 주석이 올바르게 작성되어 있는 경우 에러가 발생하지 않습니다.
/**
* Add two numbers
* @param {number} a - number for addition
* @param {number} b - number for addition
* @returns {number}
*/완료
이번 블로그 포스트에서는 코드 리뷰에서 기계적으로 검사할 수 있는 코딩 스타일과 규칙을 도구로 자동화하여 코드 리뷰 시간을 줄이는 방법에 대해 알아보았습니다.
코드 스타일 통일에는 초기 도입 비용이나 규칙 합의에 시간이 걸리는 단점이 있지만, 장기적으로는 코드의 가독성 향상, 유지보수 효율성 향상, 협업 효과 향상 등 많은 장점이 있습니다.
ESLint, Stylelint 같은 Linter와 Semgrep을 활용하면, 코드 리뷰에서 반복적으로 지적되는 코딩 스타일 문제를 자동으로 검사할 수 있습니다. 코딩 규칙 추가 프로세스를 정립하여, Linter로 검사할 수 있는 것은 Linter에, Linter로 검사할 수 없는 것은 Semgrep에 맡기는 것이 효과적입니다.
코드 리뷰에서 반복적인 스타일 지적에 시간을 쏟고 있다면, 도구를 활용한 자동화를 검토해 보시기 바랍니다.
ESLint 규칙을 추가한 구체적인 예시는 아래 블로그 포스트를 참고하시기 바랍니다.
제 블로그가 도움이 되셨나요? 하단의 댓글을 달아주시면 저에게 큰 힘이 됩니다!
앱 홍보
Deku가 개발한 앱을 한번 사용해보세요.Deku가 개발한 앱은 Flutter로 개발되었습니다.관심있으신 분들은 앱을 다운로드하여 사용해 주시면 정말 감사하겠습니다.
