부모와 아이가 율동 체조를 함께 즐기며 유대감을 기르고
운동을 통한 건강까지 챙길 수 있는 서비스
모성애의 상징인 캥거루의 영어 단어 Kangaroo 와
같이 춤 출까? 라는 의미의 Shall we Dance 의 합성어로
부모와 아이가 함께 춤을 추며 유대감을 쌓는다는 의미를 담음
- 재밌는 율동 체조 게임으로 아이와 즐거운 시간을 보내며 건강 관리를 하고 싶은 부모
- 소아 비만을 치료하거나 예방하고자 하는 4~7세 사이의 미취학 아동 및 부모
| 이름 | 역할 | 전공 여부 |
|---|---|---|
| 김민식 | BE, 팀원 | 전공 |
| 김은지 | BE, 팀장 | 전공 |
| 박민지 | BE, 팀원 | 전공 |
| 신동찬 | FE, 팀원 | 비전공 |
| 윤서용 | FE, 팀원 | 비전공 |
| 이유경 | FE, 팀원 | 전공 |
🛠 Tools 🛠
(1) 놀이를 통한 부모와 아이의 유대감 형성
✅ 성장기 아이와 부모의 교감은 중요하다.
✅ 그 중에서도 함께 놀이 를 하는 것이 매우 효과적이다.
(2) 소아 비만 문제
✅ 코로나19 시기 온라인 수업과 체육 활동의 최소화, 불규칙한 식생활 습관 등으로 소아 비만이 증가하고 있다.
- 이는 고지혈증, 지방간, 고혈압, 당뇨병 같은 성인병으로 이어진다.
- 어릴 적 비만인 아이는 성인이 되어서도 비만이 될 확률이 80% 이상.
➡ 즐거운 율동 체조형 서비스 를 통해 부모와 아이가 함께 유대감 을 기르고 소아 비만 을 관리할 수 있도록 하자.
- 부모님과 아이가 함께 활동함으로써 자녀와 부모 사이의 유대감 형성
- 춤으로 소아비만 예방 및 치료
- 보다 재밌고 쉽게 운동 가능
- 포토카드 기능을 통한 추억 기록
- 칼로리 소모량 및 체중 변화율을 기록하고 확인
📌 커밋 메시지 컨벤션
- 팀원과의 소통
- 편리하게 과거 추적 가능
- 나중에 실무에서 익숙해지기 위해
- 추적 가능하게 유지해주기
- 너무 많은 문제를 한 커밋에 담으면 추적하기 어렵다.
- 쌍따옴표를 닫지 말고 개행하며 작성 → 다 작성한 후에 쌍따옴표를 닫으면 작성 완료
git commit -m "FEAT: 회원가입 기능 추가
- 회원가입 기능 추가"-
커밋 유형은 영어 대문자로 작성하기
커밋 유형 의미 Feat 새로운 기능 추가 Fix 버그 수정 Add Feat 이외의 부수적인 코드 추가/라이브러리 추가/ 새로운 View나 Activity 생성 Docs 문서 수정 Style 코드 formatting, 세미콜론 누락, 코드 자체의 변경이 없는 경우 Refactor 코드 리팩토링 Test 테스트 코드, 리팩토링 테스트 코드 추가 Chore 패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore Design CSS 등 사용자 UI 디자인 변경 Comment 필요한 주석 추가 및 변경 Rename 파일 또는 폴더 명을 수정하거나 옮기는 작업만인 경우 Remove 파일을 삭제하는 작업만 수행한 경우 !BREAKING CHANGE 커다란 API 변경의 경우 !HOTFIX 급하게 치명적인 버그를 고쳐야 하는 경우
- 커밋 유형 이후 제목과 본문은 한글로 작성하여 내용이 잘 전달될 수 있도록 할 것
- 본문에는 변경한 내용과 이유 설명 (어떻게 보다는 무엇 & 왜를 설명)
📌 이슈 컨벤션
- 제목은 영어로 작성한다.
- 내용은 다른 사람이 알아볼 수 있게 본인이 작업할 내용을 적는다.
- 라벨을 설정한다. (
BackEnd,FrontEnd,Feat,Fix,Refactor)
📌 merge request 컨벤션
- 제목은 영어로 작성한다. (이슈 컨벤션과 같음)
- [영어 대문자] #이슈번호 - 해당 이슈 내용 (꼭 이슈랑 동일하지는 않아도 된다. 이슈 번호만 신경써서 적기)
- 내용에는 변경 사항을 적는다.
- 해당 이슈의
closed #이슈를 단다. - assignees를 본인으로 설정한다.
- reviewers를 설정한다.
- 라벨을 설정한다.
- 코드 리뷰를 받는다.
- 변경 request 단 경우 확인 후 resolve를 한다.
- 스쿼시 머지를 한다.
📌 git flow
작업하는 동안 default branch는 develop.
✅ pr 날릴 때 어디로 날리는 건지 꼭 체크하기!
main은 모든 작업이 끝난 후 develop에서 merge 시킨다. —————————————————————————
- main - 초기 세팅 존재
- develop - local 작업 완료 후 merge 브랜치
- minji - 민지 local 브랜치
- eunji - 은지 local 브랜치
- minsik - 민식 local 브랜치
- localdevelop_feature/#issue - 각자의 기능 추가 브랜치 → ex) eunji_feature/#3
—————————————————————————
local - feature에서 각자 기능 작업- 작업 완료 후
remote - develop에 PR - 코드 리뷰 후 Confirm 받고 Merge
- remote - develop 에 Merge 될 때 마다 모든 팀원 remote - develop pull 받아 최신 상태 유지
main → develop → feature/내용, fix/내용, refactor/내용
- 팀원끼리 코드를 공유하기 때문에 일관성 있는 코드를 작성하면 서로 이해하기 쉽다.
- 나중에 입사 지원 시 프로젝트를 하며 코드 컨벤션을 만들어 진행했다고 하면 협업 면에서 유리하게 작용할 수 있다.
📌 FrontEnd
- components 이름은 Pascal Case로 작성한다.
- Non-components 이름은 Camel Case로 작성한다.
- null 또는 undefined일 수 있는 값은 optional chaining 연산자 (?.)를 사용한다.
- 유틸리티 파일을 만들어 중복된 코드를 피한다.
- Presentational 컴포넌트와 Container 컴포넌트를 분리하여 사용한다.
- 고차 컴포넌트(Higher Order Components, HOC)는 적절하게 사용한다.
- JS, test, css로 파일을 분리한다.
- 불필요한 주석을 사용하지 않는다.
- 현재 화면보다 긴 코드는 더 작은 단위의 코드로 리팩토링 한다.
- 주석 처리된 코드는 커밋하지 말고 삭제한다.
- class component가 아닌 function component를 사용한다.
- JSX 문법을 사용한다.
- spread 연산자를 사용한다.
- 구조 분해 할당을 사용한다. let과 const만 사용한다. (var 사용금지)
- 되도록 화살표 함수를 사용한다.
- 직접 null을 체크하기 보다 optional chaining 연산자 (?.)를 사용한다.
- 테스트를 작성한다.
- 적정 수준의 테스트 커버리지를 유지한다.
- 하나의 테스트 파일에서 하나만 테스트 한다.
- 테스트 코드안에서 로직을 사용하지 않는다.
- 테스트 클래스는 하나의 클래스만 테스트 한다.
- 네트워크, 데이터 베이스와 직접 통신하지말고 가짜 함수를 사용한다.
- inline css를 사용하지 않는다.
- 명명 규칙을 지킨다.
📌 BackEnd
문자열을 처리할 때는 쌍따옴표를 사용하도록 합니다.문장이 종료될 때는 세미콜론을 붙여줍니다.🐫 함수명, 변수명은 카멜케이스로 작성합니다.🥙 URL, 파일명은 케밥케이스로 작성합니다.☝ 가독성을 위해 한 줄에 하나의 문장만 작성합니다.주석은 설명하려는 구문에 맞춰 들여쓰기 합니다.
// Good
function someFunction() {
...
// statement에 관한 주석
statements
}연산자 사이에는 공백을 추가하여 가독성을 높입니다
a+b+c+d // bad
a + b + c + d // good☝ 콤마 다음에 값이 올 경우 공백을 추가하여 가독성을 높입니다.
var arr = [1,2,3,4]; //bad
var arr = [1, 2, 3, 4]; //good🔠 생성자 함수명의 맨 앞글자는 대문자로 합니다.
function Person(){}🔠 ENUM이나 상수는 대문자로 합니다.
NORMAL_STATUS = 10;🔠 함수명은 소문자로 시작하고 동사로 합니다.
function getUserId(){}- 패키지는 목적별로 묶는다.
- common(공통기능 관련 패키지), user(User 관련 패키지), coupon(쿠폰 관련 패키지)
- Controller에서는 최대한 어떤 Service를 호출할지 결정하는 역할과 Exception처리만을 담당하자.
- Controller 단에서 로직을 구현하는 것을 지양한다.
- 하나의 메소드와 클래스는 하나의 목적을 두게 만든다.
- 하나의 메소드 안에서 한가지 일만 해야한다.
- 하나의 클래스 안에서는 같은 목적을 둔 코드들의 집합이여야한다.
- 메소드와 클래스는 최대한 작게 만든다.
- 메소드와 클래스가 커진다면 하나의 클래스나 메소드 안에서 여러 동작을 하고 있을 확률이 크다.
- 수많은 책임을 떠안은 클래스를 피한다. 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더욱 바람직하다.
- 클래스 나누는 것을 두려워하지 말자.
- 도메인 서비스를 만들어지는 것을 피하자.
- User라는 도메인이 있을 때, UserService로 만드는 것을 피한다.
- 이렇게 도메인 네이밍을 딴 서비스가 만들어지면 자연스레 수많은 책임을 떠안은 큰 클래스로 발전될 가능성이 높다.
- 기능 별로 세분화해서 만들어보자. (UserRegisterService, UserEmailService 등...)
- 에러 검출(try - catch)
- 최상단에서 에러 검출 하기
- ex) 컨트롤러 서비스 DAO가 있으면 컨트롤러에서 try -catch문 작성
-
컨트롤러 클래스 안에서 메서드 명을 작성 할 때는 아래와 같은 접미사를 붙인다.
메서드명 의미 orderList() 목록 조회 유형의 서비스 orderDetails() 단 건 상세 조회 유형의 controller 메서드 orderSave() 등록/수정/삭제 가 동시에 일어나는 유형의 controller 메서드 orderAdd() 등록만 하는 유형의 controller 메서드 orderModify() 수정만 하는 유형의 controller 메서드 orderRemove() 삭제만 하는 유형의 controller 메서드
-
서비스 클래스 안에서 메서드 명을 작성 할 때는 아래와 같은 접두사를 붙인다.
메서드명 의미 findOrder() 조회 유형의 service 메서드 addOrder() 등록 유형의 service 메서드 modifyOrder() 변경 유형의 service 메서드 removeOrder() 삭제 유형의 service 메서드 saveOrder() 등록/수정/삭제 가 동시에 일어나는 유형의 service 메서드
-
Mapper 클래스 안에서 메서드 명을 작성 할 때는 아래와 같은 접두사를 붙인다.
메서드명 의미 selectOrder() 조회 유형의 mapper 메서드 insertOrder() 등록 유형의 mapper 메서드 updateOrder() 변경 유형의 mapper 메서드 deleteOrder() 삭제 유형의 mapper 메서드
📌 DB 컨벤션
ex.)
- 두 개 이상의 단어를 조합해서 쓸 때는 카멜케이스로 쓴다.
- 한 단어일때는 소문자로 적는다.
1. idx
idx는 테이블명_idx로 하도록 한다.
2. 예약어는 칼럼명으로 사용하지 않는다.
ex) 난이도 테이블의 값 : value = X
3.이분법으로 나눠지는 값은 is‘_‘사용
데이터 구조는 어플리케이션 코드보다 훨씬 지속력이 높다. 잘 정의된 데이터 구조와 테이블 레이아웃은 어떠한 어플리케이션에서도 사용되어질 수 있다. 즉, 데이터 구조는 한번 잘 짜 놓든 아니든 영향력이 오래간다.
한번 컬럼이나 테이블 이름을 정해 놓으면 어플리케이션에서는 그 이름을 코딩으로 사용한다. 만약 컬럼과 테이블의 이름이 변경된다면 의존하고 있던 어플리케이션에서도 수정이 일어나야 한다.
이름이 잘 정의된 테이블, 뷰, 컬럼이 있다면 본인 뿐만 아니라 다른 개발자들도 데이터베이스의 구조를 이해하는데 짧은 시간이 소모될 것이다.