-
Notifications
You must be signed in to change notification settings - Fork 3
2020 11 17 데일리 스크럼
Kwon soon won edited this page Nov 17, 2020
·
1 revision
-
쓰레드와 이모지, n:n 관계 될것같은데 혹시 어떻게 없앨 수 있을까요? 유저와 채널도 n:n의 관계가 될 것 같다. saved item , n:n mysql 대신에 mongoDB가 더 편하려나..?
-
상태관리 redux,
mobx, recoil ..- 리덕스는 써보는것도 괜찮음.
- context api 써서 하는것도 많음.
-
아토믹 디자인에 관해
- 사용해도 좋다
- 이름을 길게 하더라도, 컴포넌트의 역할이 명확하게 구분되도록 명시하는게 좋다
- 어느정도 기준을 잡고 나누는게 좋을것 같습니다
-
기획서는 얼마나 작성하고 진행해야 할까요? 5주? 1주? 하루?
- 최소 1주일 단위.
- 일단위는 유연하지 못할 수 있다.
- 전체 계획을 정하고, 주단위로 어디까지 할건지.
- 일정이 너무 세세하면 힘들 수 있다.
- 보통 자기가 생각한 스펙, 이거 개발하는데 얼마나 걸리겠다. 쓰레드 3일 걸리겠다. 하면 x1.5 해서 생각하는 식으로.
-
ERD 완성시키기
-
도전과제 작성
-
기술 스택 fix
-
백로그
-
데모시나리오
-
기술 스택 정해지면, 기술 요구사항 (기획서) 자세하게 작성
-
백엔드 구현
-
api 명세 작성
- 현준 공동작업
- 깃헙 위키 회의한것들 정리해서 올렸고
- 이하 상동
- 없음.
- 그라운드룰 정하기
- 커밋, PR 컨벤션, 코딩 컨벤션 정하기
- 깃 브랜치 전략. 단순하게 master, dev, feature(origin), hotfix
- 배포가 master
- dev가 개발할때 사용
- upstream 포크 따서 dev로 pr 날리는 형태로 작업
- 전반적인 요구사항 분석
- 기술 스택. 백엔드 (express, mysql, orm X, passport Oauth, socket io)
- 프론트 (CRA? 안쓰는 쪽으로) -> 현업에서도 잘 안쓴다.
- custom이 어렵다.
- 리액트 버전 17? 괜찮다.
- styled-component
- 기능 정리
- 요구사항, DB 정리
- 프로젝트 세팅 진행. 가능하면
- 아직 없다.
- 현준님 말씀과 동일. 공통작업.
- DB N:N 관계 어떻게 처리해야 1:N으로 할수 있을까?
- 먼저 스키마를 짠 후에 제거할 수 있는걸 제거해나가는 방식으로 진행해 볼것.
- DB
우선순위 0. 로그인 => oauth 제외하기
- 채널 생성
- 실시간 채팅
- 쓰레드 내의 쓰레드들 구현 ------------------- 여기까지만 하면 모양은 나온다.
- 멘션 (+notification) ------------------- 여기까지 최소 스펙
- 타이핑 표시, 링크 썸네일
- 파일업로드
- 검색
- 이모지
- 실시간 마크다운 적용
- DM -> 채널의 변형
채널 실시간 채팅 방식
회원가입, 로그인시 Oauth 빼고, 이메일 인증 방식 넣어볼것. Oauth는 토큰 관리, 인증 등에서 이슈가 많이 생길 수 있을듯
실시간 마크다운은 오래 걸릴 task. 취사선택 하면 될듯. FE쪽에서 더 할게 많은 이슈!
검색은 하이라이팅 기능 등이 FE 쪽에서 들어갈 수 있다.