🔑Front-End🔑 :
Lanuage && Framework
Communication Method
State Management
Build Tool
🔓Back-End🔓 :
Lanuage && Framework
Infra
Monitoring
DB
API Documentation
| 허연우 | 백주연 | 이승렬 | 최호연 |
|---|---|---|---|
| @chrisheo | @juurom | @BackEndStory | @hoyyChoi |
| 프로젝트 초기 세팅 DB 설계 API 구현 테스트 코드 작성 |
프론트 화면 구현 서버와 api 통신 연결 반응형 css 적용 |
AWS 세팅 DB 설계 API 구현 테스트 코드 작성 |
프론트 화면 구현 서버와 api 통신 연결 반응형 css 적용 |
- 컴포넌트 기반
- 컴포넌트 단위 관리가 가능하기 때문에 재사용성이 높고 유지보수에 용이합니다.
- Virtual DOM
- Virtual DOM을 이용하기 때문에 메모리 누수가 줄고 수정 비용을 절감할 수 있습니다.
- 지식공유
- 개발 생태계와 커뮤니티가 활성화되어 있어 문제상황에 대응하기 쉽습니다.
- 서버 시작 속도
- 개발할 때 번들링을 하지 않고 ESM 방식을 사용하기 때문에 로컬 서버 구동 속도가 매우 빠릅니다.
- 업데이트 속도
- HMR을 통해 애플리케이션을 다시 시작하지 않고도 변경된 컨텐츠만을 갱신할 수 있습니다.
- Promise기반
- return을 promise 객체로 해주기 때문에 response 데이터를 다루기 쉽습니다.
- 브라우저 호환성
- 크로스 브라우징 최적화로 브라우저(특히, 구형 브라우저)호환성이 좋습니다.
- 단순함
- 다른 전역상태관리(ex. Redux)에 비해 사용하기 간편하고, 이를 활용해 코드의 복잡도를 줄일 수 있습니다.
- 비동기 처리
- 추가 라이브러리 없이 Recoil 자체만으로 비동기 처리를 해결 할 수 있습니다.
- Single-Thread의 non-blocking I/O 이벤트 기반
- Node.js는 단일 스레드(Single-Thread)의 논 블로킹(Non-blocking I/O) 이벤트 기 반 비동기 방식으로 처리되어 높은 처리 성능을 가지고 있습니다.
- npm(node package manager)을 통한 다양한 모듈(패키지) 제공
- 내장 HTTP 서버 라이브러리를 포함하고 있어 웹 서버에서 아파치 등의 별도의 소프 트웨어 없이 동작하는 것이 가능하며 이를 통해 웹 서버의 동작에 있어 더 많은 통제 를 가능케 합니다.
- 웹 개발 호환성
- Javascript 언어로 Front-end 뿐만 아니라 Back-end 개발 환경을 구성할 수 있기에 생산성이 높고 러닝 커브가 줄어듭니다.
- 경량 및 효율성
- Node.js는 다른 웹 프레임워크에 비해 적은 리소스를 필요로 하는 가볍고 효율적인 프레임워크이므로 배포 및 관리가 더 쉽습니다.
- 유형 안전성
- TypeScript는 JavaScript에 유형 안전성을 추가하여 런타임이 아닌 컴파일 타임에 오류를 잡는 데 도움이 됩니다. 이는 코드의 안정성과 유지 관리성을 향상시키는 데 도움이 될 수 있습니다.
- 향상된 코드 가독성
- TypeScript의 강력한 유형 지정 및 명시적 유형 선언은 코드 가독성을 개선하고 이해 및 유지 관리를 더 쉽게 만드는 데 도움이 될 수 있습니다.
- 일관성
- Docker는 응용 프로그램 환경이 서로 다른 시스템 간에 일관성을 유지하도록 하여 종속성 또는 구성의 차이로 인해 발생하는 문제를 방지합니다.
- 효율성
- Docker를 사용하면 애플리케이션의 여러 구성 요소를 별도의 컨테이너로 격리하여 리소스 사용량을 줄이고 효율성을 높일 수 있습니다.
변수명
- Camel Case 사용
- lower Camel Case
- 함수의 경우 동사+명사 사용
- ex) getInformation()
- flag로 사용 되는 변수는 조동사 + flag 종류로 구성
- ex) isNum
- 약어는 되도록 사용하지 않는다.
- 부득이하게 약어가 필요하다고 판단되는 경우 팀원과 상의를 거친다.
주석
- 한줄 주석은 // 를 사용한다.
// 한줄 주석일 때
/**
* 여러줄
* 주석일 때
*/- 함수에 대한 주석
/**
* @route Method /Route
* @desc Function Description
* @access Public
*/- Bracket 사용 시 내부에 주석을 작성한다.
if (a == 5) {
// 주석
}Bracket
- 한줄 if 문은 여러 줄로 작성한다.
// 한줄 if 문 - 여러 줄로 작성
if (trigger) {
return;
}- 괄호는 한칸 띄우고 사용한다.
// 괄호 사용 한칸 띄우고 사용한다.
if (left == true) {
return;
}- Bracket 양쪽 사이를 띄어서 사용한다.
const { userId } = request.user;비동기 함수의 사용
- async, await 함수 사용을 지향한다.
- Promise 사용은 지양한다.
- 다만 로직을 짜는 데 있어 promise를 불가피하게 사용할 경우, 주석으로 표시하고 commit에 그 이유를 작성한다.
| 태그 이름 | 설명 |
|---|---|
| chore | 코드 수정, 내부 파일 수정 |
| feat | 새로운 기능 구현 |
| add | FEAT 이외의 부수적인 코드 추가, 라이브러리 추가, 새로운 파일 생성 |
| fix | 버그, 오류 해결 |
| style | 코드에 관련 없는 주석 달기, 줄바꿈 |
| docs | README나 WIKI 등의 문서 개정 |
Git Workflow
main → develop → feature_# / fix_#
feature, fix 이하 번호는 issue 번호에 맞게 생성
Issue 예시
/-------------------------
Feature/Fix Request
기능 설명 : 초대장을 보내줍니다.
To-Do List
* 난수 생성해서 초대코드 보내주기
-------------------------/
PR 예시
/-------------------------
Solved Issue
close/해결한 이슈의 링크
Motivation
* 초대장 생성 api 구현
Key Changes
* 난수 생성해서 초대코드 생성
To Reviewers
* 머지해주세요~~
-------------------------/
1. issue 생성
2. local - feature_# / fix_# 에서 각자 기능 작업
3. remote - feature_# / fix_# 에 Push
4. remote - develop 으로 PR
5. 코드 리뷰 후 Confirm 받고 remote - develop Merge
6. remote - develop 에 Merge 될 때 마다 모든 팀원 local - develop pull 받아 최신 상태 유지
| Branch Name | 설명 |
|---|---|
| main | 배포용 브랜치 |
| develop | 구현 완료 브랜치 |
| feature_/# | 이슈 별 기능 구현 브랜치 |
| fix_/# | 이슈 별 픽스 브랜치 |
