1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)
이번주차는 설계를 진행했기 때문에 프로젝트를 하면서 부딪힌 기술적인 문제는 없으나
멘토링과 리뷰를 통해서 얻은 키워드들은 있다.
- 보상 트랜젝션
- api가 실패했다면 어떻게 다시 실행을 해야 하는가? -> spring batch, spring-retry
- 주문시 pay, product 등 여러 도메인에 수정이 들어갈텐데, order를 제일 먼저 작업하는 이유: 트랜젝션 ID를 따기 위함.
=> 결제 중간에 실패하거나, 뭐 알수 없는 이유로 실패하면? 어? 어느 작업중이었지? 를 판단하는 기준. - api 응답코드. 422 코드는 처음 봤다.
- Optional과 throw Error. Optional의 안티패턴.
비즈니스로직에서 매번 같은 if (data == null) throw Error를 작성한다면?
그냥 인프라 레이어(DB 접근)에서 에러를 던져버리기. 그럼 비즈니스에서 직접 에러 처리가 필요한 경우가 있다면? 비즈니스에서 Optional로 넘겨주기.
이렇게 에러를 처리하는 위치에 따라 메소드를 분리하는 접근은 다른 방면에서도 유용하게 쓸 수 있을 듯. - 이미 만들어진 케이스를 보고 학습해보기. 개발자를 위한 레디스. 가상 면접 사례로 배우는 대규모 ~
- 현업에서 연관관계를 안 쓰는 경우가 있다. 데드락이 걸릴수도 있고, 요구사항이 계속하여 변경되기 때문. 데드락이 걸릴 조건은 뭔지 생각해보기
- 연관관계를 안 쓰는 이유처럼 DB에 enum도 안쓰는 경우가 있다.
- 정석적인 처리 방법은 없고 비즈니스에 따라 정해지는 문제가 많음
- 동시성 이해 과정 정리하기. synchronized -> lock -> 레디스 -> 분산락까지 이어지는 그 흐름.
- 상위 아이템 조회: 레디스 topK
- 토큰은 입장표처럼 생각하면 된다. 세션과 토큰은 다른 것. 토큰은 입장표 세션은 주문?? 토큰 내용 이해 필요.
- JPA에 id만 걸어두기 / 연관관계 없애버리기 (FK. OneToMany, ManyToOne) / JPA에서 엔티티 간접참조하기
2. 시도
질문을 정리했다.
질문을 하기 전에 챗지피티와 충분한 대화를 해보니 좋은 것 같다. 단순한 기술같은건 해결이 되고, 대화를 하다가 떠오르는 꼬리질문을 하다보면 단순히 기술에 대한 지식만으로 판별이 나지 않는 문제들이 나온다.
예를 들어 Optional로 던지기와 throw Error로 던지기.
"Optional.isPresent()로 하는거나 try {Optional.get()}catch(err) 하는거나 throw Error로 하는거나 뭐가 다른가?"
와 같이 지식으로 해결할 수 없는 경험이 필요한 문제들.
그런 경험을 나눌 수 있는 질문을 하는게 멘토링 시간을 유용하게 사용하는법같다.
그리고 꼬리질문을 꺼내주는 키워드들은... 까먹으니까 어디 적어놔야겠다.
3. 해결
멘토링을 했다.
4. 알게된 것
Keep : 현재 만족하고 계속 유지할 부분
이번 주를 마무리 하며 나에게 만족했던 부분은 무엇인가요?
Problem : 개선이 필요하다고 생각하는 문제점
이번 주를 마무리 하며 개선이 필요하다고 생각했던 문제점은 무엇인가요?
P1.
Try : 문제점을 해결하기 위해 시도해야 할 것
이 문제점을 해결하기 위해 다음 한 주간 시도 할 것은 무엇인가요?
P1.
사용 태그 #항해플러스 #항해99