2023.10.10 ~ 2023.11.17 (약 7주)
📢 안녕하세요! 비틀비틀즈입니다.
| Backend | Backend | Frontend | Frontend | Frontend | Frontend |
|---|---|---|---|---|---|
 |
 |
 |
 |
 |
 |
| 임수형(팀장) | 박영서 | 김성용 | 김하늘 | 이정민 | 정현아 |
💡 프로젝트 명: Ziglog
목적: 지식그래프를 활용한 마크다운 노트 필기 웹 서비스
기대효과:
-
마크다운 문법을 이용한 지식 정리
-
참조 관계를 활용한 효율적인 지식 관리
-
폴더 관계를 활용한 효율적인 노트 관리
차별점:
-
노* : 폴더관계가 명확하지 않고 그래프를 이용한 탐색기능이 없음
-
옵시*언 : 로컬 서비스이고 다른 사용자의 노트를 확인할 수 없음
=> Ziglog: 웹 + 그래프 서비스를 제공
💡 로그인 및 회원가입:
- 소셜 로그인(Kakao, Google)
💡 그래프 탐색:
- 노트 기반 2D, 3D
- 폴더 기반 2D, 3D
💡 폴더 탐색기:
- 폴더와 노트를 탐색하는 사이드바
💡 검색:
- 공개 설정이 적용된 전체 노트 검색
- 사용자의 내 노트 탐색
💡 노트 생성 및 수정:
- 실시간 마크다운 문법을 변환해주는 에디터 제공
- 해당 노트를 참조하고 있는 노트를 북마크에서 선택할 수 있는 기능
💡 노트 읽기:
- 마크다운을 파싱한 화면 제공
💡 라이트모드/다크모드:
- 사용자의 눈을 보호하기 위한 밝기 변환 기능 제공
💡 알림:
- 타사용자가 내 글을 참조하거나, 북마크를 할 때 알림 기능 제공
💡 개인정보 수정:
- 사용자의 프로필 이미지, 닉네임을 수정하는 기능 제공
Language | Typescript
Framework | Next.js
Engine | Node.js
Package Manager | Yarn Berry
Library | Redux Toolkit, Tailwind CSS, Storybook, return-fetch, react-md-editor, react-force-graph
Language | Java 17
Framework | Spring Boot 3.1.4,
Spring Security | 6.1.4
Data | Spring Data JPA 3.1.4, Query DSL 5.0.0, Spring for Apache Kafka 3.0.11, Apache Kafka 3.4.1
Cache | Spring Data Redis 7.2.3
Build Tool | Gradle 8.3
Test | Junit 5.10.0
API Documentation | SpringDoc OpenAPI 2.1.0
Server | AWS EC2 t2.xlarge, Oracle Cloud Instance A1 Ampere
Infra | Nginx, Sonarqube, MobaXterm, Docker 24.0.7, Docker Compose V2 2.21.0, net-tools, iftop, openssh
DB | H2, MySQL 8.2.0, DBeaver
CI/CD | Git, Jenkins 2.426
프론트 프로젝트 구조
📦app
┣ 📂(pages)
┃ ┣ 📂oauth
┃ ┣ 📂search
┃ ┗ 📂user-page
┃ ┗ 📂[userNickname]
┃ ┣ 📂edit-note
┃ ┃ ┗ 📂[noteId]
┃ ┗ 📂read-note
┃ ┗ 📂[noteId]
┣ 📂api
┃ ┣ 📂bookmark
┃ ┣ 📂folder
┃ ┣ 📂graph
┃ ┣ 📂note
┃ ┣ 📂notification
┃ ┣ 📂quote
┃ ┣ 📂search
┃ ┗ 📂user
┣ 📂components
┃ ┣ 📂common
┃ ┣ 📂main
┃ ┣ 📂search
┃ ┗ 📂userPage
┃ ┣ 📂Notification
┃ ┣ 📂QuotationModal
┃ ┣ 📂Search
┃ ┗ 📂SideBar
┃ ┗ 📂Directory
┣ 📂src
┃ ┣ 📂design
┃ ┣ 📂fonts
┃ ┣ 📂hooks
┃ ┗ 📂util
┣ 📂store
┗ ┗ 📂modules
백엔드 프로젝트 구조
📦domain
┣ 📂bookmark
┃ ┣ 📂controller
┃ ┣ 📂dto
┃ ┃ ┣ 📂request
┃ ┃ ┗ 📂response
┃ ┣ 📂entity
┃ ┣ 📂exception
┃ ┃ ┗ 📂exceptions
┃ ┣ 📂repository
┃ ┗ 📂service
┣ 📂member
┃ ┣ 📂controller
┃ ┣ 📂dto
┃ ┃ ┣ 📂request
┃ ┃ ┗ 📂response
┃ ┣ 📂entity
┃ ┣ 📂exception
┃ ┃ ┗ 📂exceptions
┃ ┣ 📂repository
┃ ┗ 📂service
┣ 📂note
┃ ┣ 📂controller
┃ ┣ 📂dto
┃ ┃ ┣ 📂request
┃ ┃ ┃ ┣ 📂folder
┃ ┃ ┃ ┗ 📂note
┃ ┃ ┃ ┃ ┣ 📂quotation
┃ ┃ ┗ 📂response
┃ ┃ ┃ ┣ 📂folder
┃ ┃ ┃ ┣ 📂graph
┃ ┃ ┃ ┗ 📂note
┃ ┣ 📂entity
┃ ┣ 📂exception
┃ ┃ ┗ 📂exceptions
┃ ┣ 📂repository
┃ ┗ 📂service
┗ 📂notification
┃ ┣ 📂controller
┃ ┣ 📂dto
┃ ┣ 📂entity
┃ ┣ 📂exception
┃ ┃ ┗ 📂exceptions
┃ ┣ 📂repository
┃ ┗ 📂service
ERD
전체 문서
WIREFRAME
클릭하여 내용 표시/숨기기
- 매일 오전 9시, 오후 5시 2회에 걸쳐 **데일리 스크럼(Daily Scrum)**을 진행해, 개인별 당일 목표를 설정하고 진행 상황을 공유합니다.
- 매주 금요일 오후 5시에 **스프린트 세션(Sprint Session)**을 진행해 일주일간 프로젝트의 진행 상황 및 추후 진행 목표를 설정합니다.
- 데일리 스크럼과 스프린트 세션은 팀장이 회의를 주재하고, 다른 팀원들이 돌아가며 회의록을 작성합니다.
- 회의에 적극적으로 참여하고, 팀장의 지목에 따라 본인의 의견을 반드시 제시합니다.
- **코드 리뷰(Code Review)**는 점심시간을 활용해 필요한 부분만 간단히 30분 동안 진행합니다.
- 서로 다른 코드 스타일을 합의한 **코딩 컨벤션(Coding Convention)**에 따라 일원화합니다.
- 코드 리뷰는 우선순위에 따라 빠르게 진행하며, 사소한 의견을 반영할 지에 대한 부분은 코드 작성자가 선택할 수 있도록 합니다.
- 에러(Error)가 발생 시 1시간 정도는 혼자서 고민해보고, 해결이 되지 않을 경우 팀원들과 바로 공유합니다.
- 에러를 해결하기 위해 고민한 내용 및 해결 과정은 노션에 정리하여 공유합니다.
- 코드에 주석(Comment)을 작성하는 습관을 생활화하여, 다른 팀원들이 내가 작성한 코드를 이해하기 쉽도록 합니다.
- 기능의 구현 원리를 공부하고 파악하기 위해서 오픈 소스(Open Source) 라이브러리 사용을 최소화하는 것을 원칙으로 합니다.
- 풀리퀘스트(Pull Request)가 있을 경우, 이를 확인했다는 의미에서 최소한 1개 이상의 의견을 남겨야 합니다.
- 풀리퀘스트 시 의견 갈등이 생겼다면, 충분한 토론과 의견 수렴 과정을 거쳐 다수의 의견을 따라야 합니다.
- 커밋(Commit)하기 전에 고칠 부분을 한 번 더 점검합니다.
- 1가지 기능 또는 1가지 함수를 새로 만들 때마다 커밋하는 습관을 생활화합니다.
- **커밋 메시지(Commit Message)**는 합의한 **커밋 컨벤션(Commit Convention)**에 따라 최대한 상세하게 작성합니다.
- 깃 브랜치(Branch) 규칙에 따라 브랜치를 관리하고, 모든 작업은 올바른 브랜치에서 작업해야 합니다.
클릭하여 내용 표시/숨기기
type: [commit message] ex) feat: 로그인 기능 구현
- 전부 소문자로 작성합니다.
| Type | 설명 |
|---|---|
| feat: | 새로운 기능 추가 |
| fix: | 버그 수정 또는 타입 수정 |
| refactor: | 리팩토링 |
| design: | CSS 등 사용자 UI 디자인 변경 |
| comment: | 필요한 주석 추가 및 변경 |
| style: | 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 |
| test: | 테스트(테스트 코드 추가, 수정, 삭제, 비즈니스 로직에 변경이 없는 경우) |
| chore: | 위에 걸리지 않는 기타 변경사항(빌드 스크립트 수정, assets image, 패키지 매니저 등) |
| init: | 프로젝트 초기 생성 |
| rename: | 파일 혹은 폴더명 수정하거나 옮기는 경우 |
| remove: | 파일을 삭제하는 작업만 수행하는 경우 |
| infra: | ci/cd 및 시스템 또는 외부 종속성에 영향을 미치는 변경사항 (npm, gulp, yarn 레벨) |
| docs: | 문서 작업 |
git commit -m "feat: 회원가입 기능 추가"클릭하여 내용 표시/숨기기
바로 여기를 참고
Jira로 이슈 생성, 티켓 발급
→ 이슈의 경우 최대한 잘게 나누어서 되도록이면 한 번의 커밋으로 구현할 수 있게 해주세요
(여러 번 커밋해야 하는 거대 기능 하나를 두기보다는 여러 개로 쪼게 주세요)
→ 이슈를 기반으로 브랜치를 생성함
- master
- dev/be
dev/shc/feat/register-user-S09P21A204-9출처 브랜치/본인 이니셜/브랜치 종류/내용-지라코드
- dev/fe 브랜치에서 새로운 브랜치 생성하기
dev/khn/feat/register-user-S09P21A204-9
- dev/be
| Type | 설명 |
|---|---|
| feat: | 새로운 기능 추가 |
| fix: | 버그 수정 또는 타입 수정 |
| refactor: | 리팩토링 |
| design: | CSS 등 사용자 UI 디자인 변경 |
| comment: | 필요한 주석 추가 및 변경 |
| style: | 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 |
| test: | 테스트(테스트 코드 추가, 수정, 삭제, 비즈니스 로직에 변경이 없는 경우) |
| chore: | 위에 걸리지 않는 기타 변경사항(빌드 스크립트 수정, assets image, 패키지 매니저 등) |
| init: | 프로젝트 초기 생성 |
| rename: | 파일 혹은 폴더명 수정하거나 옮기는 경우 |
| remove: | 파일을 삭제하는 작업만 수행하는 경우 |
| infra: | ci/cd 및 시스템 또는 외부 종속성에 영향을 미치는 변경사항 (npm, gulp, yarn 레벨) |
| docs: | 문서 작업 |
클릭하여 내용 표시/숨기기
CODING CONVENTION
- 1문자의 이름은 사용하지 않는다.
- 네임스페이스, 오브젝트, 함수 그리고 인스턴스에는 camelCase를 사용한다
ex) camelCase - 클래스나 constructor에는 PascalCase를 사용한다.
ex) PascalCase - 약어 및 이니셜은 항상 모두 대문자이거나 모두 소문자여야 한다.
ex) NFT - 클래스명과 변수명은
명사 사용 - 메서드명은
동사 사용 - 상수명은 대문자를 사용하고, 단어와 단어 사이는 _로 연결한다.
- component는 PascalCase를 사용한다.
클릭하여 내용 표시/숨기기
JIRA CONVENTION
- 매주 월요일 오전 스크럼 회의 이후 각자의 이슈 티켓을 생성한다.
- 이슈 생성 시 확인해야 할 부분
- 담당자가 본인으로 설정되어 있는지
- 컴포넌트가 지정되어 있는지 (FE, BE, 공통 중 택1)
- Epic Link가 지정되어 있는지 (설계, FE개발, BE개발, 회의, 학습…)
- 스프린트의 총 Story Points가 40 이상인지
- 이슈 티켓 이름은 [말머리] 구체적인 기능으로 적는다.
- 기능 관련 이슈일 경우 [말머리]는 기능 명세서의 대분류를 따른다.
- 매일 오전 스크럼 회의 이후 그 날 처리할 이슈 티켓을 진행 중으로 이동시킨다.
- 실시간으로 이슈를 처리할 때마다 완료 처리한다.