[항해99 6기] 미니프로젝트를 마치며

 

 

느낀점

 

전체적인 팀원 구성이 프론트 엔드 2명, 백 엔드 4명 이렇게 구성되어서 협업을 하였습니다.

처음 해보는 협업이었기에, 실력이 부족한 자신이 팀원들에게 발목을 잡지 않을까 걱정이 많았습니다.

하지만 프론트의 변기원님과 서유나님께서 백엔드에서 구현하기 힘들었던 부분을

적극적으로 반영해서 맞춰주시고, 요구 사항에 대해서 아무 불만 없이 들어주셨습니다.

 

또한 조장님인 지수민님과 함께 게시글, 댓글을 만드는 과정을 함께 하였습니다.

기본적인 기초가 부족했기에 스프링 부트의 흐름을 같이 호흡을 맞춰가는 과정을 경험해봄을 통해서, 

복습을 할 수 있는 기회가 되어서 좋았습니다.

 

비록 JWT, 오류발생, CORS와 같은 프론트와의 연결관계에 관련하여서는 코딩하지 않아서 부족한 점이 많았지만,

5기 B반 7조의 깃헙 코드를 참고하여서 프론트 참여하기와 백엔드 참여하기 로직을 만들었습니다.

 

비록 복사 붙여놓기를 통해서 작동한 기능이지만,

처음으로, 코드를 한줄 한줄 곱씹으면서 데이터의 흐름에 대해서 이해하고

내 것으로 승화할 수 있어서 개인적으로 뿌듯하였습니다.

 

그래도 아직 모르는 부분이 많고,

팀원들에게 많은 도움이 되지 못해서 죄송함과 고마움이 많았던 한 주였던 것 같습니다.

 

 

참고한 코드 주소)

 

https://hanghae99.spartacodingclub.kr/exhibitions/mini2/5/B

항해99

https://github.com/KimCG1130/miniproject

GitHub - KimCG1130/miniproject

 

1주일동안 진행과정

정확하지는 않지만 크게 다음과 같이 진행하였습니다.

프로젝트 이름

‘개발자들의 모임’ <개.모.임>

 

프로젝트 소개

만들고 싶은 서비스는 많은데 팀원을 어떻게 구해야할지 모르겠고, 취업 포트폴리오는 만들어야하는데 아이디어는 떠오르지 않아 막막했던적 없으신가요?

‘개발자들의 모임’ <개.모.임>은 이러한 고민을 갖고 있는 개발자들을 위한 Social Recruiting Network Service 입니다.

취업준비는 하고 싶은데 포트폴리오가 없어 난항을 겪는 개발자들, 또는 아이디어는 넘쳐나는데 함께할 팀원이 없어 낙심하는 개발자들을 많이 보았습니다. 그렇다고 네트워크를 만들기 위해 학원이나 부트캠프를 다니기엔 부담스럽기도 하죠.

이러한 고민을 갖고 있는 개발자들의 크고 작은 도전에 한 발짝 보탬이 되고자 서비스를 만들어 보았습니다.

 

와이어프레임 및 API

 

🗓️ 주간 계획

 

• 4/08 (금)
  • 와이어프레임 작성
  • API 작성
  • DB schema 작성
  • Github repository 만들기
  • 팀 SA 제출 (19:00)
  • 백엔드 : 기능 분담 및 스키마와 전체적인 틀 구현 (Entity, ERD Program)
  • 프론트엔드 : view 분담(element, 페이지), mock API

 

• 4/09 (토)
  • 백엔드 진행 상황 체크 - 개별 맡은 부분 구상
  • 프론트엔드
    • 전체 view 구현
• 4/10 (일)
  • 백엔드 : 게시글 조회(메인), 게시글 작성 <게시글 완료기능 구현하기 - 접근법>
  1. 좋아요 기능을 구현해보자 (POST?)
  2. 프로젝트에 좋아요 기능을 구현해보기 (중요한 점 : 유저정보를 주고 받아야 됨)
  3. 조건 : 모집 인원은 아직 max로 두지 않고, 작성자가 작성 완료 버튼을 누르면 → completed : ture로 변환
  4. 유저정보를 활용하여 → count반영 & 닉네임 보여주기 (GET)
  • 프론트엔드:
• 4/11 (월)
  • 백엔드: 회원가입, 로그인 완성/ 댓글(detail)
  • 프론트엔드: 로그인, 로그아웃 기능 구현, Access Token 이용해서 전체 컴포넌트 분기 확인, 메인화면 불러오기 완성

 

• 4/12 (화)
  • 백엔드: 1차 ****서버 배포 및 오류 수정
  • 프론트엔드: 상세페이지 불러오기, 글쓰기 api 구현, 댓글 불러오기 구현

 

• 4/13(수)
  • 공통
    • 업무 공유
    • 이슈 공유
    • 프론트 백엔드 합치기
    • 백엔드: 2차 찐찐막 배포?! 및 오류 수정 추가 기능 구현 도전
  • 프론트엔드: 댓글 작성 api post 기능 ****

 

• 4/14(목)
  • 공통
    • 업무 공유
    • 이슈 공유
    • 이슈 사항 수정 및 완성
  • 백엔드: 추가 기능 구현 도전, 배포 및 오류 수정 + 마무리
  • 프론트엔드

 

트러블슈팅~!!!

현재 로그인중인 Id와 관계 없는 Id가 response로 들어오는 현상 😦

 

내가 한 일

1. 회의하기

회의를하면서, 좋아요 기능을 배우지 않아서 어떻게 접근해야 되는지 토론을 하였습니다.

3시간 정도 토의를 하면서 이전 기수의 코드를 참고해서 변형하는 방향성으로 잡았습니다.

 

 

2. 게시글 댓글 

 저번 주에 구현했던, 게시글을 붙여놓기하여서 만들어 보았습니다.

이번에 처음 해본 것은 Dto를 통해서 status값을 200으로 보내주는 것을 해보았습니다.

 

또한 컨트롤러에서 바로 레포지토리를 찾으면 안 좋다는 것을 참고하여서,

리턴 값을 서비스로 보내서 작업하는 것을 배웠습니다.

 

 

전체조회하는 페이징 처리는 수민님이 구현하셨고,

ㄱ. 게시글 작성시 모집인원이 0일경우, 오류를 내는 로직을 간단하게 짜보았습니다.

ㄴ. 주호님이 알려주셔서 프론트로 보내주는 레스폰스 값을 status = true로 보낼 수 있도록 만들었습니다.

 

실수

-> @PathVariable 어노테이션 추가로 해결 (코드를 꼼꼼히 보자!)

-> 댓글을 수정했을 때, 유저가 수정하기 전의 내용을 다시 보여주는 GET API를 설계하지 않았던 점이 있습니다

 

3. 프론트, 백엔드 참여하기 로직 짜기

https://github.com/KimCG1130/miniproject

GitHub - KimCG1130/miniproject

 

위의 깃허브 링크를통해서 좋아요 기능을 컨트롤러 -> 디티오 -> 서비스 -> 엔티티 -> 레포지토리

순서로 하나씩 뜯어보면서 데이터의 흐름에 대해서 공부해 보았습니다.

 

H2 콘솔

 왼쪽 : ARC를 통해서 likeCnt를 프론트와 백 Cnt로 변형하여서 카운팅을 하는 것을 확인

오른쪽 : 프론트와 백이 모집이 다되었을 경우 completed를 true값으로 변형이 되는 것을 확인

(목표 달성 가능성을 확인하였다)

 

내가 짠 로직에대한 설명

 위 사진은 참고한 좋아요 서비스입니다.

순서는

1. 유저가 보고있는 게시글의 postId를 찾기

2. 사용자의 정보와 1번에서 찾은 게시글에 해당하는 like를 찾는다

-> 사용자가 보고있는 게시글에 좋아요를 눌렀는지 좋아요Repository에서 찾는다.

<검증>

3.  if 좋아요를 누르지 않았으면, 좋아요Repository에 회원과 유저의 정보를 넣는다.

4. 저장후 유저가 보고잇는 게시글 postId의 전체 좋아요 리스트를 찾는다.

5. 해당 게시글의 LikeCnt값을 4번에서 찾은 전체 좋아요 리스트의 크기 (전체 수)를 넣는다.

ex) 0개 -> 1개

 6. 반환값으로 likes엔티티 내에 @builder 어노테이션을 통해 만든 toDto를 호출하여

-> LikeResponseDto로

bool(사용자가 좋아요를 눌렀는지의 여부)에 true/false값과 likeCnt값을 보내준다.

 

 이를 활용하여 아래와 같은 로직을 만들었습니다.

 

1. 기능 분리

우선 프론트와 백엔드서비스를 따로 분리하여 대입해보았습니다.

좋아요기능을 활용하여 2개로 분리한 것입니다. 

 

2. 모집완료

여기서 모집인원인 frontNum과 backNum을 Max값으로 하여, Cnt값이 이에 도달하게되면

모집완료의 의미에서 completed값을 false에서 true을 보내주고

추가적으로 참여 요청이 오게되면 오류를 보내주어 각각의  Repository에 저장되지 않도록 하였습니다.

 

3. 모집완료 후 취소할 경우의 false 전환

또한 모집인원이 모두 모여서 모집완료과 되었을 경우, 참여자가 버튼을 한번 더 눌러서

참여를 취소할 경우를 고려하여 IF문에 먼저 Repository에 유저 정보가있으면 삭제하고 ture->false전환

-> else문에서 Repository로 다시 신청하게 될 경우 유저 정보를 저장하여 flase -> ture로 전환

하도록 하였습니다.

 

4. 만약 프론트에 참여했는데, 백엔드에도 참여지원을 할 경우?

프론트서비스 : 백엔드 Repository에서 유저정보가 있다면 -> 에러발생

백엔드서비스 : 프론트 Repository에서 유저정보가 있다면 -> 에러발생

-> 지원 중복을 방지하였습니다. 

 

 

 

링크

http://gaemoim.s3-website.ap-northeast-2.amazonaws.com/

React App

https://www.notion.so/539bca928c154c45bfff997655120a8d?v=1a7143f9d06f479d9d41c9acfcaba62a 

API 설계

https://meteor-ghoul-61a.notion.site/ffa94e7f8a57495bbc1fbe4c89de0ba0

미니 프로젝트 2조 S.A

프론트 FE
kiwonbyun/hanghae99-gaemoim-FE (github.com)

GitHub - kiwonbyun/hanghae99-gaemoim-FE

 

백엔드 BE

ohyeryung/mini22 at develop (github.com)

GitHub - ohyeryung/mini22