[63] 부트캠프 TIL - 본캠프 44일차(Spring 조별프로젝트 KPT 회고)

※ 프로젝트 내용 관련 포스팅은 추후에 할 예정입니다.

📁️ 프로젝트 설명

간단한 SNS시스템 개발)

- 로그인

- 회원가입

- 프로필관리

- 뉴스피드 게시글관리

- 친구관리

 

프로젝트 기간 및 인원)

- 총 5일(실작업 3일)

- 인원 4명

 

사용기술)

- JAVA, Spring, JPA

 

📚 담당역할

친구요청생성)

ㄴ 요청받을사람의 기본키id와 status(상태값)을 대기(PENDING) 로 보내 저장

 

친구요청생성 - 예외처리)

ㄴ 요청을 이미 보낸경우
ㄴ 요청받을사람이 이미 나에게 요청을 한 경우
ㄴ 자기자신에게 요청하는 경우

ㄴ 요청받는 사람과 요청보내는 사람의 상태값이 대기(PENDING) 또는 승인(ACCEPT)인 경우

 

친구요청생성 - 예외처리 모두 통과후  등록 되는 조건) 

ㄴ 테이블의 데이터가 아예 0개일 경우

ㄴ 요청 받는사람이 친구요청을 거절(REJECT)했을 경우

 

※  요청 보낼때 - 로그인 고유번호(id) == fromUserId  요청생성 / 요청조회,요청응답 (나눠진 조건에따라 기준 id가 변경)

 

 

친구요청조회)

ㄴ 상태값이 대기(PENDING)이면서 요청받는 사람과 요청보내는사람의 고유번호(id)를 확인하여 조회

※  요청 조회시 - 로그인 고유번호(id) == toUserId

 

친구요청응답)

ㄴ 본인이 받은 요청이면서 상태값이 대기(PENDING)인 데이터만 응답할 수 있도록

 

친구요청응답 - 예외처리)

ㄴ 입력값이 ACCEPT(승인), REJECT(거절)이 아닐 경우에는 유효하지 않은 상태값으로 예외처리
ㄴ 위의 2가지 조건을 충족한 후 선택한 값이 대기(PENDING)일 경우에만 응답할 수 있도록 2차처리

(조회 조건에 들어가있지만 2차체크)

※  요청 응답시 - 로그인 고유번호(id) == toUserId

 

 

📓 KPT회고

1. Keep ( 현재만족하는 부분, 계속 이어갔으면 하는 부분, 좋았던 점 )

ㄴ 맡은 부분에서 다행히 오류가 극심하게 발생하지 않았다.

ㄴ 위와 같은 결과로 주어진 짧은 시간안에 프로젝트를 마무리 할 수 있었다.

ㄴ 깃으로 협업을 하는 부분에 대해 가이드 같은 것을 받은 기분이다.(어떻게 진행해야할지 감이잡힌느낌)

ㄴ 깃에서 코드병합중 충돌과정을 해결하는 방법에 대해서 잘 배웠다.

ㄴ 프로젝트 중 필수적인 소통 및 돌발적인 상황에 대한 공유나 전체적으로 소통이 엄청 잘되었다.

ㄴ 서로 존중하면서 예의 바르게 행동하는 팀원들 덕분에 분위기가 정말 좋았다.

ㄴ 팀원들의 코드를 보면서 배우는 점이 많았다고 생각이 든다.

ㄴ 프로젝트 기획단계에서 전체 팀원이 참가하여 기능에 대한 예외처리부터 ERD,와이어프레임 등 상세한 부분까지 정해서 좋았다.

ㄴ 기획단계에서 꼼꼼하게 진행한덕에 프로젝트 중간에 기획이 변경되는 경우가 없었다고 할 수 있다.

ㄴ 담당 튜터님이 전체 프로젝트 진행되는 부분에서 큰틀부터 사소한 부분까지 엄청 신경써주셔서 배운점이 정말 많았고, 엄청 감사하다고 생각한다.

 

2. Problem ( 불편한점, 개선되어야할 점 )

ㄴ 댓글, 좋아요, 추가검색기능 등을 구현하고 싶었는데 못해서 아쉽다.

※ 하지만 이 선택은 튜터님이 현재까지 한 프로젝트 코드리뷰를 받을지 추가기능개발을 할지 제안을해주셨었다.(우리조는 전체 프로젝트 기간 중 40%정도 여유가 있었기 때문에 충분히 가능했었다.) 고민해본 결과 만장일치로 튜터님께 리뷰를 받기로 했고 이 선택은 모든 팀원들이 100%만족하는 결과였다. 

 

ㄴ 개인적인 성향이 완벽하길 바라고, 내 뒤에 주어진 과제를 바로 끝내야하는 성격이다.
(대학교 과제도 교수님께서 첫수업에 내주시고 학기끝날때 제출하라고 하시면 그 다음주 수업에 제출하는 성격이다.)

ㄴ 성향때문에 프로젝트 기획부터 최종 발표까지 팀장으로서 챙겨야할 부분과 기획 발표준비 개발등에 많은 역할들을 책임져야했는데 그러다보니 개발시간이 부족해서 프로젝트 기간내내 새벽3시는 기본으로 자서 시간관리나 컨디션관리가 필요하다고 생각했다.

 

- 좋은점으로 팀원들의 코드를 보고 많이 배웠다고 했지만, 그만큼 내 자신의 부족함을 느꼈고, 부족한 부분을 채워야겠다고 생각했다.

3. Try ( Problem 해결책 )

ㄴ 개인적으로 학습을 더 많이 해야겠다고 생각했다.

ㄴ 좀 더 체계적이고 꼼꼼하게 계획을 세워야 할 필요성이 있다고 생각했다.(그러면 새벽3시까지 무리할 필요가 없었지 않을까 생각을한다.)

 

4. 느낀점

8월달에 처음 조별프로젝트를 진행했을때와 같이 인원이 4명이었다. 대부분 5명인 조들이기 때문에 개발속도나 프로젝트의 규모가 줄어들 수 밖에 없다고 생각했다. 하지만 이런 우려는 기우였다. 모든 팀원들의 기본 실력이 다들 출중해서 프로젝트 총기간 5일중 3일차에 이미 주어진 작업들을 전부 완수해냈다. 1차로 이때 마음이 좀 놓였던 것 같다. 

 

그리고 추가 기능에 대해서 내가 생각해놓은 기획이 있어서 회의를 진행했다. 이 회의는 튜터님께서 좋은 제안을 주셔서 추가 기능을 개발할지 말지 정하는 자리였다. 내가 생각한 기획을 통해 회의를 진행하면서 추가개발을 하는데 문제가 없겠다라는 확신을 전체 팀원들에게 먼저 주고싶었다. 추가 기능개발에 대한 걱정을 가지고 있다면 시도 조차 해볼 생각을 못할 수도 있는 점을 방지해주고 싶었다. 회의가 잘 마무리되고 추가기능개발을 잘 해낼 수 있다는 확신을 다들 가졌다. 그리고 튜터님이 직접 코드리뷰해주시는 기회와 고민을 했는데 만장일치로 추가기능개발은 멈추고 리뷰를 받기로 했다. 

 

결과만 말하자면 이 리뷰는 큰 도움이 되었다. 현업에서의 대한 기준으로 여러 사례들을 예로 들어서 설명해주시면서 코드리뷰를 해주시니 듣는 사람의 입장에서 100번 납득이 가고 그리고 더 좋은 방법들을 제시해주시니 생각하는 폭을 넓힐수 있게 되었다고 생각한다. 프로젝트 리팩토링을 꼭 진행해서 학습을 더 진행해야겠다고 생각했다.

 

협업에 대한 얘기를 안할 수가 없는데 튜터님이 가이드라인을 잘 제시해 주셔서 우리 조는 그 가이드라인만 철저하게 준수하는 방식으로 진행했다. 이슈를 생성하고 각 이슈번호에 맞춰 브랜치를 생성하여 각자 작업을 진행하는 형태로 진행했다.

그렇게 작업이 완료되면 pr을 생성하고 생성된 pr은 팀원들끼리 코드 충돌이 발생할 것이기 때문에(같은 파트에서 겹치는 부분이 있어서 무조건 충돌이 날 수 밖에 없었다.) 전체 팀원이 코드를 화면공유를 통해 보면서 충돌을 해결해나가는 식으로 진행했다. 이때 충돌해결하는 방법을 튜터님이 알려주신대로 진행해서 해결이 되었을때 다같이 좋아했던게 기억이 남는다. 

 

이번에 협업하는 방식과 깃에서 코드충돌을 해결하는 방법 등 현업에서 필요한 부분들을 많이 배웠다고 생각해서 좋았다.

그리고 깃 README.md를 본인 포트폴리오로 남기기위해 내용을 알차게 넣고 해야하는 부분을 강조해주셔서 더 신경써서 만들어야겠다고 생각했다.