이번에는 레포를 생성하고 팀 문화를 설정하고 일부 작업을 진행했다.
지난 2주간 생각보다 많은 내용을 진행했다.
우선 레포지토리를 생성했다.
지난 주차에 수행했던 몹 프로그래밍 결과물을 옮겨와서 project init을 했다.
https://github.com/BCSDLab/KOIN_API_V2
레포를 생성하자마자 코드를 작성하지는 않았다.
디스코드로 회의를 진행하며 팀 문화를 정하는 시간을 가졌다.
원래라면 동아리 관례 상 Google Drive를 사용하는 것이 일반적이겠지만 이번에는 특별하게 Github Wiki를 사용하고싶어 팀원들에게 제안하고 이를 적용했다.
https://github.com/BCSDLab/KOIN_API_V2/wiki
우선 코드 컨벤션에 대한 내용을 작성했다.
이전에 코드리뷰를 할 때 Cmd + Opt + L
로 라인 포맷팅을 수행하며 생기는 file changes가 신경쓰인적이 있었다.
이는 인텔리제이 설정이 각기 달라 생기는 불필요한 코드 변화로 코드 포맷을 xml 파일로 적용시켜 공통화시킬 수 있다.
작업이 늘어지는 것을 방지하고 PR을 보다 효율적으로 하기 위한 그라운드 룰을 2가지 정했다.
코드 리뷰 in 뱅크샐러드 개발 문화와 피움 팀의 Wiki를 참고했다.
3일 이내로 PR 리뷰를 해줘야하는 룰을 적용했지만 이에 대한 리마인드가 안되고있어 사람이 일일히 신경써야한다는 부분이 아무래도 조금 걸리는 부분이다.
추후 인원이 늘어남에따라 해당 그라운드 룰을 기술적으로 풀어나갈 방법도 고민해봐야겠다.
리뷰의 효율을 높이기 위해서 RCA 룰도 적용했다.
코드리뷰 과정에서 무수히 많은 코멘트들이 얼마만큼의 중요도를 갖는지 알기 어렵다.
RCA룰은 이러한 중요도를 R, C, A라는 알파벳 하나로 함축적으로 표현함으로써 각각의 리뷰 코멘트에 집중하는 정도를 구분할 수 있는 방식이다.
알파벳 각각의 의미는 다음과 같다.
R (Request Change): 조금 격하게 표현하자면 Production에 올라가면 안되는 코드, 혹은 반드시 반영해야하는 코멘트에 사용된다. 보통 컨벤션 혹은 예외상황에 사용되곤한다.
C (Comment): 격하진 않지만 그래도 웬만하면 반영하는것이 긍정적인 효과를 가져오는 경우 사용하곤 한다.
A (Approve): 칭찬 혹은 개인의 견해를 이야기하는 코멘트에 사용된다.
RCA룰은 작업하면서 까먹어서 이번에 올린 2개의 PR에는 미처 적용을 못했다.
다음에 올라오는 PR에는 꼭 적용해봅시다!!
기존의 기능들을 API 엔드포인트를 기준으로 issue로 등록해둔 다음 각 인원들이 작업을 pull 해가는 방식으로 작업을 진행하고있다.
우선 빠르게 POST /user/login
기능을 개발하기로 했다.
Redis가 얽혀있는 기능이기 때문에 해당 테스트를 구성하는 과정에서 Redis 테스트를 재사용 가능하게 구성해둬야 추후 다른 인원들이 작업을 진행하는 데 어려움이 없을 것이라고 판단했기 때문이다.
이 과정에서 임베디드 Redis를 적용하려다가 다양한 문제를 인식하고 결국 TestContainer를 적용하게 되었다.
POST /user/login
기능과 TestContainer 적용이 하나의 PR에 올라와있으면 PR 단위가 너무 커질 것 같아 별도의 브랜치로 작업해서 PR을 올렸다.
TestContainer 작업 PR: https://github.com/BCSDLab/KOIN_API_V2/pull/27
적용 과정에 대한 블로깅도 했다. TestContainer 적용하기
TestContainer를 적용하고 난 뒤에는 Redis Container를 띄워 Redis를 사용하는 환경도 테스트할 수 있도록 구성할 수 있었다.
로그인 flow는 다음과 같이 진행된다.
이 Redis에 저장하는 로직을 최대한 간단하게 적용하기 위해 Spring Data Redis를 적용했다. 사용 방법은 생각보다 간단해서 Spring Data (JPA, JDBC 등)를 사용해봤다면 금방 익숙해질 수 있을 것 같다.
레디스 테스트를 어떻게 해야할 지는 항상 고민이였는데 이번에 TestContainer를 적용하면서 나름 깔끔하게 해결할 수 있었다.
추가로 mysql과 h2의 문법차이를 신경써야했던 부분까지 해결할 수 있어서 많은 부분을 개선할 수 있었다.
아직 팀 문화가 어색하고 작업단위를 구성하는것이 어색한 팀원들도 있기 때문에 주기적인 회고가 필요할 것 같다는 생각이든다.
부담되지 않는 선에서 프로젝트 회고 시간을 별도로 마련해봐야겠다는 생각이 든다.