벌써 세 번째 팀 프로젝트임.
코드카타 적어도 100문제는 하고 시작하고 싶었으나 역시나 언제나 그렇듯 그러지 못했음 (나란놈).
이번 프로젝트는 '뉴스피드 프로젝트'를 주제로하여 팀 별로 서비스를 기획하고 요구 기능들을 구현하는 것이 목표임.
개발 프로세스 가이드는 아래와 같음:
필수 기능 요건도 확인하셈:
추가 기능 요건도 확인하시고:
더 어려운 기능 요건도 추천사항으로 있었음:
이에 따른 우리 팀의 기획 메모임:
*** 나는 뼈대가 되는 필수기능 및 댓글 CRUD와 nodemailer를 통한 이메일 인증 기능을 구현하기로 함.
와이어프레임임:
ERD임:
API 명세의 경우 노션으로 작성하였는데, 여기선 생략하겠음. 앞으로 스웨거에 익숙해질 예정이기에!
선생님의 깃헙을 염탐하며 Git commit type을 아래와 같이 지정하여 커밋 메세지에 통일성을 주었음:
위의 내용들을 SA (starting assignment??)라고 하던데, 여기에 튜터님께서 아주 유익한 커멘트를 주셨음:
"
1. 그라운드 룰
- 좋습니다 :) 하루에 한 번씩 모르는거 토의하기와 같은 것도 좋을 것 같아요!
- 캠이 아니라면, 화면 공유하기 와 같은 룰도 추가해보시는 것은 어떨까요!
----------------
2. 사전 기획 및 설계
2-1. 프로젝트 내용
- 반려동물 중점의 ""인스타그램"" 이라고 이해해도 괜찮을까요? 좋은 것 같아요!
- 그러면 ""해시태그"" 같은 것도 고려해보면 어떨까요?!
2-2. 화면계획서 / 와이어프레임
- 좋습니다! 전체적으로 순서를 ""사용자 관점"" 으로 배치하는 것은 어떨까요?
- 처음 진입시 -> 어디 버튼을 누르면 어디 (화살표로 간략하게)
- 그럼 다음 페이지는 무엇인지의 흐름으로 배치가 되어있으면 더 좋을 것 같습니다!
2-3. ERD
- Likes Table에서 개수는 SQL aggregation(통계, 집계쿼리)을 하시려고 하는 것이 맞는거죠?
- Likes Table에 createdAt 같은 field는 있는게 좋지 않을까요?
- Follow Table에서 follwerId 값과 follwingId 값이 있는데 왜 또 userId 값이 있을까요? 좋아요 기능과 비슷하게 생각해볼 수 있지 않을까요?
- 만약 해시태그를 고려하신다면 Posts Table에 field가 추가가 되면 좋을 것 같아요! (선택)
- content 라는 field만 있다면, 아마 HTML 자체를 저장하겠다라는 의미로 보입니다. 이때 이미지 업로드 등에 대한 고려는 어떻게 하셨을까요?
2-4. API 명세
- endpoint는 다 괜찮은 것 같은데, 여러개 조회시 s를(복수형) 붙여보는 것도 좋을 것 같아요.
- 게시글 상세 조회에 좋아요 개수도 같이 보여야 하지 않을까요? 해당 부분은 어떻게 하실 예정일까요?
- 댓글 좋아요도 있는데, Likes는 Post와 User 정보밖에 없습니다. 어떤 댓글을 좋아요 눌럿는지는 어떻게 구분할 수 있을까요?
2-5. Github rule (버전관리 룰)
- 버전관리 rule도 접두사로 통일되게 잘 정해주신것 같아요!
- 커밋룰 외에 P.R에 대한 룰도 정해보는 것은 어떨까요? 그에 따라 branch를 만들면 그 branch 이름을 어떻게 세팅할지 고민도 해보면 좋을 것 같습니다.
----------------
3. Task 분리 / 업무 분리
- API 기준으로 보면 오롯이 OO님의 Task가 조금 부족하지 않나요?!
- 그 외 적절하게 Model기준으로 API Task 잘 나누신 것 같아요 :)"
"
프로젝트 준비는 대단히 수월하였고, 이를 기반으로 개발을 본격적으로 시작하였음.
금일 발표가 끝나고 오피셜리 프로젝트 종료되었는데, 발표자료를 가지고 다음 글에서 복기하도록 하겠음.