-
Notifications
You must be signed in to change notification settings - Fork 0
11.7 월 회의록
Min-h-96 edited this page Nov 7, 2022
·
7 revisions
- 브랜치의 구분을 명확히 하기 위해서
-
main- 개발이 완료된 dev 브랜치를 merge 하여 배포 가능한 상태만을 관리하는 브랜치
-
dev- 개발이 진행되는 브랜치, 이 브랜치를 기반으로
feat,refactor등으로 파생됩니다. -
feat/[기능명][이슈번호(optional)]- 새로운 기능을 추가하고자 할 때, 사용하는 브랜치입니다.
-
refactor/[기능명][이슈번호(optional)]- 리팩토링이 이루어지는 브랜치입니다.
-
fix/[기능명][이슈번호(optional)]- 버그를 수정하기 위한 브랜치입니다.
-
design/[기능명][이슈번호(optional)]- 디자인 관련 작업을 하는 브랜치입니다.
- 개발이 진행되는 브랜치, 이 브랜치를 기반으로
-
camelCase- 일반적인 함수(hook 포함)
- 일반적인 변수
-
PascalCase- 컴포넌트 관련한 파일, 폴더, 명
- class 명
-
snake_case- DB
- 상수(영문 대문자 사용)
-
kebab-case- html 요소
- 배열의 이름은 복수형으로 만듭니다.
// 예시
- 반환 값이
boolean형인 함수나 변수는is또는has로 시작합니다. - 매직넘버 사용 금지(변수나 상수로 분리)
-
const는let보다 상단에 작성합니다. - 변수는 사용 시점에 선언 및 할당합니다.
- 선언과 할당을 동시에 하는 변수를 선언만 하는 변수보다 먼저 선언합니다.
- import 순서
- 외부모듈 -> 내부모듈 -> style -> assets 순서로 작성합니다.
// 예시- 선언 그룹 사이에 공백을 둡니다.
- 지윤이 가져다 쓰기
- 선언형 (
function foo() {})- Hook 등의 로직
- 유틸 함수 등, 통상적인 함수들
- 화살표 함수 (
foo = () ⇒ {})- 컴포넌트
- 콜백 함수
- 클래스 (
class Foo {})- 생성자로 인스턴스를 만들어야 할 때 (this가 필요할 때)
<Route path='/auth'>
<Route path='/github' />
<Route path='login' />
</Route>- 부모-자식 라우터가 생길 것을 고려하여 컴포넌트 형식으로 작성
-
createBrowserRouter을 사용하면 부모-자식간 상관관계가 직관적이지 않을 우려 있음?
-
- 제목은 확실히 적어줍니다.
- 본문은 optional.
# <타입>: <제목> (#1)
##### 제목은 최대 50 글자까지만 입력 ############## -> |
# 본문은 위에 작성
######## 본문은 한 줄에 최대 72 글자까지만 입력 ########################### -> |
# --- COMMIT END ---
# <타입> 리스트
# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# refactor: 리팩토링
# style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# docs : 문서 (문서 추가, 수정, 삭제)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (빌드 스크립트 수정 등)
# ------------------
# 타입은 영어로 작성하고 제목과 본문은 한글로 작성한다.
# 제목 끝에 마침표(.) 금지
# 제목과 본문을 한 줄 띄워 분리하기
# 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
# 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# 관련된 이슈번호는 제목 맨 뒤에 추가한다. ex. (#1)
# ------------------
- client
|- public
|- assets
|- images # png jpg
|- svgs # svg export
|- index.html
|- src
|- common # 공용 컴포넌트 (2개 이상의 페이지에서 같이 쓰임)
|- styles
|- colors.ts # 색상값
|- sizes.ts # border size, box size 등 사이즈 공용값
|- reset.css # 기본 스타일 리셋
|- hooks
|- utils
|- components
|- pages
|- TestPage1
|- TestComponent1 # TestPage1 에서만 사용되는 컴포넌트
|- TestComponent2
|- TestPage2
|- store # 전역 상태관리 상태값들 (redux dispatch 또는 recoil atom)
|- testState1
|- atoms.ts
|- selectors.ts
|- services # axios 또는 fetch 함수들
|- fetchTest.ts
|- types # 타입 값들
|- test.d.ts
|- api.ts # axios 를 쓰게 된다면 설정값
|- App.tsx # 일단은 라우터도 여기로
|- index.tsx # React가 읽어들이는 엔드포인트
|- prettierrc.json
|- eslintrc.json
|- tsconfig.json
|- package.json
|- .env
- server
|- app.ts
|- 도메인 별로 폴더
|- user // 예시
|- userController
|- userService
|- userRepository
|- utils
|- ...- 프론트와 백에 같은 언어를 사용함으로써, 기본적인 문법을 통일함으로써 더욱 원활한 소통을 할 수 있습니다.
- 코드 작성 시 매번 타입을 결정해야 하기 때문에 번거롭고 코드량이 증가하지만, 정적 타입 언어로 코드 작성 단계에서 에러를 체크할 수 있습니다. 이 장점으로 버그를 발견하고, 해결하는 시간을 단축시킬 수 있습니다.
-
any는 최대한 사용하지 않습니다.
- Plug'n'Play & ZipFS 을 이용한 의존성 관리
- Yarn Berry - Toss Tech
- 커뮤니티가 큽니다.
- Best practice 를 찾기가 쉽다고 생각합니다.
- 상용화된 라이브러리가 많습니다.
- Angular, Vue 와 달리 React 는 라이브러리기 때문에, JavaScript 언어를 알고 있다면 프론트엔드 지식이 부족해도 이해하기 수월합니다. -> 풀스택 작업이 더 수월해집니다.
- JSX 문법 덕분에 HTML 과 JS 코드 작성이 효율적입니다.
- Why use react
- HTML 태그를 직관적으로 인지하기 쉽습니다. 따라서 Semantic 하게 태그를 작성할 수 좋습니다.
- Javascript (또는 Typescript) 파일 내에 CSS를 작성할 수 있어 편리합니다
- 백엔드 서버를 구현하기 위한 기능이 Nest.js 프레임워크 자체에 포함되어 있습니다. -> 짧은 기간에 서버를 만들기 수월하다고 생각했습니다.
- Nest.js 는 구조가 정해져 있어서 협업을 진행할 때 일관성을 유지할 수 있습니다.
- 새로운 학습을 해야되서 시간적 손해가 있을 수 있지만, 공식 문서가 잘 정리되어있는 편이기 때문에 그 부분에 대한 부담을 해소할 수 있다고 생각합니다.
- Why use Nest.js
- Nest.js DOCS
- 기능을 정하고 정하는 걸로
- Gihub Action
- 배포하는 클라우드(ncloud vs firebase vs aws)
- 📃 기획서
- 📂 Backlog
- 📊 ERD, 폴더 구조
- 🗓️ 회의록