Project/개다모

개다모 솔루션 기획 및 설계

S_N_Y 2024. 2. 17. 19:44

 

#0 프로젝트 개요 및 추진 배경🏃‍♂️

현재까지 서로 공부했던 Java와 Spring 개념들을 적용해보고자 팀 프로젝트를 시작하게 되었다. 깊게 배우지는 않았지만 코드에 직접 기술들을 활용해보면서 배운 개념을 좀 더 또렷하게 만들고 모르는 부분이 있으면 확실하게 물어보면서도 각자 아는 게 있으면 서로 가르치고 배우면서 구현 능력을 키우는 바에 목적을 두고 프로젝트를 구성하게 되었다.

 

 

게시판과 댓글 기능, 마이페이지 기능이 있는 와이어 프레임

 

#1 기획 및 목표🏋️

주제는 콘텐츠 업데이트를 용이하게 할 수 있도록 정의되어진 news feed 데이터 형식의 애플리케이션으로 정했고 지식공유의 장이 될 수 있도록 자신의 피드에 게시글과 코멘트를 작성하고 다른 사람이 볼 수 있는 전체 피드에 올라올 수 있도록 설계하였다.

 

목표는 이렇게 정하였다.

1. JWT토큰을 이용하여 로그인과 회원가입 기능을 구현해보기 ✅

2. 게시글과 댓글의 CRUD기능과 테이블 간 유연한 연관관계 설정해보기 ✅

3. 마이페이지에서는 내가 쓴 글만 볼 수 있게 구현해보기 ✅

4. 개인정보 수정 및 회원 탈퇴 기능 생각해보고 구현해보기 ✅

 

#2 프로젝트 환경

 

1. 프로젝트 명 : 개발자 다 모여(개다모) - 개발 블로그 애플리케이션

2. 개발 인원 : 4명

3. 개발 기간 : 02.07-02.14

4. 기술 스택 및 웹 서버 : Spring Boot 3.2.2, JDK 17, Spring MVC, Lombok, Jpa, MySQL 8.3.x, JWT, Tomcat 10.1.18, slack, notion

개발회의는 메타버스 ZEP을 이용하여 실시간 소통회의를 통해 그 안에서 서로의 화면을 공유하며 모르고 헷갈리는 코드를 물어보거나, slack과 notion을 이용하여 각자 진행된 상황을 공유하고 PR approval과 각자 프로젝트에 pull을 받으라는 등등 소통방식이 유연하게 되도록 진행하였다.

 

#3 기능 명세서

✅ 모든 기능들의 필수적인 항목은 들어오는 데이터 모두 잘못된 데이터값이 들어오면 exception처리를 하도록 유도하였다.

 

<회원>

- 회원가입 : 사용자는 이메일과 비밀번호를 통해 회원가입할 수 있다. - 비밀번호는 secrect key로 암호화

- 로그인 : 이메일과 비밀번호로 로그인할 수 있다. - JWT토큰 사용

- 회원탈퇴 : 회원탈퇴할 수 있다. - 이 부분에서 여러 가지 고민을 하게 되는데 추후에 블로그에 작성

- 회원 프로필 조회 : 자신의 회원 정보를 조회할 수 있다.

- 회원 정보 수정 : 회원 정보를 모두 수정할 수 있는데 수정시, 비밀번호를 한 번 더 받아 수정할 수 있게끔 할 수 있다.

<게시글>

- 게시글 전체 조회 : 전체 게시글 목록을 메인페이지에서 조회할 수 있다.

- 게시글 단건 조회 : 특정 게시글의 정보를 조회할 수 있다.

- 게시글 등록 : 인증 처리된 유저만이 자신의 게시글을 작성할 수 있다.

- 게시글 수정 : 인증 처리된 유저만이 자신의 게시글의 내용을 수정할 수 있다.

- 게시글 삭제 : 인증 처리된 유저만이 자신의 게시글을 삭제할 수 있다.

<댓글>

- 댓글 조회 : 모든 사람이 게시글에 달린 댓글을 조회할 수 있다.

- 댓글 작성 : 작성자에 한해서 댓글을 작성할 수 있다.

- 댓글 수정 : 작성자에 한해서 댓글을 수정할 수 있다.

- 댓글 삭제 : 작성자에 한해서 댓글을 삭할 수 있다.

 

#4 문서 작성 방법 및 팀원간 규칙

 

- 문서 작성 방법 📑

와이어프레임 작업은 figma를 통해서 실시간으로 같이 설계하였으며,

api 설계 및 프로젝트 진행방향은 team notion에 작성하였고

ERD 설계는 ERDCloud를 통해 기능이 추가적으로 생길 때마다 서로의 의견을 물어보며 설계하였다.

 

- 팀원간 규칙🧑‍🤝‍🧑

1) github PR과 default  branch 변경 : PR이 있을 때 merge approver를 2명 이상 받기로 설정하였고 main branch가 아닌 dev branch로 먼저 default로 잡아 개발 후 최종적으로 main branch에 merge하기로 했다.

2)  기본 commit convention으로 유도 : 서로의 commit의 가시성이 좋게 공공연하게 알려져 있는 commit convention을 사용하자고 말해보았다. 끝나고나니 서로의 commit이 무슨 유형인지 한 눈에 알 수 있어서 좋았다.

3) 진행상황 openly 공유 : 각자 진행 상황을 허심탄회하게 오픈하며 같이 성장할 수 있도록 돕기로 했다. 

 

 



#5 계획할 때의 회고 💭 - 아쉬웠던 점과 개선 방향

 

기획 단계의 api 설계의 방향성을 확립했던 시간 📢

지금 생각해보니 아쉬웠던 점은 현재는 고쳐진 상태이지만 계획단계에서 api 설계를 다같이 각자 맡은 부분을 notion에 실시간으로 적는 일이 있었는데 각자의 생각이 다르기에 api 설계가 완벽하게 되지 않아 후에 PK명은 확실하게 무엇으로 할지, restful한 api는 뭔지 고민하는 시간이 상당하였다. 그래서 restful한 api를 설계함에 있어서 수정되었던 단계들이 많아졌던 것 같다. 나중에라도 기획단계에서의 각자의 생각을 존중하면서 restful한 api가 나오려면 각자가 원하는 api의 의견을 모두 정리한 후 처음부터 확실하게 잡아서 부가적인 이슈들은 다 정리하고 기능 개발 구현에 집중할 수 있도록 유도해야겠다는 교훈을 얻었다. 또한 소통하는 방법에 있어서 각자의 생각을 어필하고 유연하게 조율하는 방법에 대해서 얻어갔던 시간이었다.