본문 바로가기
프로그래밍/프로젝트

1. 컨벤션과 Git Flow

by 카프카뮈 2021. 1. 26.

개발 관련 내용을 포스팅하려고 계속 준비했는데,

기회가 생기지 않아 특별한 포스팅 없이 2020년을 보냈다.

 

다행히 2021년엔 새 토이 프로젝트를 시작하게 되어,

이번 기회에 진행사항이나 고민하는 내용들을 적어보려고 한다.

 

이번 프로젝트는 "BooksDiary" 프로젝트.

읽은 책을 기록하고, 이를 바탕으로 몇 권의 책을 언제 읽었는지 다시 볼 수 있는 간단한 리뷰 서비스다.

개발 동기는 간단하다. 내가 읽은 책 기록하기가 귀찮아...

앱스토어에 있는 북 다이어리 앱들은 기록하기 난삽하거나 커뮤니티가 주인 경우가 있어 불편했고

지금은 왓챠의 책 리뷰 기능을 쓰지만 이 역시 불편하다.

토이 프로젝트인만큼 상업성보다는 내가 만들고 싶은 데에 집중하려고 한다.

왓챠를 통해 독서목록 관리중. 날짜 기록 등이 귀찮고 연도별로 모아보기도 어렵다!

 

 

기술 스택은 Spring Boot 2와 VueJS를 기본으로 하고, 추가로 Spring Data JPA를 사용한다. 
이외에 추가되는 기술 스택은 그때그때 포스팅과 함께 소개할 예정이다.


프로젝트를 시작할 때 제일 재밌고 제일 진빠지는게 컨벤션 정하는 일이 아닌가 싶다.

이전에 팀 프로젝트를 할때에도 이 부분을 정하는게 쉽지 않았다.

 

이번 프로젝트에서는 이전에 사용했던 컨벤션이나 깃헙 세팅을 바탕으로 진행하고,

이후 불편함을 느끼거나 개선할 방법을 찾으면 조금씩 바꿔보려고 한다.


기본적인 코드 컨벤션

 - 자바코딩 컨벤션

 - 객체지향 생활체조

 - 코드의 들여쓰기 깊이는 되도록 2 이내로 한다.

 - 들여쓰기는 4 space로 한다.

 - 코드 포맷터를 사용한다. 

    - 백엔드는 SonarLint를 사용한다. 추후 Jacoco + SonarCube 도입을 시도해 볼 계획이다.

    - 프론트엔드는 ESLint와 Prettier를 사용한다. 

 - 테스트 코드를 알아보기 쉽게 작성한다.

    - 상수값을 코드 상단에 상수로 선언해두며, 상수의 이름은 한글로 한다.

    - DisplayName은 ~~~할때, ~~~한다 식으로 작성한다.

    - 예외처리에 대한 테스트일 경우, DisplayName의 맨 앞에 "예외 테스트: "를 붙여준다.

    - 테스트 메서드의 이름은 해당 메서드의 이름 + Test로 한다.

 

2020년에 우아한 테크코스에서 1년간 백엔드 교육을 받았는데,
그 과정에서 클린코드를 지키며 TDD로 프로젝트를 진행하는 법을 배웠다.

프로젝트 유지보수 측면에서 큰 도움을 받았기에, 이번 프로젝트 역시 객체지향 생활체조와 테스트 코드를 안고 갈 생각이다.

코드의 들여쓰기 같은 경우는 2 이내로 하려고 노력하다보면 기능이 메서드 단위로 적절히 분리되는 것을 보았기에,

혼자 하는 프로젝트더라도 이를 준수하려고 한다.

들여쓰기 4space는 의견이 좀 갈리려나...개인적으로는 탭으로 해뒀을때 다른 환경에서 코드가 이상하게 보일까 염려되어 지키고 있다.

 

그 외에 특이한 부분이라면 테스트 코드의 상수를 모두 상단에 선언하고 이름을 한글로 하는 부분이 될 것 같다.

실제 테스트 코드를 여러개 작성하다 보면 여러 상수값이 코드에 직접 들어가는 경우가 많다.

그런데 도메인 설계가 바뀌는 등으로 인해 이 값이 바뀌면, 코드 전체를 수정해야 해서 불편한 적이 많았다.

그렇기에 상단에 모두 선언해 주는 것이고, 한글로 하는 이유는 테스트 코드를 봤을때 직관적이라서!!

이런 느낌으로 작성!! 테스트 코드에 대해서는 다음에 포스팅하겠다.

 

이런 식으로 선언을 해주면 동작을 파악하기도 편하고, 추후 값이 바뀌어도 관리가 편하다는 이야기이다.


Git 브랜치 / 커밋 관리

 - 깃 플로우를 통해 브랜치를 관리한다. (링크 : 배민 기술 블로그)

 - 커밋은 개행을 두 번 해준 뒤 자세한 설명을 적는다.

 - 당연한 이야기지만, 왠만하면 master에 바로 커밋하지 않는다.

 

이전에는 git을 잘 사용하지 않아 말도 안되는 실수를 많이 했다.

master branch에 잘못된 내용을 바로 커밋해서 복구한다고 고생한다던가...

branch도 거의 나누지 않고 진행했는데, 협업을 하게 되었을 때 이게 좋지 않은 습관이란걸 알았다.

 

다행히 팀원 분께서 Git Flow라는 기법을 소개해 주셨고, 마침 사용중이던 소스트리에서 편하게 사용할 수 있어

이를 프로젝트에 적용해 보았다. 당시엔 만족했고, 이번 프로젝트에서도 믿고 가기로!!

다만 저번 프로젝트 때에는 Release 카테고리를 잘 쓰지 않았는데

막상 Github의 Version 태그를 달아보니 Release를 안쓰면 불편하더라. 이번에는 있는 기능 모두 써보기로.

 

만약 소스트리를 사용한다면, Git Flow 설정은 더욱 간편하다.

주변을 보면 터미널이나 인텔리제이를 통해 Git을 쓰는 경우가 많았다.

터미널이 명령어만 잘 안다면 더 좋다고 생각하지만...

그래도 Git 명령어 때문에 시간을 계속 쓰기보다, GUI 툴을 통해 간편하게 설정하려고 한다.

(Git 학습이 불필요하다는 이야기는 당연히 아니다!)

상단의 저장소-Git Flow 메뉴에서 Git Flow 설정을 간편하게 할 수 있다.
같은 메뉴에서 새 기능을 누르면, 이렇게 브랜치를 만들어준다!

 

커밋 컨벤션은 우아한테크코스에서 배운 방식으로 사용하고 있다.

앞에 간략한 커밋 분류를 적어주고, 한줄 요약을 적어준 뒤, 개행하여 설명을 적는다.

여기에 자세한 설명이 있어, 링크를 공유한다.


이제 간단히 컨벤션을 정했다.

Github 저장소를 열고 프로젝트를 만드는 과정도 공유하려고 했으나, 

나도 모르게 한호흡에 끝내버렸다. 혹시나 이 부분에서 막히신다면 이동욱님의 저서를 읽어보시길 추천한다.

(사실 스프링 부트로 개발하는 초보 백엔드 개발자라면, 놓칠 부분이 없는 책이라고 생각한다)

 

다음 포스팅에서는 JPA와 Lombok에 대해 간단히 써보려고 한다.

반응형

댓글