패스트캠퍼스 백엔드 개발 4기 부트캠프_AduCalendar

HJoo·2023년 5월 30일
0

DAYistory

목록 보기
6/8
post-thumbnail

💙시작

안녕하세요! 패스트캠퍼스 기자단 HJoo입니다. 오늘은 지난달 진행한 미니 프로젝트를 주제로 포스팅을 준비했습니다. 미니프로젝트의 주제는 회사의 연차/당직을 관리하는 캘린더 서비스 구현하기! 인데요, 처음으로 프론트와 함께 협업하며 맨땅에 헤딩한 아주 힘들었던 프로젝트랍니다.. 힘들었던 만큼 소중한 제 첫 번째 협업 프로젝트를 소개합니다!

⭐Adu! Calendar⭐

👩🏻‍💻참여

백엔드 팀원은 총 4명으로 이루어져있고, 제가 팀장을 맡았습니다!🥲

  • 유⭐주 - 팀장
  • 김⭐헌
  • 정⭐은
  • 류⭐우

⚒️기술스택

이번 프로젝트는 스프링부트 프로젝트로, Rest API로 문서화를 진행했고 쿼리를 다양한 방법으로 다뤄보았습니다:)

  • SpringBoot
  • Rest Api
  • JPA
  • QueryDSL
  • MockMvc
  • AWS

🔧협업 도구

협업 도구를 이용해 다른 백엔드 팀원들과, 프론트 팀원들과 함께 협업을 진행했는데요, 자유자재로 다루지 못해서 아쉬운 마음이 들었습니다 🥲

  • Git
  • GitHub
  • Slack

🗂️데이터베이스

서버를 띄우기 전까지 h2를 이용했고 서버를 띄운 후에는 MariaDB를 이용했습니다.

  • MariaDB
  • h2

시스템 아키텍쳐 설계

💡Backend Focus

🗒️구현 사항

ㅤ🙋🏻‍♀️유저 관련 기능

  • 회원가입
  • 로그인
  • 사용자는 USER(일반 유저)와 ADMIN(관리자)로 구분
  • 관리자는 각 유저의 권한 설정 가능
  • 개인정보 수정, 삭제

ㅤ🗓️️연차/당직 관련 기능

  • USER는 ADMIN에게 연차/당직 등록, 수정, 삭제 신청
  • ADMIN은 USER의 신청을 승인/거절
  • 캘린더에서 사용자들의 연차와 당직 보여주기
  • USER 본인의 신청 내역과 신청 결과(승인/거절) 보여주기

ㅤ자세한 기능 구현 사항은 api문서

🔗ER-Diagram

사용한 엔티티들의 관계를 보기 쉽게 ER-Diagram으로 만들어보았습니다 :)

🎥시연 영상

로그인 - 사용자의 이메일과 비밀번호를 이용해 로그인을 진행합니다.

회원가입 - 이름, 이메일, 비밀번호, 비밀번호 확인을 이용해 회원가입을 진행합니다.

전체 일정 조회 - 승인되었거나 승인 처리중인 일정들을 조회할 수 있습니다.

일정 수정, 삭제 요청 - 로그인 상태가 아닌 경우 로그인을 해야한다는 알림이 뜨며 수정 및 삭제를 할 수 없고 admin 페이지에 접근할 수 없습니다.

일정 수정, 삭제 요청 - 본인의 일정이 아닌 경우 권한이 없다는 알림이 뜨며 수정 및 삭제를 할 수 없고, admin 페이지에 접근할 수 없습니다.

ADMIN 페이지에선 Admin 사용자가 User들의 일정 승인, 수정, 삭제 요청을 처리할 수 있습니다.

관리자 페이지 - 사용자들을 조회할 수 있고 사용자의 권한을 변경할 수 있습니다.

존재하지 않는 페이지를 조회하려할 경우 접근할 수 없습니다.

User는 본인의 개인 정보를 조회할 수 있고, 신청 일정을 조회할 수 있습니다.

💡회고

이번 프로젝트를 마무리하고 프론트와 함께 회고를 진행했는데요, 처음 해보는 회고에 어떤 대화를 나누어야 할지 감이 안 잡히기도 했지만, 다음 파이널 프로젝트에 굉장히 많은 도움이 되겠다는 생각이 들었습니다 :)회고한 내용을 간단히 적어보겠습니다!

개선해야겠다고 생각한 문제점⭐

  • 💡문제 1. (프론트) 회의 진행하며, 기능 구현에서 백엔드의 의견이 많았는데 그 내용에 대해 가능하다/불가능하다 확답을 줄 수 없는 상황이었다. 그 상황에 매일 회의를 진행하는게 어려웠다.

  • Q. 문제가 생겼던 원인 파악
    A. 처음 사용한 라이브러리 기능들이라 그 기능을 사용하는 데에 공부하는 시간이 필요했다. 회의를 매일 하는 것이 오히려 부담이 되었다.

  • Q. 문제에 대한 개선점
    A. 매일 회의를 하는 것보다 커뮤니케이션은 꾸준히 하되 회의 횟수를 적게 하는 걸로 결정하였다.

  • 💡문제 2. 문제가 발생했을 때 프론트와 백엔드의 소통이 원활하지 못했다. 혹시 민폐일까봐 속 시원히 문제가 있다고 (일부는) 말하지 못하고 시간을 많이 잡아먹어버렸다.

  • Q. 문제가 생겼던 원인 파악
    A. 서로 무슨 일을 하는지 소통이 부족했고 서로 기능 부분에 대해 잘 모르고 공부하며 했기 때문에 발생한 문제인 것 같다. 서로 (백엔드와 프론트엔드) 상대에게 부담을 주고 싶지 않고 싶었다.

  • Q. 문제에 대한 개선점
    A. 문제가 발생하면 (일부는) 각자 해결했다. 앞으로는 백엔드와 프론트는 소통을 많이 해야할 것 같다!


잘했다고 생각한 부분⭐

  • 백엔드는 서로의 코드를 거리낌 없이 지적하며, 피드백을 주고받았다. 처음부터 그러기 쉽지 않지만 첫 단추를 잘 끼운 탓인지 매번 기능을 추가할 때마다 토의를 한 후, 좋은 의견을 적용시킨 코드를 만들어냈다.
    잘 못할까봐 두려워하지 않고, 기분이 상할까봐 주저하지 않았다는 점이 참 잘했다고 생각했다!😆

그럼에도 아쉬운 부분🥲

  • 프론트는 본인들끼리 협업을 한 경험이 있어서 깃헙 사용이 자유자재였다. 하지만 우리는 우리끼리 협업도, 프론트와의 협업도 처음이라 깃헙으로 어떻게 협업하는지 잘 몰랐고 어떤 컨벤션을 정해야 하는지도 잘 몰랐다.. 그래서 프론트가 깔끔하게 깃헙으로 협업하는 모습을 멀리서 지켜만 보았다.
    마지막에 전체 회고할 때 이런 점을 말하니, 프론트가 본인들에게 말했으면 알려줬을 거라고 했다😆 다음 파이널 프로젝트는 프론트와 좀 더 친해지고 이런 궁금증도 숨기지 않고 말해야겠다고 생각했다!

🌟마무리

지금까지 미니 프로젝트를 주제로 포스팅을 해보았습니다! 우당탕탕 좌충우돌이 많았던 제 첫 협업 프로젝트였는데요! 금세 지나가버린 시간에 더 잘할걸 아쉽기도 합니다. 다음 파이널 프로젝트에 이 경험을 살려 완벽히 마무리할 수 있길 바랍니다 :-)

profile
안녕하세요. Chat JooPT입니다.

0개의 댓글