참고: 4F 회고

Fact : 무슨 일이 있었는지, 어떤 일을 했는지
Feeling : 어떤 감정을 느꼈는지
Finding : 어떤 지식과 인사이트를 얻게 됐는지
Future Action : 앞으로 무엇을 할 계획인지

Fact

: 무슨 일이 있었는지, 어떤 일을 했는지

좋은 테이블 구조란?

waiting - reservation 테이블 구조를 어떻게 짤까로 3번은 족히 바꾼 것 같다.
결론적으로 waiting이 reservation을 갖고있게했는데
덕분에 이 바꾸는 과정에서 근거가 매우 풍부해져서 오히려 좋다고 생각한다.

성능 최적화는 실제 이슈가 생기기 전까지 미루자

select 쿼리 몇개 더 나가는 게 보통 크게 문제되지 않는 경우가 많거든요. 
서비스 초반일수록 그 영향이 미미하고, lazy loading 을 도입하는 것이 
오히려 과한 최적화 작업일 수 있어요.

이미 findAll 같은 경우에 fetch join을 해오고있어서 
n+1과 같이 뻔하게 예상되는 성능 저하는 잘 피해가신 상황인데, 
별도로 lazy loading 하는 것이 필요한 최적화일지 한 번 생각해보셔도 좋겠네요 :)

리뷰어에게 피드백 받은 내용인데 쉽게 놓칠 수 있는 부분이라는 생각이 들었다.
쿼리, lazy loading 등을 계속 신경쓰다보니 자칫하면 오버할 수도 있다는 것!

놀면 뭐하니?

주말에 코치들이 놀면 뭐하니?라는 이름의 재밌는(?) 행사를 한다고 크루들을 모았다.
뭔지 모르고 가서 마주한 오늘의 미션은 바로 이것이었다.

Spring이 아닌 다른 낯선 프레임워크를 사용하여 방탈출 예약 관리 요구사항을 구현한다.

방탈출이나 보물 찾기 아니야~ 라고 기대에 부풀어 간 것과는 매우 다른 미션이었지만😇
그래도 새로운 프레임워크를 써본다는 것에 흥미로워하며 미션을 시작햇다.
나는 타칸, 다온과 3인 페어(!)를 시도해보았고, 프레임워크는 Spark를 선택했다.

느낀점

1. 왜이렇게 공식 문서 튜토리얼이 불친절하지?
2. 코치들이 만들어준 학습테스트가 없는 야생에서의 학습은 이런 형태려나? 내가 너무 편한 환경에서 학습 중인가?
3. 디버깅이 어려웠음, 로그가 복잡하고 불친절함
4. 새로운 건 항상 재밌다.
5. 고개를 들어 스프링이 해주던 감사한 일들을 다시 느껴보아라
   • 벨로시티 템플릿 엔진과 같이 뷰 리졸버를 따로 적용시켜줘야했다.
   • 오브젝트 매퍼로 객체를 받아오고, 객체를 보내야했음
   • 심지어 localDate, localTime도 자동변환 안됨

회고

스프링이 최고네~ 이런 생각만 했었는데 브라운과의 회고를 통해 느낀 점이 있었다.
어쩌면 레벨2에서 내부 구현을 생각 깊게 하지 말라는 이유를 느끼게 된 순간이었을지도 모른다.

우리가 스프링을 배우려고 한 게 아니라는 걸 다시 한 번 느끼게 되었다.
스프링의 뷰 리졸버를 사용하는 게 중요한 게 아니고 그걸 파는 게 중요한 게 아니라는 걸 역설적으로 느낀 것이다.

스프링의 뷰리졸버를 쓰는거, 그 세부 동작이 중요한 게 아니라,
스프링이든 스파크의 템플릿 엔진을 쓰든 중요한 건 웹 애플리케이션, 웹 프레임워크의 과정에서 이렇게 비즈니스 코드에서 뷰로 변환하는 무언가가 있구나를 아는 것이 중요한 것이다.

즉, 어느정도 학습을 해야하는지가 오히려 스프링에서 프레임워크 단으로 추상화된 느낌이었다.

1. 새로운 학습 방법을 찾는일.
2. 내부 구현을 세부적으로 알 필요가 없다고 하는 일.

레벨 2에 제안한 두가지 이 목표가 사실 연결되는 느낌을 받은 신선한 활동이었다!
신성한 주말의 2시간을 투자할만 했다😂

Feeling

: 어떤 감정을 느꼈는지

중반을 넘어선 시점, 레벨2 잘가고 있는지 돌아보기

→잘 가고있다.

그 이유는

1. 커리큘럼 키워드를 따라가면서 학습에서 파고들어야 하는 부분이 어딘지를 알면서 미션 구현, 리팩토링에 힘쓰기도 하고
2. 매주 새로운 걸 배우니 재밌다. 그 과정의 학습테스트 - 미션으로 이어지는 과정도 학습에 충분하다고 느껴진다.
3. 마음을 내려놓아서 편한 것도 있다. 내가 못하는 상태인 게 오히려 마인드적으로는 가벼워져서 무기인 느낌.
4. 조급함이 적어졌다. 미션이 느려도, 구조가 멋지지 않아도. 근거를 갖고있는 내 코드가 더 맘에 든다.

어느순간 리뷰어의 리뷰를 쳐낸다.

그 기준은 내가 잡는다는 느낌. 변화가 느껴진다!

Finding

: 어떤 지식과 인사이트를 얻게 됐는지

이번주에는 어떤 나만의 학습방법을 찾고 적용해보고 있을까?

해결이 안되면 어디까지 파야할까?

💡 문제 상황

member의 memberName이라는 필드에 대해서 null 검증을 하고 싶었는데
2가지 방법이 있었음. 근데 baeldung에서 1번을 권장했음.

1. @NotNull

• null 검증할 때 쿼리가 안날아감

2. nullable = false

• null 검증할 때 쿼리가 날아감

• String email은 ddl에 CREATE문에 not null 적용이 됐는데, @Embedded인 MemberName에는 not null 적용이 안됨

💡 결론

1. dto에서 검증하는데 엔티티에서 검증을 또 해야할까?

• 판단 기준
  • 만약 큰 프로젝트라 여러 개발자가 참여해서, 다른 곳에서 member에 대한 컨텍스트 없이 사용하는 경우가 생길 수 있다면
  • 돈관리처럼 철저한 검증이 필요하다면
• 결과
  • 아님, 더불어 db 들어갈 때 검증이 된다면 더더욱 필요없음.

💡 느낀점

이거 파는데 총 2시간은 걸린 것 같다.
사실 nullable = false로 처리하면 되는 건데,
@notNull이라는 스프링 의 어노테이션의 작동이 왜 안되는지를 파기위해 이정도의 리소스를 투자해야할까?
놀면뭐하니를 통해 느꼈지만, 그럴 필요가 없다.
가성비있는 공부를 위해 어느정도 파보고 나만의 결론을 내린 후 끝낸다.

해결한 결론을 내야할까?

실험을 해봤고 → (해결이 되지 않았어도) 각 상황별 현상을 확인했고 → 그래서 어떤 걸 쓸지, 이유를 만들었다 → 그게 결론이고, 판단의 근거가 된다! 충분!

빈틈이 채워지는 기분의 학습

영속성 컨텍스트와 lazy loading, identity type 등을 학습하면서 계속해서 헷갈리고, 주위에 물어보니까 민망하기도 했었다.
하지만 그때마다 완벽히 다 알겠다고 오버하지 않고 지금 필요한 정도만 학습하곤했다.
그리고 다음에 더 학습해야하는 상황을 만나면 다시 공부하고, 이렇게 점점 채워지는 느낌을 느끼며 학습했다.

그러다보니 더이상 불안하지 않았다. 내가 지금 다 이해하지 못하는 것도 괜찮다. 학습은 계속 이어지는 거니까!