💻 기술 스택

---

🔑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 적용

👀 기술 스택 선정 이유

---

React

1. 컴포넌트 기반

• 컴포넌트 단위 관리가 가능하기 때문에 재사용성이 높고 유지보수에 용이합니다.

2. Virtual DOM

• Virtual DOM을 이용하기 때문에 메모리 누수가 줄고 수정 비용을 절감할 수 있습니다.

3. 지식공유

• 개발 생태계와 커뮤니티가 활성화되어 있어 문제상황에 대응하기 쉽습니다.

Vite

1. 서버 시작 속도

• 개발할 때 번들링을 하지 않고 ESM 방식을 사용하기 때문에 로컬 서버 구동 속도가 매우 빠릅니다.

2. 업데이트 속도

• HMR을 통해 애플리케이션을 다시 시작하지 않고도 변경된 컨텐츠만을 갱신할 수 있습니다.

Axios

1. Promise기반

• return을 promise 객체로 해주기 때문에 response 데이터를 다루기 쉽습니다.

2. 브라우저 호환성

• 크로스 브라우징 최적화로 브라우저(특히, 구형 브라우저)호환성이 좋습니다.

Recoil

1. 단순함

• 다른 전역상태관리(ex. Redux)에 비해 사용하기 간편하고, 이를 활용해 코드의 복잡도를 줄일 수 있습니다.

2. 비동기 처리

• 추가 라이브러리 없이 Recoil 자체만으로 비동기 처리를 해결 할 수 있습니다.

Node.js

1. Single-Thread의 non-blocking I/O 이벤트 기반

• Node.js는 단일 스레드(Single-Thread)의 논 블로킹(Non-blocking I/O) 이벤트 기 반 비동기 방식으로 처리되어 높은 처리 성능을 가지고 있습니다.

2. npm(node package manager)을 통한 다양한 모듈(패키지) 제공

• 내장 HTTP 서버 라이브러리를 포함하고 있어 웹 서버에서 아파치 등의 별도의 소프 트웨어 없이 동작하는 것이 가능하며 이를 통해 웹 서버의 동작에 있어 더 많은 통제 를 가능케 합니다.

3. 웹 개발 호환성

• Javascript 언어로 Front-end 뿐만 아니라 Back-end 개발 환경을 구성할 수 있기에 생산성이 높고 러닝 커브가 줄어듭니다.

4. 경량 및 효율성

• Node.js는 다른 웹 프레임워크에 비해 적은 리소스를 필요로 하는 가볍고 효율적인 프레임워크이므로 배포 및 관리가 더 쉽습니다.

TypeScript

1. 유형 안전성

• TypeScript는 JavaScript에 유형 안전성을 추가하여 런타임이 아닌 컴파일 타임에 오류를 잡는 데 도움이 됩니다. 이는 코드의 안정성과 유지 관리성을 향상시키는 데 도움이 될 수 있습니다.

2. 향상된 코드 가독성

• TypeScript의 강력한 유형 지정 및 명시적 유형 선언은 코드 가독성을 개선하고 이해 및 유지 관리를 더 쉽게 만드는 데 도움이 될 수 있습니다.

Docker

1. 일관성

• Docker는 응용 프로그램 환경이 서로 다른 시스템 간에 일관성을 유지하도록 하여 종속성 또는 구성의 차이로 인해 발생하는 문제를 방지합니다.

2. 효율성

• Docker를 사용하면 애플리케이션의 여러 구성 요소를 별도의 컨테이너로 격리하여 리소스 사용량을 줄이고 효율성을 높일 수 있습니다.

📍 Code Convention

---

변수명

1. Camel Case 사용

• lower Camel Case

2. 함수의 경우 동사+명사 사용

• ex) getInformation()

3. flag로 사용 되는 변수는 조동사 + flag 종류로 구성

• ex) isNum

4. 약어는 되도록 사용하지 않는다.

• 부득이하게 약어가 필요하다고 판단되는 경우 팀원과 상의를 거친다.

주석

1. 한줄 주석은 // 를 사용한다.

// 한줄 주석일 때
/**
 * 여러줄
 * 주석일 때
 */

2. 함수에 대한 주석

/**
 * @route Method /Route
 * @desc Function Description
 * @access Public
 */

3. Bracket 사용 시 내부에 주석을 작성한다.

if (a == 5) {
  // 주석
}

Bracket

1. 한줄 if 문은 여러 줄로 작성한다.

// 한줄 if 문 - 여러 줄로 작성
if (trigger) {
  return;
}

2. 괄호는 한칸 띄우고 사용한다.

// 괄호 사용 한칸 띄우고 사용한다.
if (left == true) {
  return;
}

3. Bracket 양쪽 사이를 띄어서 사용한다.

const { userId } = request.user;

비동기 함수의 사용

1. async, await 함수 사용을 지향한다.
2. Promise 사용은 지양한다.
3. 다만 로직을 짜는 데 있어 promise를 불가피하게 사용할 경우, 주석으로 표시하고 commit에 그 이유를 작성한다.

📌 Commit Convention

---

[TAG] 메시지

태그 이름	설명
chore	코드 수정, 내부 파일 수정
feat	새로운 기능 구현
add	FEAT 이외의 부수적인 코드 추가, 라이브러리 추가, 새로운 파일 생성
fix	버그, 오류 해결
style	코드에 관련 없는 주석 달기, 줄바꿈
docs	README나 WIKI 등의 문서 개정

💻 Branch Strategy

---

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_/#	이슈 별 픽스 브랜치

📃 API Documentation

API명세서

⚙️ Software Architecture

---