[ About 📚ReadyBooks📚 ]

• 함께 책 읽을 준비되셨나요?
• ebook 서비스를 제공하는 사이트

구현 사항

• 소셜 로그인
• 상세페이지
• 메인페이지
• 장바구니

Demo video

ReadyBooks video link

Project Duration

• 2021/12/13~2021/12/23 (2주)

Team Members

• 프론트엔드 3명
• 백엔드 3명

[ Skills ]

Frontend

- React, React-Router, Style-components

Backend

- Python, Django, Docker, MySQL, AWS

[ Communication Tools ]

Git, Github

GitHub ReadyBooks

• 코드 관리

Slack

• 기본적인 소통
• Github 과 연결하여 github merge, PR 상태 확인

Notion

• slack에서 해당 부분을 찾기 위해 글들 속에서 헤엄치지 않아도 됨
• 모든 미팅 기록이 있어 좋음
• 미팅 전 사전 로그 작성하여 미팅 전 팀원들이 확인하여
• 해당 부분에 대해 먼저 생각하고 미팅에서 의견을 나누고 더 빨리 이해 할 수 있게 됨
• 프로젝트에 관련된 모든 문서를 저장
• 공통으로 정한 부분을 문서화해 해당 부분을 계속 확인하고
• 정해진 부분에 대해 다시 미팅하거나 해당 팀원에게 묻지 않아도 되기 때문에 업무의 효율성을 높임

Trello

• srum, 한주 sprint의 목표, 해야 할 부분을 보기 좋음
• 팀원들이 서로 다른 팀원의 진척도를 보고 자신이 할 일들의 우선순위를 조정할 수 있음

Gather town

https://www.gather.town/

• 온라인으로 만나야 할 경우 gather town 에서 만남
• 화면 공유로 같이 코드를 고민
• 회의실에서 회의를 진행
• 각자의 자리에서 작업을 하다 의논할 일이 있으면 팀원 자리에 가서 의논

[ What I did ]

소셜 로그인

카카오 소셜 로그인 구현
kakao developers 공식 문서
(블로그나 다른 사이트를 참고하지 않고 오직 공식 문서만을 이용해서 소셜 로그인을 구현)

[ 로그인 ]

• 팝업 방식으로 로그인 구현
• 카카오로 사이트 가입
• 필수사항 + 선택사항 로그인 시 기입
• 로그인 후 카카오에서 받은 카카오 토큰을 백엔드에게 전달
• 백엔드로부터 ReadyBooks 사이트 토큰 받아 local에 저장

[ 로그아웃 ]

• 카카오 토큰 만료
• 저장된 ReadyBooks 사이트 토큰 지우기

어려웠던 점

• 문서의 내용은 방대했고 내가 원하는 부분이 어디에 들어있지는 지 얼마만큼 봐야 하는지 감을 잡기가 어려웠다.
• 작성자가 어떤 의미에서 어느 부분에서 해당 부분을 사용하라는 의미인지 감을 잡기가 어려웠다.

당면했던 문제

• 공식 문서를 보고 로그인은 빨리 완성했는데,
  로그아웃 후 로그인을 하면 계속 로그인 팝업창이 뜨지 않고 자동 로그인이 되어
  다른 아이디로 로그인할 수 가 없었다.

해결 : 공식 사이트에는 없고 공식 사이트에서 첨부한 모든 API 참고 문서에 있었다.
(정말 모든 문서를 샅샅이 살펴봐야 하나보다...)

공식문서의 중요성

• 당연히 검색도 개발자의 역량인 만큼 중요하지만 관련 글이 많다는 것은 이미 해당 부분이 나온 지 오래됐다는 것
• 개발 분야는 업데이트가 끊임없이 이루어지기에 글이 많을수록 벌써 업데이트가 되었을 가능성이 있다.
• 업데이트가 작은 부분에서 이루어질 수도 있지만 내가 사용하려고 한 부분에서 이뤄져서 이미 다른 블로그나 사이트들의 내용이 적용되지 않을 수 있다.
• 블로그나 누군가가 정리한 친절한 글만을 보다 보면 공식 문서가 더 읽기 어려울 수 있다. 공식 문서를 더 많이 읽도록 하자!
• 공식 문서를 읽을 수 있다면 그 누구보다 더 정확하게 더 빠르게 해당 부분을 사용할 수 있다!

로그인 시 상단바

• 로그인이 성공적으로 완료되면 백엔드로부터 사용자의 nickname, 프로필 사진을 받음
• 프로필 사진을 누르면 사용자의 nickname이 표시되고 로그아웃 부분이 dropdown으로 나타냄
• 로그인 시 장바구니 페이지로 이동할 수 있는 장바구니 버튼 구현

상세페이지

구매에 따른 화면 구성 변화

• 구매에 따른 화면 구성을 위해서는 구매 여부를 알아야 했다.
• 구매 여부는 3가지 case 로 나눌 수 있었다.

1. 로그인하지 않았을 때 -> 무조건 구매 x
2. 로그인 o + 구매 이력이 o -> 구매 o
3. 로그인 o + 구매 이력 x -> 구매 x

• 이를 위해 로그인 시 header에 토큰을 주는 방법을 백엔드와 논의했다

1차 시도

• 백통신을 할 때 로그인되지 않아 토큰이 없으면 빈 string을 주는 방법을 생각했다

const Authorization = sessionStorage.getItem('Authorization') || '';
// ...
    fetch(`${API.book}/${bookId}`, {
      headers: {Authorization: Authorization},
    })

문제 : 백엔드에서 토큰이 없을 때 주어지는 빈 string을 처리하지 못했고 undefined, null을 하더라도 문제가 생겼다.
알고 보니 백엔드에서의 기본값으로 이 부분을 처리하려고 했는데 -> Authorization 라는 key 자체가 들어오지 않을 때 기본값이 사용되다 보니 빈값이라도 일단 키값이 들어오면 기본값으로 처리할 수 없었다. 그렇기에 빈칸으로 들어오던 undefined으로 들어오던 일단 if 문을 사용해 처리해야 했다. (3개의 과정을 더 거쳐야 한다고 했다.)

해결 방법 : 프론트단에서 처리해 주자!

2차 시도
방법 : spread 연산자를 이용해서 토큰이 없다면 키 자체를 주지 말자

const Authorization = sessionStorage.getItem('Authorization')
// ...
    fetch(`${API.book}/${bookId}`, {
      headers: {
        ...(Authorization && { Authorization: Authorization }),
      },
    })

[ 구매 전 ]

• 바로 구매하기 버튼 -> 클릭 시 바로 구매 됨
  [구매 버튼이 만들어지기까지의 과정]
  처음 기획 단계 -> 가격 부분과 구매 버튼은 따로 있었다.
  문제 -> 따로 있다 보니 UI 부분이 깔끔하게 떨어지지 않았다.
  해결 -> 구매하는 사람만 가격을 보면 됨, 구매할 때 가격을 찾게 됨, 구매 버튼에 가격을 넣으면 아래 미리 보기 부분과 길이가 비슷해짐 등을 고려해 보니 가격과 구매 버튼을 합치게 되었다.
  결론 -> 구매 버튼 안에 가격 넣기

• 장바구니 버튼 -> 장바구니에 추가됨

• 책 미리 보기 -> 5장까지만 보기 가능

• 리뷰 불가능

[ 구매 후 ]

• 책 보기 -> 책 전체 보기 가능
• 리뷰 추가 가능

PDF 읽기

• react-pdf 라이브러리 사용

어려웠던 점

• pdf를 보여주는 것은 처음
• 첫 라이브러리 사용

라이브러리 사용 시 고민해야 할 부분

[문제]

• 라이브러리는 내가 원하는 딱 그 부분만이 아닌 엄청 많은 부분을 가진 코드일 가능성이 많다 -> 프로그램이 무거워질 가능성이 높다

[해결 방법]

• 라이브러리 코드를 보고 내가 해당 부분을 참고해서 개발을 할 수 있으면 참고하는 방향으로 최대한 한다.
• 참고할 수가 없다면 동료 개발자들과 해당 라이브러리가 꼭 필요한지 토의를 해본다.
  -> 어쩌면 더 가벼운 라이브러리, 또는 다른 해결책이 존재할 수도 있으니 :)

리뷰

• 비 구매 시 리뷰 작성 불가 -> 상세 페이지에 대한 데이터를 백으로부터 받아 올 때 구매 여부를 받아 이를 기준으로 판단
• 리뷰 추가 시 별점 필수 -> 별점은 상세페이지 상단에 평점에 사용되고, 랭킹은 이 평점을 기준으로 만들어짐
• 리뷰 추가 후 리뷰 부분만 다시 백엔드에서 받아와 보여줌
• 리뷰 삭제 -> 작성자의 user_id와 사용자의 user_id 가 같다면 삭제 버튼이 옆에 생성되고 삭제 할 수 있음
• 리뷰 삭제 후 리뷰 부분만 다시 백엔드에서 받아와 보여줌

어려웠던 점

문제

• 처음에는 장바구니와 같다고 생각을 했다
  -> 렌더링을 최소화하기 위해 프론트에서 리뷰를 추가하고 백에게 이를 알리면 된다고 생각했다
  -> 그럴듯해 보였다. 하지만 문제는 삭제에서 생겼다
• 삭제를 review_id로 하는데 프론트에서 review_id를 만들어 백에게 전달하면 중복의 문제가 생길 수 있다.(난수로 하더라도 한쪽에서 관리하는 것이 맞다...)

깨닫게 된 부분

• 리뷰는 여러 사용자가 함께 사용하는 공간이다 (장바구니는 사용자 1명의 공간이다)
  -> 중간에 다른 사용자가 댓글을 추가했을 수도 있다 => 해당 부분을 업데이트해줘야 한다
  -> review_id는 백엔드에서 생성해야 복잡함이 덜하다
  -> 실시간 채팅까진 하지 않더라고 추가, 삭제 시 해당 부분은 업데이트해야 한다

• 백엔드 요청을 할 때 1번에 1가지 일만 하게 하자
  -> 리뷰 추가, 삭제를 맡는 부분에서 백엔드 통신을 백엔드와 함께 고민하며 추가, 삭제 후 리뷰 부분을 Get 요청해야 하는데 그냥 리뷰 삭제, 추가 요청의 response 로 업데이트된 리뷰를 주면 안 되냐 물어본 적이 있다.
  -> 결론 : 기능별로 요청을 나누어야 한다

[ 개발 ] 이번 프로젝트로 배운점

• 라이브러리를 사용할 때는 신중히 고민하고 코드 참고용으로도 고민해 보자
• 공식 문서를 읽는 연습을 더 하자
• 백엔드 API는 1번에 1가지 기능을 하는 것이 이상적임을 인지하자
• 백엔드와의 통신 중 key 값이 비게 될 경우 키 자체를 보내지 않게 하여 백엔드가 기본값을 사용할 수 있도록 하자
• 리렌더링이 일어나지 않게 하는 것도 중요하지만 일단 해당 부분이 리렌더링이 필요한지부터 고민하는 것이 먼저다!

[ 협업 ] 이번 프로젝트로 배운 점

이번 프로젝트는 모든 팀원들이 각자 하고 싶은 부분들이 있었고 각자 해야 하는 부분을 찾아서 했다.
이를 통해 팀장은 많은 부분을 챙기지 않아도 되었으며 각자의 부분을 더 열심히 하고 더 많은 의견을 나눌 수 있었다.

고민한 부분
팀장의 역할, 무게, 팀원에게 어떤 일들을 시키는 빈도는 어쩌면 팀장의 성향도 있겠지만 팀원의 성향에 따라 변할 수도 있지 않을까라는 생각을 했다.

다짐

• 내가 해야 할 부분을 알아서 찾는 팀원이 되어야겠다.
• 나의 역할을 먼저 정의해 보고 내가 할 수 있는 부분, 내가 해야할 부분을 최대한 팀 내에서 하도록 해야겠다.
• 팀장의 역할이 아닐 때에도 나무가 아닌 숲을 보도록 노력해야겠다.

프로젝트를 마치며...

이번 프로젝트는 즐거웠다. 힘들지 않았냐고 물으면 당연히 힘들었다고 말하겠지만 힘듦과 즐거움은 공존할 수 있다.
나는 매일 아침 위코드에 가서 팀원들과 토론하고 내가 해야 한 부분들은 고민하고 팀원들을 도와주고 이번 2주는 분명 이전 프로젝트에 비해 피곤도는 높았지만 즐거웠다. 언제나 최소한 여유 10%를 가지도록 노력했으며 이를 통해 바쁘더라도 도움을 요청하는 사람에게 20번에 19번은 더 여유롭게 도움을 줄 수 있는 여유도 생겼다. 이 여유는 같이 고민할 시간을 주어 사람들마다 다른 접근법을 알게도 했고 내가 모르는 부분을 알게 하는 좋은 기회도 되었다. 언제나 10%의 여유를 가지고 혼자만 책임을 지려고 하지 않고 다 같이를 많이 느낀 프로젝트였다.

프로젝트 log (+코드)

📚ReadyBooks?!📚 2주차 고민한 코드의 흔적들
📚ReadyBooks📚 댓글 구현하기
📚ReadyBooks📚 1주차 고민한 개발의 흔적들
[📚ReadyBooks📚] 2차 프로젝트 시작!