-
Notifications
You must be signed in to change notification settings - Fork 1
22.11.07.
leegwae edited this page Nov 7, 2022
·
1 revision
- README.md
- 프로젝트 소개, 위키 링크, 데모 링크, 주요 기능에 대한 소개, 기술 스택, 아키텍처, 그 외(우리가 공유할 만한 경험들), 팀원 소개
- 기획서
- Feature List
- 기능 요구사항 문서=제품 백로그
- 핵심 기술 요구사항
- API, ERD(모델링)
- 피그마(디자인, 프로토타입)
- 프론트-백엔드 구조(아키텍처)
- 기술 스택
- 전체 계획
- 스프린트 백로그(주차별)
- 팀 룰
- 코딩 컨벤션
- GitHub branch 전략
- GitHub commit 컨벤션
- GitHub Issue 컨벤션
- GitHub PR 컨벤션
- 데일리 스크럼
- 일일 회고
- 주차 회고
- 피어세션
- 멘토님과의 미팅
- 토론, 기술 논의(왜 그 기술을 선정했는가)
- 링크 모음
- 공유 발표자료
- 데모영상
- 우리가 디스코드 클론코딩인건 맞지만 무슨 컨셉인지 기획의도가없다.
- 야스니티가 커뮤니티를 나타내니까 어떤 커뮤니티인가에 대한걸 정하면 좋을 것 같다.
- 귤이니까 같이 앉아서 귤까먹으면서 이야기해요.. 이런거
- 리포지토리 생성
- 오늘 스크럼 기록
- 문서 템플릿 작성하기 템플릿 모음
- 그라운드 룰 정하기
- 팀 룰
-
코딩 컨벤션→ 개발환경 설정할 때 작성하기 - GitHub commit 컨벤션
- GitHub Contribution 컨벤션:
.github에 템플릿 만들것임- GitHub Issue 컨벤션
- GitHub PR 컨벤션
- GitHub branch 전략
-
1주차 스프린트 백로그-> 제품 백로그 완성 안했음 -
제품 백로그 (완성은 아닐수도)
- 너 왜 귤먹으러 안왔어? 👍👍 초대를 안해줬는 데 어떻게 가요?
- 같이 감귤 먹을래? 👍
- 같이 귤 까 먹을래?
- main: deploy
- dev: 개발
- fe
- be
- release가 배포 연동되어있는지
- 왜 main이랑 release 구분하는지? main은 태그만 달던데
https://techblog.woowahan.com/2553/
티켓, 백로그 → 이슈하나당 브랜치 하나 당 PR 하나
예) 모달을 만들자!
- main 브랜치 있음
- main으로부터 dev 브랜치를 판다.
- dev로부터 dev-frontend 브랜치를 판다.
- dev-frontend으로부터 feature/modal 브랜치를 판다.
- feature/modal 로부터 issue#1/loayout 브랜치를 판다.
- issue#1/loayout에서 만든다. 커밋한다. 푸쉬한다.
- feature/modal로 issue#1/loayout의 커밋에 대한 PR 날린다. 코드리뷰받는다. rebase로 머지 눌러준다.
- local과 remote에 있는 issue#1/loayout 브랜치 지운다.
- local origin 에 있는 feature/modal로 remote origin 에 있는 feature/modal의 최신 커밋(rebase merge된 커밋) 땡겨온다.
- local origin에 있는 feature/modal 개발 다 끝남.
- dev-frontend로 feature/modal 커밋에 대한 PR 날린다. 그냥 merge(아니면 커밋 줄이고 싶으면 squash)
- localorigin에 있는 dev-frontend로 remote origin에 있는 dev-frontend의 최신 커밋 땡겨온다.
- dev-frontend와 dev-backend 개발 완료
- dev로 dev-frontend, dev-backend PR보내고 확인받고 그냥 merge
- main로 dev PR보내고 확인받고 그냥 merge
근데 모노 레포라서 프론트랑 백엔드 릴리즈 브랜치 따로 파야하나?
- git-flow에 대해서 어떻게 이해하는지 공유
- git-flow에서 rebase와 squash 언제 사용하는지
- 프론트랑 백엔드 따로 배포하는 경우 릴리즈용 브랜치는 하나? 두 개?
- 코드 스플리팅
- 채팅 redis에 넣기?
- 인증 방식 결정하기(local이랑 oauth, 토큰이랑 세션)
- socket이랑 api 서버 분리할 것이므로 nest 각자 빌드해야함
-
제안사항
어떤 의사 결정을 내리거나 기술을 새로 배우면서 겪었던 문제들을 남겨두면 좋을 것같다.
왜냐면 이런걸 그때그때 적어두지 않으면, 시간이 지날수록 결과만 남고 과정이 흐릿해지기 때문
내가 학습 스프린트를 하면서 사용했던 예시 (사실 다른 것들은 더 짧게 썼는데 자세히 적지않아도 그 당시 사고의 흐름을 기록해두는 것이 목적)
-
처음 생각
- SPA를 저번에 써보지 않았으니,
SPA로 만들자. - 나는 SSR을 지향하니까
SSR로 만들면 되겠다!
- SPA를 저번에 써보지 않았으니,
-
문제 및 궁금증
- 근데 MVC 모델을 가지고 가면서 어떻게 만들지?
- Single page면 서버에서 어떻게 알아서 보내줄 수 있지?
- webpack까지 끼여있으니까, 번들은 어디에 생성해줘야하지?
- 라우터 별로 추상화를 해주어야할까?
-
학습 및 해결 과정
-
SPA는 대부분 SSR보다 CSR을 적용하여 많이 쓰니까 이번 프로젝트는
SPA+CSR로 결정 -
CSR의 경우
Model만 Server이고View,Controller는 Client에서 처리한다.- SSR, CSR을 찾아보다가 이 블로그의 그림을 보고 실마리를 잡았다.
-
webpack은 우선 dist에 다 모아두고 배포할때는 webpack 빌드를 따로 한 다음에 실행하도록 했다.
-
라우터 별 추상화
-
-
결론 및 생각
- SPA로 구현했다고 생각했으나, 사실 Header 검색바나 계정정보 같은 경우는 공통인데 엔트리 코드에서 만들어두고 article만 갈아끼우는 것이 더 좋은 방식인 것 같다 (두번 째 코드리뷰)
- CSR로 해보니, 또 SSR은 어떻게 해야하는 건지 잘 모르겠다..
- 처음 생각
- 상태가 변하면 rendering 다시하는게 전에 한거랑 동일한 이치아닌가?
- 일단 공부해보고 다시 생각하자.
- 문제 및 궁금증
- 이번 프로젝트에서 굳이 observer pattern을 적용해야하는 이유를 모르겠다.
- 학습 및 해결 과정
- 내가 의문을 가진 생각이 딱 있었고
중앙 집중식 저장소를 관리할 때 효과적이라는 말이 딱 있다. - 그렇다면, 이번 프로젝트의 SPA 에서 Home→Category→Home 이렇게 화면을 바꿔줄 때 마다 계속 데이터를 요청하면 Server에 부담이 들어서 쓴다고 새벽 3시 27분에 혼자 추론
- 내가 의문을 가진 생각이 딱 있었고
- 결론 및 생각
- 다음날 일어나서 생각하고 조원들과 토론 한 내용
-
Component Level의 상태 관리
- component level 상태 관리의 경우 하위 component가 증가하게 되면, 해당 상태를 조상이 받아오기 위해서는많은 callback이 이루어져야하기 때문에 번거롭다.
- Observer pattern을 사용한다면 중앙 집중식 저장소로 관리하기때문에 훨씬 용이하다.
-
Observer? Pub-Sub?
- Observer는 1:N의 관계, Pub-Sub는 M:N의 관계를 가진다.
- 그러나 보통 observer pattern을 쓴다고 하면 중앙 관리자가 상태 관리를 해준다는 super-set의 의미로 사용한다.
-
Component Level의 상태 관리
- 다음날 일어나서 생각하고 조원들과 토론 한 내용
- 기획서
- Figma
- Architecture
- Skill Spec
- API
- Database ERD
-
Tech discussion and sharing