사뿐

1. 개인사정이 생겼을 때 팀원들과 공유하기 2. 회의시간 필참하기 3. 혼자 해결할 수 없는 문제에 직면했을 때 팀원들과 공유하기 4. 코드리뷰 적극적으로 참여하기 5. 코딩 마감일 정하고 지키기 6. ***진환님 담타 보장***

1. 협업 잘해서 프로젝트 완성하기 2. 프로젝트를 포트폴리오에 활용하기 3. Don't give up

10:00 ~ 10:30 오전 회의 - 하루 계획 공유 19:00 ~ 19:30 하루 회고 - 진행도 확인 - TIL 공유

- 산책에 대해 구체적인 주제가 있는 어플리케이션이여서 좋은 것 같네요. 해당 어플리케이션을 어떻게 구현할 것인지, 대용량 처리는 어떻게 할 것인지, 사용자가 늘수록 어떠한식으로 데이터 처리를 할것인지에 대해 깊게 고민해보는 것이 취업/면접에 도움이 됩니다. 해당 요구사항들에 대해 정확하게 어떠한식으로 구현하고 어떻게 트래픽처리를 할 것인지에 대해 고민하는 과정이 취업/면접에 유리합니다. - 기술스택에 대해 명시해놓은 곳이 없어서 아쉽습니다. 또한 해당 기술스택을 어떤 곳에 사용할지가 명확하게 명시되어있으면 좋을 것 같습니다. - 어플리케이션에 어떠한 기능이 필요한지를 자세하게 적어놓고 해당 요구사항을 어떻게 구현할 것인지까지 문서화를 해놓고 코딩을 하는 습관을 기르시는게 도움이 됩니다. - 예를들어 '출발지, 경유지, 목적지를 입력하여 산책로를 설정한다.' 가 있으면 출발지는 어떻게 입력하고 이것을 화면으로 어떻게 나타낼 것인지 프론트를 구현하지 않더라도 해당 화면에서 필요한 API가 무엇인지 명확하게 정리되어야 합니다. - 해당 어플리케이션을 구현할 때 사용할 기술스택을 명시하고 명확하게 이 기술을 어떠한 곳에 사용하고 해당 기술에 대해 블로그 검색등을 통해 기본개념을 이해하고 사용하시면 더 좋을 것 같습니다. 곧 면접을 보게 되실텐데 명확하게 이해하고 쓰지 않은 기술은 차라리 안쓰는것보다 좋지 않을 수 있습니다. 왜냐하면 프로젝트에 사용했던 기술에 대해 면접에서 꼬리질문을 통해 질문받을 확률이 거의 100%여서 명확하게 대답을 하지 못한다면 오히려 독이 될 수 있습니다. - 와이어프레임도 잘 작성해주셨네요. 해당 와이어프레임 화면을 가져올땐 어떤 API를 사용하고 "완료"등 버튼을 눌렀을때는 어떤 API를 사용할지 명확하게 정리되어있어야 합니다. API 명세에 이것을 적든 와이어프레임 밑에 적든 어떤화면에서 어떤 API를 사용할 것인지 팀 내부적으로 명확하게 정리하는 것이 중요합니다. (이 과정을 말로 다 설명할 수 있다면 프론트는 구현하지 않더라도 충분합니다) - github rules도 적절합니다. - API 명세도 전체적으로 적절합니다. like -> likes 와 같이 복수형으로 적는게 보편적인 원칙입니다. - ERD 도 잘 작성해주셨고 테이블명, 연관관계도 적절합니다. 한가지 아쉬운 점은 게시글좋아요 테이블과같은 곳에서 boardLikeId로 적지않고 id로만 적어도 게시글좋아요번호 라는 것을 유추할 수 있습니다. 테이블명이 BoardLike이기때문입니다. 게시글 테이블에서도 boardId대신 id로만 적어도 충분합니다.