Project Shall-We-Health #1 SR 기획

안광의·2021년 11월 28일

[TOY PROJECT] Shall-We-Health

목록 보기

1/7

시작하며

First Project가 끝나고 바로 Final Project가 시작되어서 미리 준비할 시간없이 바로 SR 기획부터 시작하게 되었다. 이전에 프로젝트에 관한 다양한 아이디어가 나왔었는데 실제 프로젝트를 진행하게 된 후, 고려해야 할 사항이 많아져서 부합하는 아이디어를 찾기가 어려워졌다. 예상치 못하게 발생하는 버그를 수정하거나 새로운 스택을 배워서 적용하는 과정이 필요하기 때문에 4주라는 시간이 결코 길지 않다고 생각해서 조금 서둘러서 SR 기획을 완료했던 것 같다. 하지만 완성도 있는 프로젝트를 위해서는 SR 기획 단계가 탄탄해야 한다는 것을 알기 때문에 최대한 꼼꼼하게 검토하기 위해서 노력하였다.

아이디어 선정

Final Project에 걸맞는 도전적이고 새로운 스킬 사용
실제 서비스로 구현할 수 있을 정도의 아이디어
4주 내에 기본적인 기능을 완성하고 추가적인 기능도 구현할 정도의 난이도

Final Project는 경험을 쌓는 과정이면서 수료 후 취업과도 직결되어 있는 중요한 프로젝트이기 때문에 좀 더 도전적이고 완성도 있는 결과물이 나와야 하는데, 좋은 아이디어가 없어서 고민되었다. 회의 중, 한 팀원이 헬스 파트너를 매칭해주는 서비스가 있으면 좋을 것 같다고 아이디어를 내어서 Shall We Health라는 서비스를 개발하게 되었다.

요즘 관련된 밈이나 용어가 넘쳐날 정도로 헬스나 PT에 관심을 가지는 사람들이 많아지고 있고 Socket.io를 사용한 채팅 기능, 지도 API 관련 기능을 적용할 수 있어서 좋은 아이디어라고 생각했다.

테크 스택 및 파트 분배

Position : Full Stack
Stack: react, redux, axios
Contributions
- 네비게이션 바 구현
- 매칭 게시판 구현
  - 날짜, 지역별 필터링 기능
  - 헬스장 상호명 검색
  - 매칭 리스트 조회 및 마감/신청가능 여부 표시
- 관리자 페이지 구현
  - 유저 관리 페이지 조회/삭제 및 검색 필터링
  - 매칭 관리 페이지 조회/삭제 및 검색 필터링
  - 신고 관리 페이지 조회 및 신고 내용 확인
- 자체 모달, 컨펌 창 구현
- 신고하기 및 탈퇴하기 윈도우 구현

이번 프로젝트는 Full Stack 1명, Front-End 2명, Back-End 1명의 포지션으로 진행하게 되었다. Front-End 파트에서 목업페이지 구현과 같이 Back-End에 비해 시간이 필요한 작업이 많다는 것을 고려하여 포지션을 정하였고 나는 First와 마찬가지로 Full Stack을 맡게 되었다. 우선 Front에서 담당할 파트를 분배하고 Back-End 쪽은 프로젝트를 진행하면서 서포트할 수 있는 부분을 맡을 예정이다.

이번 프로젝트의 Kick(핵심 기능)은 Socket.io와 카카오 지도 API를 활용한 기능이기 때문에 각자 파트를 나누어서 미리 공부하기로 하였다.

프로젝트 요구사항

Bare minimum requirements

운동 파트너 모집 기능
- 일시 및 장소 선택 기능
- 운동 레벨 선택 기능
- 운동 부위 선택 기능
운동 파트너 참여 기능
1대1 채팅기능
마이페이지 활동로그 조회 기능
- 유저 추천 기능
- 유저 신고 기능
지역 별 헬스장 검색 기능
헬스장 위치정보 제공 기능
로그인 기능(로그인, 로그아웃)
회원가입 기능(인증메일 발송)
개인정보 수정 및 탈퇴 기능
관리자 페이지 기능
게스트 로그인 기능
- 가입 없이 서비스의 기능을 체험해 볼 수 있다.
소셜 인증 로그인 구현
- 네이버, 카카오등 유저들이 많이 사용하는 서비스를 통해 간편하게 로그인
페이지네이션 구현
검색 필터링 기능 구현
반응형 웹사이트 구현
- 모바일, 태블릿 pc를 사용하는 유저도 사용할 수 있다.

Advanced

유저 신고 기능
최근 본 게시물 확인 기능
문의하기 기능

Nightmare

버튼으로 변경 가능한 다크 모드
실시간 위치 기반 지도 api 기능
비회원 로그인 구현
React Native를 사용한 앱 구현
검색 알고리즘 구현

First 보다는 완성도 높은 프로젝트여야 하기 때문에 Bare minimum 단계에 많은 기능을 추가하였다. 우선 일정은 Advanced 단계까지 구현하는 방향으로 정하였고 가능하다면 Nightmare의 기능들도 구현했으면 좋겠다.

Team Rule

팀룰의 경우, First Project의 경험을 바탕으로 필요한 사항을 추가하고 Shall-We-Health와 맞지 않는 룰은 삭제하였다. 목업 페이지와 관련된 부분이 브랜치 네임, 커밋 메시지 규칙, PR 형식에 추가되었다.

커밋 메시지 규칙

커밋 메시지는 제목과 본문으로 나누어 집니다. 한 줄만 작성해도 설명이 충분하다면 제목만으로도 괜찮습니다. 하지만 어떤 변경 사항이 있는지 맥락과 설명이 필요하다면 본문을 작성할 수 있습니다. 다음은 제목과 본문을 작성하는 규칙입니다.
1. 타입 첫글자를 대문자로 적어주세요.
2. 타입은 명령어로 작성합니다.
3. 제목과 본문을 한 줄 띄워 분리해 주세요.
4. 제목은 50자 이내로 적어주세요.
5. 제목은 명사형으로 작성해주세요.
6. 제목 끝에 . 는 금지합니다.
7. 본문은 50자마다 줄을 바꿔주세요.
8. 본문은 어떻게 변경했는지 보다 무엇을 변경했는지, 왜 변경했는지 에 맞추어 작성하세요.

예시

$ <type>: <subject> -- 헤더
<BLANK LINE> -- 빈 줄
<body> -- 본문 
<BLANK LINE> -- 빈 줄 
<footer> -- 바닥 글

//type 예시
Feat: 새로운 기능을 추가할 경우 
MockUp: 목업 페이지를 추가한 경우
Fix: 버그를 고친 경우 
Design: CSS 등 사용자 UI 디자인 변경 
!BREAKING CHANGE: 커다란 API 변경의 경우 
!HOTFIX: 급하게 치명적인 버그를 고쳐야하는 경우 
Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우 
Refactor: 프로덕션 코드 리팩토링 
Comment: 필요한 주석 추가 및 변경 
Docs: 문서를 수정한 경우 
Test: 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X) 
Chore: 빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X) 
Rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 
Remove: 파일을 삭제하는 작업만 수행한 경우

Feat: 관심지역 알림 ON/OFF 기능 추가(#123)

시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함

opnion0055: 구분 코드 해결: #123

Lint 규칙

semistandard 를 따릅니다.
주요규칙
space는 두 칸, 탭 사용 x
오직 single quote만 사용
var 는 사용하지 않습니다.
키워드 다음엔 스페이스 하나를 띄워주세요.
참고링크(https://standardjs.com/rules.html)

브랜치 이름 형식

종류	사용패턴	특징
master	master	프로덕션 스냅샷 가장 최신의 배포된 버전
dev	dev	릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
feature	feature/이슈번호-컴포넌트명 feature/issueNum-name	dev에 병합
layout	layout/이슈번호-컴포넌트명 layout/issueNum-name	dev에 병합
hotfix	hotfix/이슈번호 hotfix/#911	마스터에 병합

PR형식

코드 컨벤션을 잘 지켜주세요. 컨벤션 오류로 인한 불필요한 코멘트는 시간 낭비이기 때문에 지양하는 것이 좋습니다.
리뷰 가이드라인을 잘 작성해 주세요. 모든 코드 변경사항에는 의도가 필요합니다. 의도치 않게 변경된 부분이 있다면 되돌려 놓아야 하고, 줄바꿈과 같이 아주 단순한 변경사항이라도 그 부분을 리뷰어가 볼 필요가 없다면 “Just line change” 와 같은 코멘트를 달아 명시하여 리뷰 시간을 줄여줄 수 있을 것입니다. 또는 사용된 라이브러리 업데이트가 포함되었다면 해당 라이브러리의 릴리즈 노트 링크나 스크린샷을 첨부하는 것도 좋은 방법입니다.
작업중, 리뷰 가능 여부를 잘 명시해 주세요. 아직 코드를 작성 중일 때에는 [WiP] (Work in Progress) 를 타이틀 앞에 추가하고, 만약 작업이 끝났으면 이를 제거하고 review-needed 태그를 설정할 수 있습니다. 한 번 작업을 마쳤다고 끝난 것이 아니기 때문에 리뷰를 반영하는 중에도 이 과정을 반복하여 명시해 주세요.
PR 제목

[Client] / #88 / edit: readme

PR 본문

### PR 타입(하나 이상의 PR 타입을 선택해주세요)
-[] 기능 추가
-[] 목업 페이지 구현
-[] CSS 수정
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 반영 브랜치
ex) feature/login -> dev

### 변경 사항
ex) 로그인 시, 구글 소셜 로그인 기능을 추가했습니다.

Issue 형식

Issue 제목

[title] / body

### Issue 타입(하나 이상의 Issue 타입을 선택해주세요)
-[] 기능 추가
-[] 목업 페이지 구현
-[] CSS 수정
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 상세 내용
ex) Github 소셜 로그인 기능이 필요합니다.

### 예상 소요 시간
-[] `0.5h`
-[] `1h`
-[] `1.5h`
-[] `2h`
-[] `2.5h`
-[] `3h`

### 라벨
- 예상 소요 시간: `E: 1h`
- 그룹: `client`, `server`

에러 핸들링 형식

> 해결된 에러라면 라벨에 'Complete' 를 달아주세요.
> 미해결된 에러라면 라벨을 'In progress' 로 변경해주세요.

### 어떤 에러인가요?
- 

### 에러 메시지

$ 터미널의 에러 코드를 여기 넣어주세요.

### 에러 핸들링 방법

- 핸들링 방법에 대해서 간단하게 기록해보세요.

// 코드가 들어가도 좋아요!

### 에러 핸들링을 위해 참고한 레퍼런스 링크
[링크]()

변수 이름 - Camel-case

clientLogin

파일 & 생성자 이름 - Pascal-case

ClientSide

node & npm 버전 통일

node: v14.17.6
npm: v6.14.15

프로젝트 진행 규칙

팀원들간 존댓말을 사용하며, 상호 존중하는 마인드를 가지고 커뮤니케이션에 최선을 다한다.
의견이 나눠질 경우 다수결로 결정하며, 2:2로 나뉜 경우 아래의 규칙대로 의사결정한다.
- 충분한 의사소통을 통해 프로젝트에 더 적합한 의견으로 결정한다.
- 의견이 나뉘는 관련 파트의 담당 팀원의 의견으로 결정하되, 다른 팀원의 의견 중 반영할 수 있는 부분은 채택하는 방향으로 결정한다.
미리 약속한 회의 시간을 지키지 않을 경우, 지각비 10분 당 3000원을 팀원을 위해 기쁜 마음으로 기부한다. (줌 접속한 시간 기준)
코드 리뷰는 새로운 기능이나 팀원들과 공유하고 싶은 내용이 있는 경우 자세히 설명한다.
회의 중 회의록 작성 및 PR Merge는 팀원 간 돌아가며 진행한다
DevLog는 오전 정규회의 전까지 제출하고 평일은 의무로 작성한다.
정규회의 시간:
- 평일 오전 10:00~10:30(현재 진행상황, 오늘 처리할 task 등 브리핑)
- 평일 오후 17:00~18:00(코드리뷰 및 PR Merge, KPT 회고록 작성)

DB Schema

데이터베이스 스키마는 First Project보다는 복잡해졌지만 기능 구현에 필요한 부분을 담으면서 최소화시켜서 짜려고 노력하였다. 1대1 매칭 그룹을 나타내는 Posts 테이블과 각 그룹의 채팅을 저장할 Chats 테이블, 추천 정보를 저장할 Thumbsups 테이블, 마지막으로 신고하기 기능 구현에 필요한 Issues 테이블을 생성하고 참조 관계를 설정해주었다.

마치며

이전 프로젝트에서 SR 기획을 하고 두번째로 진행을 해서 생각보다 빠르게 마칠 수 있었다. 지난번보다 미흡했던 부분도 보충하고 서비스의 로직도 다시 한번 확인하면서 프로젝트 진행 중에 놓칠 수 있는 부분을 검토하였다. First Project 처럼 기능 별로 파트를 나누지 않고 Back-End와 Front-End를 나누었기 때문에 서비스의 Flow나 API에 대해서 확실하게 이해할 필요가 있었다.

안광의

개발자로 성장하기

다음 포스트