[ 목차 ]
1. 회의 안건
- ERD & 도메인 설계
- commit 컨벤션
- Repository 생성
- FE에서 비회원으로 사용하기도 추가하고 싶다고 했음
2. 회의 내용
- ERD & 도메인
- 설계 된 도메인 기준으로 Entity도 만들어 놓으면 좋을듯 ? 너무 이른가 ?
- commit 컨벤션
- 한글로만 적어서 보낼것인지 ?
- 한글 위주로 작성, 영어로 표현해야 하느 것은 영어로 표현
- feature 커밋은 간단하게 하고 머지때 자세하게 작성했었음
- PR, Issue 템플릿을 미리 작성
- Repository 생성
- API (?)
- 오늘 하는게 맞나요 ?
- 카테고리…?
- 기본 분류(Default Category) 삭제를 고려해서 테이블을 짤 거냐
- 기본 분류 삭제를 했을 때에, 유저별 카테고리 테이블에서도 해당 엔티티들이 삭제되어야 할 것이고, 그 카테고리를 가지고 있는 income, expenditure도 다 지워져야 함(FK 물려 있으니까)
- 엑셀로 기본 분류
- 실제 애플리케이션 기획자를 고려해서 excel로도 뺄거냐
- 초기화 기능 제공하느냐 안하느냐
- 카테고리 이름을 유니크로
- 카테고리(category)의 디폴트 여부 필드를 추가해서
- 지출에 카테고리 id 와 카테고리 이름을 둘다 가지고 있어서
- 해당 카테고리 id로 category_user에서 가져오고 이름을 해당 category_user 테이블의 이름을 따라가게 됨
- 만약, 가지고 있는 카테고리 id가 category_user에 없다면 해당 이름으로 통계를 냄
- 통계에서 같은 이름이지만 구분이 되게 나오는 것은 등록한 사용자에 따라 의미가 다를 수 있다.
- 한달전에 지웠던 ‘식비’가 오늘 등록한 ‘식비’가 다른 의미일 수 있다.
기능에 대한 이슈
- 주별 조회는 캐시로 남길 수 있을 것 같다.
- 주별 통계에서 미래에 대한 것을 보여줄 필요는 없을 것 같다.
- 현재 주 말고 이전 데이터는 캐시로 저장한다.
- 과거의 데이터는 수정할 일이 거의 없다.
- 월별 통계에서는 회원 가입한 날짜 이전의 데이터도 있었다
- 회원가입 날짜 이전에 데이터도 등록은 할 수 있다.
- key에다가 string을 등록해서 사용자마다 다른 캐시 데이터 제공이 가능할 것 같다.
- 캐싱이 필요할까 의문이다. 자주 접근하는게 아닌 것 같다.
- 통계 페이지에서 매번 API 날리니까 너무 오래 걸렸다. 이 때 Redis 캐시를 사용했다.
- 사실 주별, 월별 데이터에서 너무 오래 걸릴 것 같진 않다. 하지만 Redis를 도입한다면 재밌을 것 같다.
3. 결정사항
- ERD
- commit 컨벤션
- 한글로 명시적으로 하기.
- Repository 생성
- Merge 규칙 정하기
- 최소 리뷰어 지정
- 2명 지정 2명 approve (해보고 나중에 변경)
- Merge는 누가 할 것인지
- 개발 담당자가 직접
- Java 컨벤션 확정
- Naver 결정
- Jacoco 커버리지 몇으로 지정할 것인지
- 0으로 두고, 나중에 확정하기 → 예상 80