[GDG Campus Korea] Whatever you make 2주차 회고록

회고를 적다보니 저번주보다는 한게 많은 것 같아 좀 뿌듯합니당

1. 이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

빨리 개발을 하고 싶은데 세팅에 시간을 다소 많이 소모한 것 같습니다 ㅠㅠ
CICD 구축, Spring REST Docs 세팅, 코드 컨벤션과 제약사항 세팅과 같이 실제 개발에 앞서 에너지를 너무 써버려 실제 프로덕트 코드를 거의 짜지 못했습니다.

막히는 부분에서 확실한 레퍼런스를 찾았다면 금방 해결될 문제였지만 하나의 오류에 너무 집중을 하다보니 진행 속도가 좀 느린 것 같아 반성 중입니다. 적용한 해결 방안을 문서화해두어 같은 실수를 하지 않도록 해야할 것 같습니다!

그리고 코드 리뷰를 처음 진행했는데 팀원분이 잘 짜주셔서 크게 수정할 부분이 없어 좋았습니다. 그래도 꼼꼼하게 읽다보니 시간은 오래 걸리긴 하네요!

Spring REST Docs를 공부하면서 세팅하느라 시간이 좀 걸려서 따로 포스팅해두었습니다.

API 응답 형식부분에서 팀원과 고민을 많이 했습니다.

Java16부터 정식으로 포함된 record 타입을 이용해 하나의 객체로 모든 API 응답을 처리하는 것이 목표였습니다.

우선 최종 확정 형태는 다음과 같습니다.

1) 응답

{
	"data": {
				...
	}
}

2) 응답 + paging

"meta": {
	"page": 1,
	"size": 3,
	"totalElements": 20,
	"totalPages": 7
},
{
	"data": {
				...
	}
}

사실 paging 정보가 없는 일반 응답같은 경우 굳이 data 태그로 감싸야 하나? 라는 물음에서 시작되어 팀원의 동의하에 data를 빼는 방식으로 개발하려고 했습니다.

저희가 작성한 Record 타입에서

@JsonInclude(Include.NON_NULL)

옵션이 있을 경우에 null값인 필드를 제외하고 직렬화를 하는데, data 필드는 항상 값으로 채워져 있기 때문에 하나의 레코드 타입에서 해당 필드의 태그만 제외하고 값을 출력하는 방법을 찾지 못했습니다.

어쩔 수 없이 모든 데이터는 data 태그로 감싸는 것으로 결론내렸고, 여러 레퍼런스를 확인해본 결과 data 태그로 감싸는 곳도 있어서 그냥 FIX 하기로 했습니다.

지금보면 data 태그로 감싸면 금방 해결되는 문제였지만 이런저런 시도를 해보면서 record 타입에 대해 공부가 많이 된 것 같아 나쁘지 않은 경험이였습니다.

빨리 개발을 시작하고 싶은데 아무래도 이미 기획안과 요구사항이 어느정도 확실하게 잡힌 실무와는 다르게 직접 모든 것을 다 해야하는 프로젝트 특성상 개발을 하기 전에 할게 너무 많았습니다 ㅠㅠ

위에 문서 하나당 하루씩 걸렸습니다.....

당장 다음주에 리뷰데이인데 개발을 시작하지 못해서 빨리 개발을 시작해야만 할 것 같은 느낌이 듭니다.

사용할 기술을 빨리 한 번 훑어보고 개발 시작하겠습니다!