07. 20

Default Value에 대한 처리

• 분류는 Default 값이 존재한다.

• 이 분류는 사용자가 커스텀 하여 추가, 수정, 삭제가 가능하다.

• Default 값이 필요한 경우
• 기본 유저 제공 값
• 분류를 초기화하는 경우

• 아니라면, 기획자가 엑셀로 저장한다 ?

비 로그인 인증방식

1. 가계부를 사용하는 동안 등록한 데이터가 유지되어야 한다.

2. 비회원 유저가 같은 조건(같은 기기? 또는 같은 ip)로 다시 접속했을 때 이전 정보를 불러올 수 있어야 한다.

• 찾아본건 쿠키

피드백

• 중간 테이블을 이용해 하라
• (1, 1), (1, 2), (user-id, category-id)
• 사용자마다, 카테고리마다의 통계를 뽑는 것도 편하게 되는 장점이 생긴다.

• array를 이용 (분류 id를 이용해 추가 삭제 하면 table을 재사용이 가능할 것 같다)

• user에 categories를 배열로 가지고 있는다.

• 배열로 하면 애플리케이션에서 따로 풀어야 함 (in query 사용)

• default category를 따로 분리할 필요는 없다.
• 현실세계와 맞지 않다.
• 객체지향에 맞지 않다.
• category 테이블에 모든 유저가 등록한 커스텀 카테고리를 포함한다.

• 카테고리에 default, custom을 구분하는 타입을 추가한다.
• 지금 생각해보니까 필드로 구분할 수 있는 것을 테이블로 설계한 것 같다.

• 수입과 지출은 분리해야한다.
• 중복이 많이 일어나지만 수입과 지출은 같지 않다.
• 수입과 지출의 다른 점을 찾아야한다.
• 객체지향적으로 생각을 해봐야한다.
• 재사용성만 생각하지말고 차이점을 생각해봐야한다.
• 데이터가 얼마나 많이 쌓일지도 고려해봐야한다.

• 우리는 DB에 종속적으로 생각하고 있다.
• 객체지향에서는 배열로 필드를 하는 것은 당연하다.
• 배열 뿐만 아니라 심지어 json도 저장이 가능하다.
 

• 비 로그인 인증 방식
• 프로젝트는 완성이 중요하다.
• 많은 기능 → 많은 고민 → 완성 못함 → 포폴로 못씀 → 쓰레기 행
• MVP 설정이 중요
• 데드라인은 무조건 맞춰야한다.
• 없다고 해서 서비스를 못 쓰진 않는다.
• 비 로그인은 나중에 만들자
• 이건 굉장히 많은 고민이 필요한 기능이다.
• ip는 위치(집, 카페 등)에 따라서 달라진다.
• 로그인이 되는지 먼저 확인하고, 수입-지출 등록이 잘 동작하는지 먼저 확인하고 그 다음에 고민할 것
• 쿠키를 사용하면 될 것 같지만, 시크릿 모드를 쓰면 없어진다.
• 거의 못 만든다.
• 데이터 유지가 안된다.
• 이거 말고도 추가 미션도 하면 비 로그인은 눈에 안 들어올 듯
• 스프링 배치로 하루하루 정산할 수 있는 기능을 만들 수도 있다.
• API를 제공해주는 것도 가능할지도
• 문자가 왔을 때 자동으로 등록 등등
• 후잉가계부 참고하도록
• 대시 보드
• 월별 추이
 

• OAuth 회원 탈퇴할 때 연결 끊어지도록 API 쏴줘야 함(Authorization Server쪽으로)
• OAuth는 최소한으로
• 카카오, 구글 둘 중에 하나
• 구글이 더 좋음
 

• Jacoco 커버리지는 처음부터 설정
• 필요 없는 부분은 exclude를 이용하세요~
• 테스트는 개발자를 위한 것, 기능은 사용자를 위한 것
• 정말 바쁘면 기능 먼저 머지할 수도 있다.