[1차 프로젝트 회고] 여러 컨벤션 이용 후기 - Java 코드, MyBatis 코드, DB, Git Commit 컨벤션

1차 프로젝트 때 협업을 위한 여러 컨벤션들을 적용해 보았다.

각각 어땠는지 회고해보고, 다음 프로젝트에서 개선할 점을 살펴보려고 한다.

 

1. Java 코드 컨벤션 - NAVER 코딩 컨벤션 이용

-  Java 코드 컨벤션 사용 이유

개발을 할 때 Java 코드 컨벤션을 이용하는 것이 좋다고 들었다.

그 이유는 일관된 코드 규칙이 있어야 전체적인 코드가 깔끔해지고, 코드에 대한 이해도도 향상되어 협업이 수월해지기 때문이다. 그 밖에 많은 장점이 있지만, 사실 그냥 생각해봐도 여러 사람이 같이 일할 때는 일관된 규칙이 있어야 작업하기 편할 것 같다는 생각이다.

 

우리 팀은 대표적인 Java 코드 컨벤션인 Naver 코딩 컨벤션을 사용하기로 하였다.

 

⬇️ NAVER 코딩 컨벤션 - 공식 GitHub을 이용하였다.

https://github.com/naver/hackday-conventions-java/blob/master/rule-config/naver-intellij-formatter.xml

 

- 문제점: 원하지 않는 컨벤션 규칙이 포함됨

NAVER 코딩 컨벤션에 우리 팀이 원하지 않는 컨벤션 규칙들이 있었다.

 

1. 탭이 자동으로 1번 쳐지는 현상

메서드 체이닝으로 값을 만들 때, 탭을 2번 치길 원했지만 자동으로 1번 밖에 쳐지지 않았다.

 

2. 원하지 않는 개행이 자동으로 발생

개행이 자동으로 되어 개행 기준을 정하기 어려웠다.

 

그래서 다음 프로젝트 때는, 네이버 컨벤션을 사용하지 않고 인텔리제이에서 제공하는 기본적인 Java 코드 컨벤션(default)을 사용하기로 하였다.

그리고 탭은 항상 2번 쳐서 사용하기로 통일하였다.

 

- 사용 후기

자바 코드 컨벤션을 사용해보니, 코드가 전체적으로 깔끔해지고, 코드 간 통일성이 생겼다는 점이 좋았다.

하지만 원하지 않는 규칙이 포함되는 등의 문제가 발생할 수 있기 때문에, 컨벤션을 무조건 적용하는 것만이 좋은 건 아니라는 것도 알게 되었다. 

이럴 때는 팀원들과 의견을 나누어 해당 컨벤션을 어떻게 활용할지, 아니면 다른 컨벤션을 사용할지 의논하여 결정하는 것이 중요하다고 생각했다.

 

 

 

2. MyBatis 코드 컨벤션

1차 프로젝트는 MyBatis를 이용하여 작업하였기 때문에, 이에 대한 코드 컨벤션을 정하였다.

 

- 컨벤션 규칙 내용

우리 팀이 정했던 규칙은 두 가지였다.

 

1. 생성자 결과 매핑을 @NoArgsConstructor 기본생성자로 통일한다.

2. 필드명은 camelCase로 통일한다.

 

- 문제점: @NoArgsConstructor 사용시 null 에러 발생

@NoArgsConstructor를 사용하여 Application을 실행시키고 url 요청을 보내면 null 에러가 발생했다.

 

팀원분의 분석에 따르면, 자바 변수 네이밍이 camelCase인데 MySQL 컬럼명은 snake_case라 매핑이 안된 것이 문제였다.

 

그래서 MyBatis 설정 파일에 camelCase 매핑을 적용하니 @NoArgsConstructor를 정상적으로 사용할 수 있었다.

이 과정에 대해서는 추후 자세히 포스팅할 예정이다.

 

- 사용 후기

확실히 생성자 방식을 통일하니까 코드 간 일관성이 생겨 읽기가 편했다.

 

그리고 camelCase 매핑 문제점에 대해서도 해결 방법을 알게 되었다.

따라서 다음 프로젝트에서는 바로 매핑 설정을 적용할 계획이다!

 

 

3. DB 컨벤션

우리 팀이 사용하는 DB에 관한 컨벤션 규칙을 정하였다.

 

- 컨벤션 규칙 내용

우리 팀이 정했던 규칙은 다음과 같다.

 

1. 스키마 명칭은 모두 snake_case를 사용한다.

2. 날짜 필드는 '_at' 접미사를 사용한다.

3. 수량은 '_count' 접미사를 사용한다.

4. 키에 해당하는 필드는 '_id' 접미사를 사용한다.

5. 금액은 '_amt' 접미사를 사용한다.

 

- 문제점: 과도한 축약어 사용에 따른 이해의 어려움

위 규칙을 따라 배송비 가격을 'shipping_amt'라고 설정했다.

그런데 amount의 약자인 amt의 뜻을 한눈에 '금액'이라고 인식하기 어려워, 해석에 혼동이 있을 것 같았다.

 

따라서 금액을 나타낼 때는 '_price' 접미사를 사용하기로 했다.

또한  '총' 금액의 경우에는 'total_' 접두사를 사용하기로 결정했다.

 

- 사용 후기

당연한 말이지만 코드 간 일관성이 생겨 읽기가 편했다.

그리고 컬럼명을 짧게하는 것만이 좋은 게 아니라, 팀원 모두가 이해하기 쉬운 이름으로 설정하는 게 중요하다는 것을 깨달았다.

 

 

4. Git Commit 컨벤션

깃의 커밋메세지에 대한 컨벤션 규칙을 정하였다.

 

- 컨벤션 규칙 내용

우리 팀이 정했던 규칙은 다음과 같다.

 

1. 커밋 타입은 [태그: 제목] 형식이며, ' : ' 뒤에만 space가 있다.

2. 태그는 영어로 쓰되, 첫 문자는 소문자로 한다.

3. 태그의 종류로는 feat, fix, docs, style, refactor, test, chore를 사용한다.

⬇️ 각 태그의 설명은 다음과 같다.

feat: 새로운 기능 추가

fix: 버그 수정

docs: 문서 수정

style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우

refactor: 코드 리팩토링

test: 테스트 코드, 리팩토링 테스트 코드 추가

chore: 빌드 업무 수정, 패키지 매니저 수정

 

- 문제점

사실 프로젝트가 끝나고 나서도, 커밋 메세지에 대한 별 문제를 느끼지 못했다. 

하지만 이렇게 아름답게, 문제점 없이 끝났을 거라 생각하지 않는다. 발견되지 못한 문제점이 분명 있었을 것이다.

더군다나 초보 개발자들이 진행한 프로젝트에서는 더더욱 그랬을 것이다...

 

다시금 생각해보니, 개발 당시 나는 내 커밋 메세지를 잘 썼는지 확인하기 바빴다.

그래서 팀원들의 커밋 메세지를 자세히 살펴보지 못했고, 이것이 문제점을 발견하지 못한 주된 원인이었다.

 

- 사용 후기

커밋 히스토리를 보면, 태그가 일관된 형식으로 나타나 있어서 마치 한 사람이 쓴 듯한 통일성을 느낄 수 있었다.

 

 

그러나 내 개발만 하기 급급해서, 다른 팀원들의 커밋 메세지를 자세히 확인하지 못했던 점을 반성하게 되었다.

다음 프로젝트에서는 내 개발 뿐만 아니라 다른 팀원들의 대략적인 개발 상황과 커밋 메시지들을 확인하여, 전반적인 코드 일관성을 유지함과 동시에 문제가 생길 수 있는 부분들을 인식하고 해결하려고 한다.

 

 

 

---

 

여러 컨벤션 사용 후기

처음에는 이렇게 많은 컨벤션들이 있는지도 몰랐는데, 여러 컨벤션들을 써보게 되면서 팀원간 소통과 코드 일관성에 큰 도움이 된다는 것을 깨달았다.

그리고 초반엔 그냥 컨벤션 쓰면 좋겠지 ~ 라고 마냥 생각했었는데, 원하지 않는 컨벤션 규칙이 포함되어 있다거나 너무 함축적인 이름을 쓰는 등 개발 도중에도 여러 문제가 발생할 수 있다는 사실을 알게 되었다.

따라서 중요한 건 컨벤션을 무조건 적용하는 것이 아닌, 문제가 발생했을 때 팀원들과 조율하여 더 나은 방향으로 프로젝트를 이끌어가는 것임을 깨닫게 되었다.