서론
거의 한달만의 코인 마이그레이션 진척도 보고인 것 같다.
바쁘다는 핑계로 회고를 미뤄왔으나 2월을 마무리하면서는 꼭 회고를 쓰겠다는 다짐이 근황 보고를 할 수 있게 만들어줬다.
지난번에는 QA, 백로그 설정 등으로 진척도가 거의 없었다.
1달간 얼만큼의 진척도가 있었는지 한번 정리해보자.
Feature
한달동안 총 8개의 PR이 Merge되었다.
문서화를 위한 Swagger 도입과 리팩터링 PR, 온보딩용 PR을 제외하면 5개의 기능이 Merge되었다.
1주일에 기능 1개가 merge되는 꼴인데 음.. 많이 느리다.
아무래도 내가 다른 일로 너무 바쁜 나머지 프로젝트 매니징을 잘 못한게 크게 한 몫 하는 것 같다.
그래도 팀원들이 작업을 pull 해가면서 열정적으로 PR을 꾸준히 올려줘서 감사할따름이다... 덕분에 산다 진짜 ㅠㅠ
Swagger
문서화를 위해 Swagger를 도입했다.
Swagger를 도입하면서 몇가지 알게 된 지식을 정리해보려고한다.
springfox vs springdoc
SpringBoot 3.x버전대에서는 spring fox swagger를 지원하지 않는다. springfox swagger는 jakarta를 지원하지 않기 때문이라고한다.
대부분의 블로그에 보이는 설정이 이 spring fox를 사용하는 방식으로 되어있는데 앞으로는 이거 쓰면 안될것 같다.
마지막 업데이트가 4년전이다.
우리는 swagger 도입을 위해 springdoc을 활용할 수도 있다.
문서도 잘 되어있고 업데이트도 나름 꾸준하다.
https://mvnrepository.com/artifact/org.springdoc/springdoc-openapi-starter-webmvc-ui
아래 의존성을 추가하여 swagger를 사용할 수 있다.
implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.3.0'interface 활용
Swagger 코드가 Controller에 덕지덕지 붙어있으면 꽤나 프로덕션 코드 보기가 불편하다.
Swagger 코드를 인터페이스에 정의하고 이를 implement하는 클래스를 정의하면 보다 깔끔하게 Controller를 관리할 수 있다.
인터페이스로 정의한 부분을 Api, 구현부를 Controller라고 지칭했다.
문서에는 보여주고 싶지 않은 파라미터
ArgumentResolver를 통해 인증 정보를 받기 위한 파라미터의 경우 @Hidden 어노테이션을 통해 Swagger에 표시되지 않게 만들 수 있다.
나는 @Auth와 같이 ArgumentResolver의 대상이 되는 Custom 어노테이션에 @Hidden을 달아줬다.
인기 게시물 조회
팀원이 작업한 내용인데 discussion이 꽤나 인상적이였다.
작업을 하던 팀원이 실시간으로 인기 게시물을 판별하기 위한 로직을 꽤나 복잡하게 설정한 나머지 Redis, Sorted Set 등에 대한 고민에 깊게 빠져 discussion을 올렸다.
조회수에 만료시간도 넣고, 시간 복잡도 또한 고려하면서 작업을 진행하느라 꽤나 복잡한 구조를 가져가고 있었다.
게시물은 공지사항만 존재하고 조회수도 유의미한 값으로 활용되고 있지 않은 상황이다.
고도화하는 시도는 좋으나 작업한 코드의 복잡도에 비해 기대하는 결과물이 미비할것 같다는 생각에 실시간 인기 게시물 기능이 필요한가?라는 질문을 던져봤다.
답변은 No... 되려 존재하지 않는 요구사항을 만족하려다가 유지보수하기 어려운 코드를 작성하는 꼴이 되어버리는 것 같았다.
팀원을 잘 설득하여 인기 게시물을 판단하는 로직은 DB에 있는 조회수 컬럼만 비교하는 간단한 방식으로 진행하기로 했다.
Refactor
보다 나은 협업을 위한 구조를 가져가기 위해 몇몇 리팩터링을 거쳤다.
ArgumentResolver 반환값
인증방식을 구성하는데 있어 ArgumentResolver에서 객체를 반환하는 구조가 추후에 어딘가에서는 문제를 일으킬 수 있다는 불안함이 들었다.
이에 생각을 정리하여 discussion을 올렸고 팀원들의 풍족한 근거와 의견을 들을 수 있었다.
인증에 대한 ArgumentResolver는 id를 반환하도록 리팩터링을 진행했다.
신규인원 온보딩
백엔드 레귤러로 신규 전환된 인원들에 대한 온보딩을 진행중이다.
총 7명이 전환되었고 모든 인원들의 이해도를 맞추기 위해 초록스터디를 활용중이다.
인프라 온보딩
지난 주 총 7명의 레귤러 인원들에게 동아리 인프라 구성에 대한 온보딩 강의를 진행했다.
aws부터 ssh 접속, jenkins, db, nginx 등 동아리에서 구성중인 모든 인프라에 대해 쏟아내듯이 온보딩을 진행했다.
다음주에는 직접 본인의 AWS 계정으로 초록스터디를 수행하면서 만든 애플리케이션을 직접 배포해보면서 체득하는 시간을 가지려고한다.
온보딩 이슈 선정
다음주면 신규 백엔드 전환 인원 7명을 KOIN 마이그레이션 프로젝트에 투입하게 되는데 이 때 인원들에게 할당할 온보딩 이슈도 정의해두고있다.
최대한 도메인간 협력이 없고 간단한 API 위주로 온보딩 라벨을 붙여가며 온보딩 이슈를 선정중이다.
이벤트 스토밍
KOIN 프로젝트에 대한 이해도를 높이기 위해 동아리 전체적으로 이벤트 스토밍 워크숍을 수행했다.
대부분의 인원이 참여하여 워크숍에 참여한 백엔드 인원들은 KOIN이 어떤 서비스인지 파악할 수 있는 시간을 가졌다.
이벤트 스토밍에 대한 구체적인 이야기는 BCSDLab은 성장을 시작합니다 글을 참고해주세요
후기
1학기 중으로 마이그레이션을 마치는 것이 목표다.
처음에는 7명의 인원이 증원되었으니 작업량이 7배로 늘어날 것이라는 단순한 생각이 들었지만 모든 인원이 작업에 익숙해질 때 까지의 시간을 고려해봤을 때 1학기 내에 끝내는것도 꽤나 간당간당 하다고 생각이든다.
3월에는 마이그레이션 작업의 우선순위를 높여서 복잡도가 높은 작업들을 빠르게 쳐내봐야겠다.
(아마.. 가능하다면..?)
Reference
