코드 리팩토링 00.코딩 컨벤션

Coding Convention

코딩 컨벤션(Coding Convention)은 가독성 있는 코드를 작성하고 협업을 원활하게 진행하기 위한 공통의 코드 작성 가이드라인이다.

 한국인들은 한국어로 소통하고, 일본인은 일본어로 소통하고, 미국인은 영어로 소통하듯 개발자들끼리 소통을 하기 위해서는 코드로 소통해야 한다. 하지만 우리 팀은 서로 다른 언어를 갖고 있다. iOS 개발자는 Swift, AOS개발자는 Kotlin, Front개발자는 React까지 서로 다른 언어를 갖고 있다. 그러면 우리는서로 소통할 수 없을까? 여행지에서 세계 각국의 사람들이 모이면 자연스럽게 암묵적으로 하나의 언어를 사용해 소통하게 된다. 이처럼 자연스럽고 암묵적인룰이 팀에 정착할 수 있도록 도와주는 가이드라인이 코딩 컨벤션이라고 할 수 있다. 

 

📋 코드 스타일 가이드 정의

 앱 개발 파트에서 사용하는 언어는 Swift, Kotlin, TypeScript가 있다. 이 언어는 각각의 사용환경에 맞게 코드 스타일을 정의하며, 권장하고 있다. 그렇기 때문에 각 플랫폼별 언어 사용 환경에 맞게 코드 스타일을 정의해 주어야 한다. 큰 틀을 벗어나지 않는 선에서 팀에 맞는 코드 스타일을 따로 고민할 필요가 있다. 예를 들자면 대표적으로 A언어에서는 표기법으로 파스칼 케이스를 사용하고, B언어에서는 카멜 케이스를 권고한다면 각 플랫폼에 맞는 권고를 따를지, 팀 내 코드 스타일을 수립해서 플랫폼에 제약 없이 통일할지 등의 논의가 필요하다.

 

 각 언어별 스타일 가이드이다.

• Swift Style Guide 
• Kotlin Style Guide
• Airbnb React/JSX Style Guide

👨‍💻 코드 컨벤션 적용

 컨벤션을 정하고 (사실 이것만 해도 정말 쉬운일이 아니다.) 적용하기로 약속을 하면 끝일까? 이미 컨벤션을 만들기 위해 토의하며 익숙해졌을 수 있지만, 우리는 각각의 언어 스타일 가이드로 작성하는 습관에 익숙해져 있을 뿐 아니라 수십 페이지에 달하는 스타일 가이드를 정확히 외우고 지키기는 어렵다. 작성한 코드가 팀의 코드 컨벤션과 맞는지 매번 코드 리뷰를 통해 검토해야 하지만 쌓이는 업무와 대기 중인 회의를 생각하면 우리에겐 그럴 시간도 여력도 없다.

 

 이럴때 큰 도움이 되는 것이 작성한 코드들이 컨벤션에 맞는지 검사를 해줄 Lint를 적용해 코드에 구조적 문제가 없는지 확인을 하는 것이다. Lint를 사용하면 구조적 문제로 인해 앱의 안정성과 효율성에 영향을 미치거나 코드 관리에 지장을 줄 가능성이 있는 코드를 찾을 수 있을뿐더러 감지된 문제는 설명 메시지 및 심각도 수준과 함께 보고되기 때문에 개선이 시급한 순서대로 우선순위를 정해서 처리할 수 있다.

🍎 Swift : SwiftLint

 현재 SwiftLint에는 각각 수백개에 달하는 Default Rules와 Out-In Rules가 수정 보완되고 있다. SwiftLint의 공식 문서를 살펴보면 다양한 규칙들의 식별자와 설정 여부, 자동 수정 여부, 최소 Swift Compiler 등의 다양한 사항이 명시되어 있다. 가장 위의 Block Based KVO만 해도 다음과 같이 세세하게 설명되어 있고 예시로 친절하게 설명되어있다. 전체 Rule은 [SwiftLintFrameworkDocs]에서 확인할 수 있다. (Swift는 Camel Case가 기본인데 문서를 Snake Case로 작성한게 몹시도 킹받는 부분)

🍏 Kotlin : Ktlint, detekt, Android Lint

 - Ktlint는 정적 분석도구로, 작성한 코드의 스타일 검사와 형식에 맞지 않는 부분을 수정하는 기능을 제공한다. Kotlin 공식 Style Guide를 기준으로 기본적인 규칙부터 접근제어자의 순서, 불규칙한 Spacing까지 꼼꼼하게 검사해준다.

 

 - Detekt는 단순 문법검사를 넘어 정적 분석을 통해 지양해야 하는 패턴들에 대한 감지와 특정 패턴들의 가중치를 파악하는 등 코드 본연의 문제를 파악할 수 있게 도와준다. Ktlint가 코드 스타일을 검사한다면 Detekt는 코드 품질을 검사한다.

 

 - Android Lint는 Ktlint와 Detekt가 언어적인 부분을 검사한다면, 프로젝트의 구조를 검사한다. 예를 들어 리소스 파일에 사용되지 않는 네임스페이스가 있다면 공간을 차지하며 불필요한 처리가 발생하게 된다. 지원 중단된 요소나 지원되지 않는 버전의 API 호출은 다른 구조적 문제가 발생하는 경우 코드가 올바르게 실행되지 않을 수 있는데, 이것에 대한 문제를 방지하고 해결해줄 수 있다.

🍍 ReactNative(React, TypeScript): ESLint, Prettier

 - ESLint는 정적 분석 도구로 코드를 분석해 문법적인 오류나 안티 패턴을 찾아주고 일관된 스타일로 작성하도록 도와준다.

 

 - Pretter는 ESLint가 코드의 품질을 검사한다면, Pretter는 정해진 스타일로 코드를 정리해준다. 하지만 ESLint와 Pretter를 동시에 적용하는 경우, 규칙이 겹치는 부분이 있기 때문에 추가적인 설정이 필요하다.

 🫒 그래서 꼭 해야 하는가?

 사실 그럴싸한 좋은 말들로 포장을 하긴 했지만, 코딩 컨벤션은 꼭 필요한 프로세스가 아니다. 오히려 개발자들은 코딩 컨벤션을 진행하면 컨벤션을 정리하고, 적용하고, 검토하는 과정에서 상당한 시간의 업무시간을 빼앗기게 될 것이다. 컨벤션을 정하며 서로 멱살을 잡거나 결정을 서로에게 미루며 시간을 보낼 수도 있다.

 

 하지만 여러명의 개발자가 하나의 프로젝트에 투입되어 코드를 서로 이해하고 활용해야 하는 상황에 각자의 스타일로 코드를 작성한다면 같은 프로젝트에서도 서로의 코드를 이해하는데 상당 시간이 소요될 것이고, 시간이 지난다면 본인마저도 이해할 수 없는 코드가 나오게 되어 기능을 오해하는 경우가 생기게 될 것이다. 그렇게 프로젝트가 진행되고 시간이 지나면 더 이상 그 누구도 손댈 수 없는 프로젝트가 되어 있을 것이다.

 

 좋은 코드란 쉽게 읽히고 누구나 이해할 수 있는 코드란 건 개발자라면 누구나 공감할 것이다. 코딩 컨벤션의 도입은 누구 한 명이 독단적으로 결정해서 진행할 수도 없고, 그렇게 진행해서도 안된다. 팀원들의 충분한 공감과 동의가 있어서 함께 진행하고 함께 결정했을 때만이 성공적으로 도입이 가능할 것이다. 그렇게 좋은 개발 문화가 하나씩 자리 잡게 되면 언젠가는 나도 좋은 개발자가 되어있지 않을까?

 

이 코드가 무슨 코드인지는 오직 신과 나만이 안다. 그리고 이제는 오직 신만이 아신다.

---

참고자료 : 구글 컨벤션 가이드

참고자료 : naver.github에서 제공하는 코딩 컨벤션