로컬 스토리지
•
로그인 ⇒ 로컬 스토리지에 토큰
◦
그 외 페이지
•
회원가입 ⇒ 로컬 스토리지에 토큰(왜냐하면 회원가입 성공하면 로그인이 되는 형태인거 같아서)
◦
그 외 페이지
이런 구조이니까 협업을 통해 업무를 분담하려면 우선 로컬 스토리지 형태를 정해놓고 가는게 좋을거 같다. 그래야 로그인이나 회원가입이 덜 구현됐더라도 다른 페이지에서 데이터 받아와서 코드 짜는데 수월할거 같기 때문이다. 어차피 브라우저에서 직접 로컬 스토리지 설정해놓을 수 있으니까?!!
그리고 우리가 개발할 때 이용할 간단한 테스트 데이터가 있으면 좋겠다는 생각도 했다.
일단 포스트맨으로 유저 만들어놓고 토큰 공유해서 그거 기반으로 만들기
컴포넌트에 관해
어제 컴포넌트를 뭐로 나눌 수 있는지 생각해봤는데 뭔가 페이지 구분 없이 반복되는 컴포넌트인거 아니면 비슷 비슷한 페이지에서 반복되는 느낌이다. 그래서 반복되는 컴포넌트가 많이 모여있는 페이지를 찾은 다음에, 반복되는 컴포넌트를 정하고 그 하위 페이지를 각자 맡아서 하는 방식도 괜찮을거 같다.
예를 들어 로그인/회원가입/프로필 설정/상품 등록은 서로 공통되는 컴포넌트가 되게 많은데 이걸 몇 명이서 같이 컴포넌트를 정해놓고 각자 페이지 나눠서 하기? 공통되는 컴포넌트를 정할 때는 페어 프로그래밍도 좋을거 같다(수업 시간에, 방향1, 라이브 쉐어) 일단 공통되는 컴포넌트 정할 때 너무 완벽하게 하기보다는 그 컴포넌트 내에서 쓰일만한거 생각해서 HTML 마크업정도 짠 다음에 페이지 구현 맡으면서 컴포넌트 발전시키는 방향도 괜찮을거 같다..
최대한 데이터 흐름이 연결되는 방향으로 나누기. 로그인/이메일로 회원가입/회원가입 후 프로필 설정은 요청이 성공하면 로컬 스토리지에 데이터를 담는 역할을 할 것임. 이와 달리 로그인 후 프로필 설정과 add product는 로그인 된 상태에서 유저의 아이디를 가져와 뭔가를 하는 작업.
그리고 사실상 회원가입 후 프로필 설정은 회원가입 기능에 포함됨
•
로그인
•
회원가입(프로필 설정 포함)
•
상품 등록
•
로그인 후 프로필 수정
이런식으로 데이터 흐름과 요청 방식에 따라 나눠서 개발하는 방식도 괜찮을거 같다는 생각..?
이런식으로 하위페이지를 만들 때는, 우선 요청이 돼서 응답이 성공하는 정도로만 짜기. 그후 다른 페이지들과 연결하는 방식으로 해도 좋을거 같다. 어차피 응답이 성공하면 데이터가 수정되고 등록되고 삭제 되는등 할 테니까.
누리님
기능 정리, 정의
누리님의 경우 필수 기능 → 추가 기능
리드미에 필수 기능, 추가 기능 언급 x. 긍정적인 얘기만 쓰기..
업무 분담하기
페이지별, 기능별, 팀원의 역량별
중복 작업이 발생하지 않도록 고민하고 소통 많이 하기!
누리님 팀의 경우 주간 회의를 진행, 공통 페이지(로그인, 회원가입 ..)는 다 같이 진행. 어떤 분은 팔로워 리스트, 게시글 리스트. 페어 프로그래밍.
처음부터 완벽하게 업무 분담보다는 회의 및 피드백을 통해 방향을 계속 개선해나가는 거도 좋을거 같다.
코드 작성, 코드 리뷰, 수정 반복
주간 회의 안건은 대부분 20~30분 내로 짧게 끝내고 마지막에 코드에서 고민되는 부분을 나누는 시간을 가짐. 단순 효율의 문제면 같이 이야기해보다가 멘토님께 여쭤보고, 기능이 되지 않는 거는 같이 페어 프로그래밍 등등