[GROUP-MAKER] 시작은 미약하나 끝은 창대할 여정의 시작..

2022년 10월 8일 - 기획 회의 및 와이어프레임 작성

 

Notion: https://group-maker.notion.site/GROUP-MAKER-31fda201170345579a5228a842dfc643

GROUP-MAKER

GitHub: https://github.com/Group-Maker/Group_Maker

GitHub - Group-Maker/Group_Maker

 

 

요구사항

• 로그인 & 회원가입 기능
• 라우터 (option)

 

기획 의도

• 커넥투 활동을 하면서 필요했던 서비스가 있는가?
  • → HTML/CSS 발표, HTML/CSS 프로젝트, Git 실습, JavaScript 러버덕, JavaScript 페어 프로그래밍 등 무수히 많은 팀 프로젝트를 진행했는데, 그 때마다 새로운 조를 구성하는 것이 어려웠다. 따라서 최대한 많은 구성원이 기존의 조원들과 다시 만나는 횟수가 적도록 새로운 조를 구성해주는 웹사이트를 만들어보고자 한다.
• 페어프로그래밍을 통해 배운 것들을 어떻게 녹여낼 수 있는가?
  • Counter
  • Modal
  • Login & Signup
  • Drag & Drop
  • CBD Library

 

페이지 구성

https://www.figma.com/file/NPwLDo5x4FnrlXyEFTDpBJ/JoJJaJo?node-id=0%3A1 

Figma

• 인트로 페이지 (웹사이트 설명 및 게스트 or 로그인 선택) 
• 로그인 & 회원가입
  • 로그인 페이지
  • 회원가입 페이지
• 메인
  • 과거 데이터 확인 페이지(?) → 이름 결정 필요
  • 최적 조짜기 페이지
  • 수동 조짜기 페이지

 

회의 내용

• 인트로 페이지를 만들 것인가?
  • → 인트로 페이지에서 웹사이트에 대한 간단한 설명을 제공하자 
  • → 게스트로 웹사이트를 사용할지 로그인해서 웹사이트를 사용할 지 사용자가 결정할 수 있도록 하자
  • ⇒ 결론: GUEST/LOGIN 버튼이 있는 인트로 페이지를 만들자!
• GUEST 사용자의 데이터는 어떻게 처리할 것인가?
  • → 지난 기록을 기반으로 새로운 조를 구성해주는 웹사이트 특성상 지난 기록 저장이 필수
  • ⇒ 결론: GUEST 사용자의 데이터는 로컬스토리지에 저장하자!
• 공용 컴퓨터로 다수의 사용자가 웹사이트를 이용할 경우, 이전 사용자의 기록은 어떻게 처리할 것인가?
  • → 로컬스토리지를 사용하려면 감수할 수 밖에 없는 부분..
  • ⇒ 결론: 인트로 페이지 이후 보여지는 메인 페이지의 디폴트 메뉴를 ‘과거 데이터 확인(?) 페이지’로 하고, 초기화 버튼을 제공
• 멤버 목록을 보여주고 멤버를 추가/수정/삭제하는 ‘멤버 관리 페이지’와 지난 조 구성 목록을 보여주는 ‘지난 조 목록 페이지’를 분리할 것인가 합칠 것인가?
  • → 로컬 스토리지를 사용하기로 결정했기 때문에 데이터 초기화 버튼이 필요한데, 두 페이지 중 한 페이지에서 초기화 버튼을 클릭했을 때 다른 페이지에서 보여지는 데이터까지 한 번에 삭제되는 것이 사용자에게 혼란을 줄 수 있을것이라고 생각됨
  • ⇒ 결론: ‘멤버 관리 페이지’와 ‘지난 조 목록 페이지’를 ‘과거 데이터 확인(?) 페이지’로 합침
• 로그인 & 회원가입 기능 구현 정도?
  • → 배포시에는 제대로된 로그인 & 회원가입 기능을 구현해야겠지만, 최종 발표까지는 시간적 한계가 있으므로 요구사항의 범위에 맞는 정도로만 구현하고자 함.
  • → DB를 이용해 로그인 & 회원가입 기능을 완벽하게 구현해야 하는 것인지?
  • → DB를 이용해 로그인 시 아이디와 비밀번호가 매칭되는지, 회원가입 시 기존에 존재하는 아이디인지 정도만 확인하면 되는 것인지?
  • → DB 이용 없이 단순 유효성 체크만 하면 되는 것인지?
  • ⇒ 결론: 월요일에 요구사항 확인 후 결정
• 모달이 필요한 경우?
  • ‘회원가입 페이지’에서 회원가입 성공시
  • ‘과거 데이터 확인(?) 페이지’에서 멤버 삭제시 → 되돌릴 수 없는 작업임을 알림
  • ‘과거 데이터 확인(?) 페이지’에서 추가/수정된 멤버의 이름이 기존 멤버랑 중복될 시 → 중복된 이름임을 알리고 김ㅇㅇ2와 같은 새로운 이름 제안
  • ‘과거 데이터 확인(?) 페이지’에서 지난 기록 삭제시 → 되돌릴 수 없는 작업임을 알림
  • ‘최적 조짜기 페이지’에서 생성된 조 확정시 → 새로운 조를 추가로 생성할 것인지 생성된 조를 ‘과거 데이터 확인(?) 페이지’에서 확인할 것인지 결정하도록 함
  • ‘수동 조짜기 페이지’에서 생성된 조 확정시 → 새로운 조를 추가로 생성할 것인지 생성된 조를 ‘과거 데이터 확인(?) 페이지’에서 확인할 것인지 결정하도록 함
  • ⇒ 결론: 불필요한 모달은 사용자에게 거부감과 피로감을 주어 사용성을 해칠 수 있으므로 필수적인 경우를 제외하면 모달 사용을 자제할 것
• 최대 인원에 제한을 둘 것인가?
  • → 알고리즘의 성능을 확인해본 후 새로운 조 생성 속도에 영향을 미칠만한 인원수는 제한하기로 함 
  • → 지난 조 목록을 표시할 때에도 인원이 너무 많으면 곤란함
  • ⇒ 결론: 알고리즘 성능 확인 후 결정

 

 

협업 방식

• 매일 팀플 시작/종료 시간 정하기
  • 11:00 - 11:30 시작 회의 (매일 해야할 일 정리 및 짧은 회의)
  • 13:00 - 18:00 오후 팀플
  • 19:00 - 22:00 저녁 팀플
  • 22:00 - 23:00 마무리 회의
• 매일 회의록 및 회고 작성하기 → 미리 아이디어, 회의내용 기록해두기
• 밤에 잠 푹 자고 주어진 시간에 몰입하기
• 이슈는 그때 그때 작성, 반드시 이슈 선택 후 작업 시작!
• PR 올라오면 바로 코드 리뷰 하기 → 하던 일 있어도 반드시 하기!
• 서운한 점 생기면 바로바로 말하기
• 열심히 매운맛 비판하기, 비판 당하는 사람도 열심히 매운맛 변호하기 → 납득되는 순간 빠르게 인정하기!

출처: https://asana.com/ko/resources/collaboration-in-the-workplace

 

 

기획 발표 전까지 할 일

• 컨벤션 맞추기
  • Git 관련 컨벤션: branch, commit
  • 코딩 컨벤션: eslint, prettier
• 알고리즘 한계 측정
• 컴포넌트 구체적으로 분리
• 피그마 시안 만들기(가능하다면 인터랙션 처리까지)