https://github.com/H-Hive/HHive
https://github.com/H-Hive/HHive
화 → 깃허브 위키작성 : 트러블 슈팅, 기술적 의사결정, 추가 기능 … 등등
각자 공부
—-
6~8 다은님 운동.. —————————————————————————————————!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
9/10 ~ 12/30시까지 CS 각자 공부하고 → 일찍 일어나기!
12/30 ~ 2 식사
6 ~ 7 저녁 식사
7시 코드 리뷰 : 1시간
9~ 11시까지 그 날 일정
JAVA 17버전을 쓴 이유
→ 이게 스프링부트 3 쓰려고 라고 답변하면 꼬리질문 무조건 온다
21버전도 LTS인데? → 답변 고민해본다.
17은 어떤 특징이 있나요
장점들만 남겨놓은 채 업그레이드 되는 구조인데. 대격변이 되는 버전의 변형사항을 알아둬야 한다. 한두개씩이라도
원시타입 vs 참조타입
언어, 프레임워크, 네트워크 cs, 프로젝트 대비
깃허브링크(프로젝트 리드미, 잔디, 깃허브 위키), 블로그 링크(깊게 파고든 건 무조건 쓰자 + 공부한 것), 포트폴리오 세가지 무조건 요구한다.
지각 no, 말없이 자리비움 no
예쁜 말하기
어? 어라? 및 기타 비슷한 어조 금지
힘들거나 제한되는 사항있으면 바로바로 알려주기
화면공유 키고 하기
별일없이 화면공유 1시간 이상 꺼진다 -> 캠켜라.
아침마다
1. 계획표 작성 -> 각자 계획표 공유 -> 최소 80% 달성
2. 일정 공유
진짜 개쩌는 서버 구축해보자... 풀뿌리 민주주의..
10:00 ~ 10:30 스크럼 회의
19:00 ~ PR 날리기 및 코드 리뷰
우선 대용량 트래픽을 가정한 서비스를 구축하고자 하시는 모습에 감동 받았습니다..ㅎ
수많은 러닝커브가 발생할테고 그만큼 많은 이슈들에 부딪히게 될것으로 예상됩니다만
이번 프로젝트가 완료된다면 정말 많은 성장이 이루어진 상태일것이라고 생각합니다.
다만 우려되는점은 실시간 채팅이라는 점과 SSR 기술로는 구현하지 못하는 지도와 같은 프론트적 코드들에
꽤 많은 시간이 소요될것으로 예상합니다. 만약 추후 시간이 많이 부족하게 된다면
실시간 채팅이 아닌 모임 이라는 게시글의 댓글 형태로 채팅을 구현하는 방법도 고려해보시면 되겠습니다.
아래 몇가지 리뷰 남겨보겠습니다.
---
1. 3주차 까지의 MVP 목표에서 프론트는 개별적으로 만들어 진행하고자 하는것으로 보입니다.
러닝커브가 꽤 많은 시간 발생할테고 프론트 또한 배포가 이루어져야 하니 시간 설정에 고려해주세요!
2. MVP 스펙에서 필수기능에 기능 수가 아주 많은것으로 보입니다.
로직적으로 어렵지는 않으나 많은 기능이 생기면 그만큼 많은 프론트 화면이 생기기에 이점도 고려해주시는것이 좋습니다.
만약 이로인해 시간이 부족해지면 기능 구현이 어려운것은 아니나 불필요하게 디테일한 요소들이나
추가적인 기능들은 제외하고 진행하는것이 시간 확보에 어느정도 도움이됩니다.
3. 코드 컨벤션의 경우 네이밍 규칙 혹은 return 시 변수에 담지않고 return 하는 등 사소한 부분들에도 컨벤션들이 지정되어
최종적으로 팀 전체의 코드 스타일이 같아지는것이 협업에 아주 도움이 됩니다.
누군가는 람다식을 사용하고 누군가는 단순히 if문과 throw new를 한다와 같은 부분들도 좋은 협업의 결과라고는 할 수 없습니다.
조금 더 디테일한 코드 컨벤션과 코드 스타일을 수정해주는 라이브러리들도 활용해보시는것을 추천드립니다.
4. git 컨벤션의 경우 git branch 전략, PR전 코드리뷰, git commit message 템플릿, git issue등의 활용법 등을 정확하게 지정해두고
팀 전체인원이 협의하여 사용하시는것을 추천드립니다! Conflict와 혼동을 방지하게 됩니다.
5. 프로젝트 기타 설정시 환경 변수로 빼두어 local 실행 환경을 통일시키는것 좋습니다.
6. Product Rules 의 개발환경에는 Spring, Spring Boot, java, 각종 라이브러리들 모두 버전과 해당 버전을 사용하게된 이유들을 명시해주세요.
선택 이유와 버전이 명시되어 있으면 많은 당황스러운 기술면접 질문들을 예방할 수 있습니다.
많은 시간이 소요되는것은 아니니 꼭 다듬어주세요 꼭! 꼭! 별표 다섯개 입니다.
7. API 명세서상 USER API의 /profile/users 이 들어간 URL Mapping 들은 profile(entity) 즉, 자원(resource)이 아니기 때문에 Restful API에 적합하지 않습니다.
Restful API가 어떤것인지 이번 기회에 꼭 확립하고 넘어가주세요.
ex) GET /api/users/{userId} 와 같은 형태가 프로필 조회 URL이라고 할 수 있습니다.
8. USER API에서 카테고리를 선택할 수 있도록 되어있으나 category는 엔티티로 구분되어 있음에도 카테고리를 CRUD하는 API가 존재하지 않습니다
어떠한 의도로 API들이 구성되었는지 알아보기 힘듭니다..!
9. Party API에서 PathVariable인 {Party_id} 에 P는 소문자여야 합니다..!
10. 알림 기능은 어떤식으로 구현하는지에 따라서 난이도가 꽤 높은 작업이 될 수 있습니다. 어떤식으로 구현 예정인지 설명해주세요!
11. 위치기반이 어렵게 느껴지신다면 지역 카테고리에서 파티를 생성하고 글을 작성할 수 있느 형태로 풀어낼 수 있을듯 합니다.
담당 튜터님과 서비스에 대해 상의하여 가장 좋은 방법을 선택해주세요!
추가적으로 할 것
발표 대비