일정 및 장소
, 20:00 ~ 22:00
참석자
모임 목표
관련링크
- 미로 - https://miro.com/app/board/o9J_kvwtm1Y=/
- LucidChart - https://www.lucidchart.com/invitations/accept/226cacf5-fa4f-44a9-a191-d7ef67dd3bf7
- git branch - https://github.com/slippStudy/franchise/tree/recruitmanage
활동
- 모임보다는 모집이 우선이다.
서비스를 이용하는 사용자는 다음 2가지로 유입될 가능성이 높다.
처음 사이트에 들어와서,
1. 모집 전체를 살펴보고 찾는다.
2. 관심있는 주제를 통해 모집을 찾는다.
- 특정링크를 통해 서비스에 유입되어 모임에 참여할 수 있다.
- SNS 등에 뿌릴 수 있다.(구글 스프레드시트 링크 공유와 유사)
- 누구나 Recruit 를 만들 수 있다.
마일스톤1 > m1
- 핵심로직은 심플해야 한다.
주요 내용.
1. Trello 가 아니라 Github Project 사용.
(식탁 낮은 곳에서) 책보면서 이야기했던 부분이 아래와 같습니다.
1. DDD에서 도식도를 통해 관계만 맵핑한다. 이때 Property나, Method는 명확하게 정의되지 않는다.
2. 사용자 스토리를 작성하고 작성된 사용자 스토리에서 Property나, Method, 식별자등을 선별한다.
3. 이를 바탕으로 클래스 다이어그램이나, 시퀀스 다이어그램등을 작성한다. (AC?)
2. 칸반보드 작성법?
- 기술적인 부분을 작성하는 것이 아니라, 구현해야되는 부분에 대해서 하나의 계약서와 같이 작성되어야 한다.
Ex) 예외 테스트 (x) -> UserID가 작성되지 않을 경우 400에러 반환(o) 등의 유즈 케이스 활용
3. Wiki에는 사용자 스토리를 작성한다.
- 무작위로 작성. 정제는 후에 진행된다.
4. 커밋 방식에 대한 논의
PR을 올렸으면 올린 PR이 중심이 되는 브랜치(ex, m1)에 로컬에서 머지함으로써 PR을 검증한다.
git clean -df
git checkout -b develop
git fetch upstream refs/pull/14/head
git merge --squash FETCH_HEAD
./gradlew clean test
코드가 변화된 부분 체크.
마지막으로 이상 없으면 PR > rebase and merge
-
Spec (Swagger) / Test code / Code
- 3박자가 일관성있게 유지
- 자신이 작성한 부분을 조리있게 설명할 수 있는가?
- 더 나은 코드, 읽기 좋은 코드가 될 수 있도록 가이드 되어야 한다.
테스트에도 2가지가 존재할 수 있음.
- Swagger로부터 나온 코드 Controller, MVC 에 대한 테스트 코드
- Unit 테스트 코드
controller test 에서 response에 대한 검증은 어떻게 하는게 좋을까에 대한 질문.
- response model 내부의 데이터에 대한 검증은 따로 테스트를 분리 해야한다.
- 집에오면서 생각해보니 ResponseBodyAdvice를 구현한 최종적으로 반환되는 response model의 구조는 request와 마찬가지로 같은 controller test 내에서 수행하는 게 맞는 것 같은데..
후기
Todo
다음 일정 및 장소
20:00 ~ , Online, Hangout