• 코드 컨벤션

  • FE
  • BE

• 깃플로우 전략

  • FE
  • BE

• 기술 스택

  • FE
  • BE
  • Schema (mysql을 쓸 거라면 ERD까지)
  • API 컨벤션

• 이번 주 한 일

  • 팀 전체
    • 아이디어 선정 & 유저플로우 분석
    • API 기능 명세서
    • ERD 설계
    • MVP 구현 범위 설정
    • 와이어프레임
    • 일정 관리 : jira 도입 및 github 리포지토리와 연동
    • 코드 convention 정리
  • 팀원별
    • 송두용
    • 유하정
    • 천옥수
    • 최산하
    • 강성지
    • 이예진

💪🏻 프로젝트 별 강점 5가지

• 소셜로그인

• 메인 페이지 meetings 조회 관련 기능

• 모바일 UI

• Web Socket

• CI/CD 환경을 통한 배포 자동화 → 개발에 집중

• 기술적 질문

  <aside> 📍 1. 메인 페이지 meetings 조회 관련 정책

  </aside>

  • 지도 상에 개설된 모임의 마커를 표시하기 위해 모임을 조회하는 기준을 정했습니다.
  • 어떤 선택지가 있었는지?
    • 1안 : 화면상 지도의 양 꼭지점의 x,y 좌표를 서버로 전송해 지도의 범위 내에 해당하는 모임을 동적으로 표시한다. 단점 : 유저는 현재 위치한 지도상에서의 모임만 확인할 수 있다. 화면에 나타난 지도의 위치와 유저의 필터와 일치하지 않을 경우, 유저에게 혼란을 줄 수 있다.
    • 2안 : 유저가 지역구, 기술스택, 경력 필터를 기준으로 지도에 모임을 표시한다. 장점 : 유저는 본인이 위치한 지도 내의 범위가 아닌 보고 싶은 지역구 단위로 모임을 확인할 수 있어유저 편의성이 높아진다. 단점 : 지역구 단위(한국 전체)을 폭넓은 지역구를 선택하거나, 등록된 data 가 많을 경우 클라이언트에 부담을 줄 수 있다.
  • 그래서 어떤 기술을 선택했는지?

    • 2안 : 유저가 지역구를 직접 선택한 권역의 모임만을 지도에 표시하는 경우가 더 많을 것이라고 판단. 지도 상에서 드래그로 지역을 움직이는 것은 유저 친화적이지 않다고 의견

      1. 모임 등록 - 주소 입력 시 주소, 위도, 경도, 권역 정보를 받아온다.

      2. 모임 조회 - default로 특정 지역(예: 서울 전체)이 선택된 상태에서의 모임 리스트를 보여줌, 지도는 움직이거나 줌할 수 있으나, 지도 위치에 따라 다시 모임리스트를 조회하지는 않는다.

      3. 모임 조회(지역구 필터 적용 시) - 해당 지역구에 포함된 모임 리스트를 다시 조회해 보여준다. 기술스택, 경력 필터 또한 지역구 필터와 마찬가지로 적용된다.

  <aside> 📍 2. 메인 페이지 meetings의 UI

  </aside>

  • 메인 페이지에서 현재 참여할 수 있는 모임을 카드 형태로 확인할 수 있습니다.
  • 전체 뷰의 크기를 모바일 화면에 적합하도록 구성하다보니, 한 번에 보여 줄 수 있는 카드의 갯수가 한정적입니다.
    • 선택1: 카드를 위아래로 스크롤해 보여줍니다. 이 경우 카드 형태의 디자인을 포기해야 합니다.
    • 선택2: 카드를 좌우로 스크롤해 보여줍니다. 이 경우 가로 스크롤이 익숙하지 않은 유저에게 취약할 것 같습니다.
    • 선택3: 카드를 좌우로 넘기는 캐러셀 형태로 보여줍니다. 이 경우 카드가 많을 때 클릭을 자주 해야하므로 유저 경험이 좋지 않다고 판단했습니다.
  • 선택1과 선택2를 두고 어떤 방식이 더 좋은 방식일지 고민하고 있습니다.

  <aside> 📍 3. 유저 정보 데이터 상태 관리

  </aside>

  • 유저 로그인 시 서버로부터 토큰을 받아와 세션/쿠키 등의 브라우저 저장소에 저장합니다.
  • 토큰을 서버로 전송해 해당 유저의 정보를 받아옵니다.
    1. 유저정보를 로컬 스토리지에 저장해 필요한 기능 구현 시 가져와 사용하는 방법
    2. 필요한 기능 구현 시 서버로 토큰을 보내 유저 정보를 받아와 사용하는 방법
    3. 최초 로그인 시 받아온 유저 정보를 전역으로 관리하고, 새로고침 등 상태가 초기화되는 경우 토큰을 다시 보내 유저정보를 받아오는 방법
  • 세 가지 방법을 생각했습니다.
    1. 유저정보를 로컬 스토리지에 저장할 경우 서버와 통신하는 횟수를 줄일 수 있지만, 보안 상 좋지 않을 수 있다는 단점을 알았습니다.
    2. 필요할 때 서버로 토큰을 보내 유저 정보를 받아오는 경우, 서버와의 통신 횟수를 최소화하기 위해 리액트 쿼리를 사용하고자 합니다. 이 경우 발생할 수 있는 문제가 있을지 궁금합니다.
    3. 2번 방법에 문제가 있다면, 3번 방법을 사용하고자 합니다.

  <aside> 📍 4. 다대다 엔티티 관리

  </aside>

  • 각 모임(Meeting)에는 tag 형식으로 모임에 관련된 기술 스택(SKill), 연차(Career) 를 다중 선택할 수 있게끔 구현했습니다.
  • 어떤 선택지가 있었는지?

    • 1안 : Skill, Career DB 로 관리, meeting 과의 연관관계 생성하는 법 meeting : Skill, Career 와의 관계는 다대다 테이블로 관리하고, 매핑하는 테이블을 개설합니다.

       장점: DB 에서 마스터 데이터를 관리하기 때문에, 데이터 변경 시에 유지보수가 용이합니다.
      
       단점: Skill (최대 10항목), Career(4항목) 인데, 1개의 meeting 의 매핑 관계를 관리하기 위해 최대 14개의 row 가 필요합니다. 
      

    • 2안 : Skill, Career 를 DB 로 관리, 그러나 Meeting 과의 연관관계를 생성하지 않습니다. Meeting - SkillIdList 항목으로 선택된 ID 의 리스트로 관리합니다. SkillId 로 조회하여 DB 에 조회하여 전달해줍니다. 장점 : 매핑 테이블을 관리할 필요가 없습니다. 단점 : Skill, Career Data 변경시에 유지보수가 어렵습니다.

  • 그래서 어떤 기술을 선택했는지?
    • 1안 : Skill, Career DB 로 관리, meeting 과의 연관관계 생성하는 법 meeting : Skill, Career 와의 관계는 다대다 테이블로 관리하고, 매핑하는 테이블을 개설합니다. 안전한 방법이라는 판단이 들어서 1안으로 선택했습니다. 하지만 JOIN 을 하기에는 Skill, Career 의 테이블이 너무 작고, data 의 변경 사항이 많이 없을 것 같아서 고민입니다.

• 숙제 : 멘토링 결과 다음 주까지 해올 일

  • 팀 전체

  • 팀원 개인별로 작성해 주세요.
    • 송두용
    • 유하정
    • 천옥수
    • 최산하
    • 강성지
    • 이예진