
지금 당신에게 필요한 책, <러북>
프로젝트 주제
- 여러 책의 인상깊은 문구를 먼저 보고 취향에 맞는 책을 고를 수 있는 도서 추천 서비스
개발동기 및 배경
- 우리는 보통 책을 검색할 때 책 제목을 검색한다. 하지만 어떤 내용의 책을 읽고는 싶지만 특정한 책을 고르기 힘들다면? <러북>은 유저들끼리 책의 ‘문구’를 통해 책을 소개한다.
- 사용자들은 문구를 통해 자신이 끌리는 책에 접근할 수 있게 된다. 그리고 책 소개 게시물을 통해 다른 사람들과 생각을 공유할 수도 있다. 그 과정에서 자신이 관심없던 분야에 흥미가 생길 수도 있고 평소 책을 가까이 하지 않았던 사람도 독서에 흥미가 생길 수도 있다.
- <러북>은 평소 책에 관심은 있지만 어떤 책을 읽으면 좋을지 모르던 사람, 다른 분야에 대한 책을 읽어보고 싶은 사람, 또 서로 흥미있는 분야에 대해 의미있는 대화를 나누어보고 싶은 사람들 모두에게 도움을 줄 수 있는 독서 커뮤니케이션 앱이 될 것이다.
주요 기능
- 책에서 인상깊은 문구를 추천하고 책을 소개하는 게시글을 작성할 수 있다.
- 책의 제목 뿐만 아니라 문구로 게시글을 검색 할 수 있다.
- 여러 게시글에서 좋아요, 댓글을 남길 수 있다.
- 카테고리(소설/시/기술)로 게시글의 성격을 구분할 수 있다.
- 내가 작성한 게시글 혹은 찜한 게시글을 볼 수 있다.
프로젝트 일정

🛠 기획
- 프로젝트 기획서
- 요구사항 명세
- git commit message
- 와이어 프레임 (figma)
- 기술 스택
- eslint/prettier
🪄 기술 스택
- 언어: JavaScript
- 라이브러리: React
- 상태관리: Context API
- UI 스타일링: emotion
- 협업툴: git, Notion, Slack
개발 전에 체크해야 할 사항
- 스크럼 보드에 진행 사항 공유
- issue에 할 일 올리기(ex) feat: button 컴포넌트 구현
- issue 명으로 branch 생성(ex) feature/#2_ButtonComponent
- 구현 시작
- develop으로 오후 7시까지 PR 올리기
- 리뷰(approve)를 받으면 Merge를 그 다음날 1시까지
pr/issue 컨벤션
PR과 issue
본인이 생각하는 가장 작은 단위로 Task를 설정합니다.
- 그 Task에 대해 (1)issue를 작성합니다.
- (2)작업을 진행한 후 (3)PR을 작성합니다.
- 다른 팀원들은 PR에 대해 (4)코드 리뷰를 합니다.
- 2명 이상의 다른 팀원이 approve 하면 해당 Task를 작업한 사람이 merge합니다.
(1) issue 작성법
이슈 제목은 타입/구현내용
으로 합니다. 타입은 커밋타입규칙과 동일합니다.
ex) 예를들어 모달 컴포넌트를 구현할 것이라면 이슈제목은 feat/modal 컴포넌트 구현
이 됩니다.
- 언제 시작할 것인지, 언제 끝낼 것인지 날짜를 작성합니다.
- 무엇을 작업할 것인지 명확하고 상세하게 작성합니다.
(2) 작업을 진행할 때는
브런치는 크게 main
- develop
- feature
나뉘어집니다.
- 반드시
feature/기능이름
브랜치를 생성하여 작업합니다.
- 작업을 진행한 이후 PR을 작성할 때는 반드시
develop
브런치에 merge합니다.
(3) PR 작성법
- 구현한 날짜를 포함합니다.
- 구현한 기능에 대해 상세히 설명합니다.
- 구현하면서 어려웠던 점이나 부족하다고 생각된 부분이 있다면 추가로 작성합니다.
무조건 만든 컴포넌트/디자인 캡쳐해서 같이 올리기
(4) 코드 리뷰
- 리뷰어는
approve
로 피드백 합니다.
💻진행 중
공통 컴포넌트부터 진행하기로 하였으며
내가 맡은 부분은 select, icon 부분이다.
기간은 2일이지만 하루 안에 만들어 리뷰를 받고 수정하여 merge할 예정이다.
다른 분들의 코드도 리뷰를 해드리고
후에 Header, banner 부분을 만드려고 한다.
🧐느낀 점
기획부터 아이디어 공유하고 서로 의견을 제시하며 기획하는게 재밌었고 초반엔 가끔 날카로워질때도 있었지만 그런 부분에 조심하기로 하여 이후로 큰 이슈없이 진행이 되었다. 이제 개발 초기 단계라 아직 많은 걸 만들고 있지 않고 초기 설정 후에 각자 개발하고
잘 진행이 되는지도 같이 테스트 해보는 단계라고 느끼고 있다.
빠르게 진행하고 싶지만 협업이다 보니 더욱 코드에 신경을 쓰게 되고 오타에 예민해지게 되어 오히려 좋다고 느낀다. 팀원분들이 질문에 잘 대답해주시고 적극적으로 참여하셔서 나도 같이 힘이난다.(하지만 앞으로 내가 구현을 잘할 수 있을지 걱정이 많다...)
데드라인부터 잘 지키자!!