1. 오늘 학습한 내용
1.1. 뉴스피드 팀 프로젝트
1.1.1. 프로젝트 아이디어 구상
다양한 기능보다는, 학습하고 있는 Spring, JPA의 기본기를 제대로 발휘할 수 있는 기능을 먼저 생각했습니다. 그리고 너무 많은 기능보다는 현실적으로 고려하되, 차후에 개발하면 좋겠다고 생각하는 기능들을 따로 분리했습니다.
→ 개인적으로는 듣기에 간단한 기능이라도 확장에 따라 기술적으로 고민할 거리가 있거나, 도메인에 대한 고려를 해볼 수 있는 기능들을 개발했으면 좋겠다고 생각했습니다.
프로젝트 문서에서 주어진 필수 기능 가이드와 도전 기능 가이드를 참고하여 요구사항을 도출했습니다. 그리고 크게 도메인을 6개로 나눠 요구사항을 분류했습니다.
→ 이전에 학교나 회사에서 프로젝트를 했을 때 적용했던 애자일 프로세스처럼 요구사항을 도출하여 프로덕트 백로그, 스프린트 백로그를 작성하고 스프린트를 계획해서 스크럼 및 회고를 통해 공유 및 수정하며 개발하기에는 단기간의 프로젝트라서 적절하지 않다고 생각했습니다. 차후에 긴 호흡의 프로젝트에서는 팀원들과 조율하여 도입해볼 수도 있다고 생각합니다.
1.1.2. 와이어 프레임 작성
피그마를 잘 다루시는 팀원분이 와이어프레임을 만들어주셨습니다. 따라서, 와이어프레임을 보며 요구사항들의 동작 흐름을 파악하며, 어떤 데이터가 필요한지 또 어떻게 데이터가 움직여야하는지 파악했습니다.
→ 와이어프레임과 요구사항을 대조하면서 수정하는 작업 덕분에, 팀원 모두가 추상적으로 조금이라도 다르게 생각하는 것이 아니라 구체적으로 요구사항의 동작 흐름을 이해할 수 있었습니다. 그리고 미처 고려하지 못한 기능이나 데이터도 찾아낼 수 있었습니다.
1.1.3. ERD 작성
와이어프레임과 요구사항을 바탕으로, ERD를 구성했습니다. 테이블과 테이블의 컬럼을 정의하고, JPA를 사용하기 때문에 클래스로 표현되는 entity임을 고려하면서 작성했습니다. 연관 관계와 제약조건도 고려했습니다.
3.1 Account와 Profile의 분리
다른 팀원의 의견에 따라 Account와 Profile을 분리했습니다. 도메인을 Auth와 Profile로 나눠서 개발하는 만큼, Auth에 사용되는 이메일, 비밀번호만 별도로 Account로 관리하고 나머지 정보들은 profile을 통해 관리하도록 구성했습니다.
Account와 Profile이 동기화를 맞춰야하거나 2가지 정보 모두가 필요한 상황에서 어떤 것이 효율적인지 고려할 점이 있었지만, 단기간의 프로젝트이니 이번에 이렇게 한 번 해보는 것도 괜찮겠다고 생각했습니다.
3.2 집계 데이터의 별도 컬럼 생성 여부
Post테이블에 좋아요 개수와 댓글 개수, 그리고 Profile 테이블에 팔로워 수와 포스트 개수를 따로 컬럼으로 만들지에 대해 의견이 나뉘었습니다.
- 컬럼으로 따로 만들기
- 별도의 쿼리가 필요 없이 바로 값을 사용할 수 있습니다.
- 해당 데이터를 사용하는 로직들에서 값의 정합성을 유지하기 위해 추가적인 로직이 필요합니다.
- 따로 만들지 않기
- 카운트 쿼리 등 추가적인 쿼리가 필요합니다. 데이터가 많아지면, 조회 성능과 속도에 문제가 생길 수 있습니다.
- 정합성에 대한 고려를 하지 않아도 됩니다.
튜터님께서는 비즈니스적으로 각 값마다 정확하게 정합성을 유지하는 것이 의미를 가지는지 판단해보고, 그것에 따라 결정하는 것도 좋은 방법이라고 해주셨습니다. 따라서, 페이징과도 관련이 있는 댓글 개수와 포스트 개수는 카운트 쿼리를 이용하고, 정확성이 비즈니스적으로 중요도가 떨어지는 좋아요 개수와 팔로워 수는 컬럼으로 값을 만들기로 결정했습니다.
1.1.4. API 명세 작성
요구사항, ERD, 와이어프레임을 바탕으로 API 명세를 작성했습니다. 먼저 공통 응답을 만들었습니다. 그리고 도메인별로 각자 역할을 나눠서 API를 정의했습니다.
5.1 RESTful 원칙대로 명사 복수 종결 vs 실용성을 위한 동사 사용
명사의 복수형으로 끝나는 것이 RESTful하게 리소스를 나타내는 방식입니다. 다만. 필요한 API를 완전히 RESTful 하게 작성하는 것이 어려운 경우가 있습니다. 인터랙션 도메인에서 특정 게시글의 좋아요와 다른 사용자를 팔로우할 때 사용하는 API는 각각 해당 테이블에 데이터를 생성합니다. 그래서 리소스에 초점을 맞춰서 likes와 follows를 사용했습니다.
다만 명사보다 동사를 사용하는 게 자연스럽다고 생각하는 의견도 있었습니다. 다만 튜터님의 피드백에서 충분히 의미가 와닿으니 굳이 변경할 필요 없다는 피드백을 받고, 명사형 복수를 그대로 사용하기로 결정했습니다.
1.1.5. 그라운드 룰 정하기
- 프로젝트 관리는 별도의 도구 없이 github projects를 사용하기로 했습니다.
- git convention은 anguler 스타일의 prefix를 사용하기로 했습니다.
- PR은 1명 이상의 코드 리뷰를 통과하도록 정했습니다. 그리고 develop 브랜치로 병합된 경우 ci/cd를 사용하는 프로젝트가 아니므로 스스로 테스트를 하기로 했습니다.
- git 브랜치 전략은 git flow를 사용하기로 했습니다.
오랜만에 팀 프로젝트를 하다 보니, 조금 낮선 느낌도 있었습니다. 기술적으로 경험이 많이 없어부족한 JPA와 SQL에 대해 개인적으로 학습하면서 제가 맡은 도메인을 개발하려고 합니다.
또한, 회사가 아닌 부트 캠프이니만큼 제가 경험했던 부분을 일방적으로 제시하기보다는, 팀원들과 함께 답을 찾아가는 과정 자체를 더 중요하게 생각하며 프로젝트에 임하고 싶습니다. 제가 모르는 부분은 당연히 배우고, 경험했던 부분은 처음부터 팀원들과 함께 다시 고민해보면서 저 스스로도 성장하는 기회로 만들고 싶습니다.
2. 더 알아볼 내용 / 다음에 할 내용
- 프로젝트 세트업
- 담당 도메인인 상호작용 도메인 개발
- git을 통한 협업 중 문제 해결