1. 개요

1. 일시 및 장소 : 11.16.(수) 11:20 ~ 12:00, 13:30 ~ 16:00, 게더타운
2. 참여자 : 전원
3. 목적 : 2주차 구현을 위한 기능 분류 및 배정
4. 회의 중요도 : 중
5. 이번 주 페어
   • 상준 - 한빈
   • 윤우 - 현정

2. 논의

2.1. 이슈 크기

2.1.1. 이슈를 더 작게 나누는 방식

• 이슈를 더 작게 나누어야 각 페어가 FE, BE를 고르게 구현할 수 있음
• 기존의 이슈를 더 작은 단위로 나누고, 커밋을 더 작은 단위로 보내기
• 기존의 이슈에서 생각하지 못했던 부분을 고려하고 나누기는 해야 함
  • MongoDB 연결, 백엔드 연결 등의 중요한 내용이 빠져 있음

2.1.2. 이슈를 기존 크기로 유지하는 방식

• 굳이 하나의 기능을 세세하게 나눠서 구현해보지 않아도 FE, BE를 고르게 구현할 수 있음
  • 또한, 페어 간 코드 리뷰를 잘 해주면 충분히 서로의 코드를 이해할 수 있음
• 이슈를 지금보다 더 작게 나누고, 자주 업무를 교체하면 인터럽트 발생이 심해짐

2.1.3. 결론

• 우선, 페어 간 업무를 나눌 때 이슈를 기존 크기로 나눔
• 각 페어에서 이슈를 세분화하여 진행

2.2. 디렉토리 구조

1. styled component 파일 나눌 것인가
   • component와 style을 분리하면 코드의 가독성이 좋아짐
   • styled component는 css 파일과 다르게 지역적으로 스타일 코드를 관리하는 것이 장점임
   • 결론 : 우선은 style을 컴포넌트 파일에 작성
2. 컴포넌트 이름으로 폴더 만들 것인가?
   • 후에 확장성을 고려하여 컴포넌트 이름으로 폴더 생성
3. 디렉토리 초기 구조
   • server

routers
	ㄴauthRouter
controllers
	ㄴauthController
services
	ㄴauthService
repositories
models

• client

src
ㄴapis
ㄴutils
ㄴassets
ㄴcomponents
	ㄴComponent
		ㄴComponent.tsx
		ㄴ*Component.style.tsx
	ㄴNewComponent
ㄴconfig
ㄴ*atom (jotai)
ㄴ*action (jotai)
ㄴhooks
	ㄴuseHooks.ts
ㄴpages
	ㄴPage
		ㄴPage.tsx
		ㄴ*Page.style.tsx

2.3. 백엔드 라이브러리 교체?

2.3.1. koa

• koa는 미들웨어 기능만 있어 가벼운 것이 장점
  • 그런데 router 등 거의 필수적으로 필요한 기능들을 위해 다른 라이브러리가 필요함
• boilerplate로 복잡하게 구현하면 express, nest 대비 장점이 퇴색
• express 대비 참고 자료도 적음

2.3.2. express.js

• 특별한 이유 없이 새로운 라이브러리를 굳이 사용할 필요가 없음
  • 우리 팀원은 모두 FE를 지망하는데 BE에서 억지 변화가 필요한가?
• express를 더 공부하면서 BE 자체에 대해 이해하기 위한 노력이 필요함
• 자유도가 높음

2.3.3. nest.js

• Java의 spring boot와 유사한 boiler plates 방식
• 그러나 윤우를 제외한 다른 멤버들은 몰라서 학습 시간이 필요함

2.3.4. 결론

• express로 복귀하자!!

2.4. trouble shooting 기록 방법

• 노션
  • 내용을 상세하게 적을 수 있으며, 아카이브 역할을 함
  • 그러나 문제가 발생한 코드가 어디인지 헷갈릴 수 있음
• 깃허브
  • 요류가 발생한 코드의 위치, 해결 방안 등을 동시에 확인할 수 있음
  • 이슈 : 주로 사전에 구현할 기능을 정하는 용도로 사용하는데, 중간에 오류가 발생했다고 임의로 발행하면 헷갈리지 않을지?
  • PR : 오류의 내용과 해결 방안 등을 자세하게 적을 수 없음
• 결론
  • 우선 노션에 일자별로 trouble shooting 작성
  • 깃허브에서는 각자 이슈와 PR을 활용해보고 뭐가 더 좋은지 판단

2.5. 논의 방법에 대한 고민

• 우리는 하나의 문제에 대해 열심히 논의함
  • 각자 자신의 의견도 잘 제시하고, 상대방의 의견에 대해 적극적으로 피드백 함
• 그러나 필요 이상으로 논의에 시간을 써서 구현이 느려지는 경향이 있음
  • 회의가 정해 놓은 시간을 넘기거나, 쉬는 시간을 제대로 지키지 못하는 경우가 많음

3. 구현 목록

3.1. 지도 출력

• 네이버 지도 API 연결
• 지도 초기 화면을 서울 중심으로 출력

3.2. API 요청

• express 서버 연결
• 서울 실시간 도시 데이터 API 연결
• 주요 장소 50곳에 대한 인구밀도/위도/경도 정보 가져오기
• MongoDB 연결
• 데이터를 가공해서 DB에 저장하기(CRUD)

3.3. 핀

• 지역에 대한 구체적인 위도/경도 설정
  • (선택) 해당 지역을 테두리로 표시 (추후 논의)
• 지도에 50곳의 위도/경도 대한 핀 출력
• 인구밀도를 기반으로 핀의 색상 출력
• 핀 클릭 시 상세 정보 모달 출력
• 핀 클릭 시 핀의 크기를 키우고, 핀의 중앙에 현재 상태 표시
• 핀 클릭 시 핀이 화면 중앙으로 오도록 설정

3.4. 상세 정보 모달

• 현재 장소 상태 메시지 UI 출력
• 실시간 예상 인구수 UI 출력
• 북마크 버튼 UI 출력
• ‘내일 갈 거야’ 버튼 UI 출력

3.5. 분배

• A조(한빈, 상준)
  • 네이버 지도 API 연결
  • 지도 초기 화면을 서울 중심으로 출력
• B조(윤우, 현정)
  • express 서버 연결
  • 서울 실시간 도시 데이터 API 연결
  • 주요 장소 50곳에 대한 인구밀도/위도/경도 정보 가져오기