궤도
[Spring] [면적면적[16]] 회고라기엔...뭣하고 중간점검 본문
끝난 것 같지만 끝난 프로젝트가 아니라구요~!
내가 스프링 마스터가 될 때까지 넌 나와 함께하는거야
(면적면적 프로젝트가 끝났을 때, 때는 2398년이었다)
내가 언젠가 까먹을 수 있으니 뭔가 찝찝한걸 적어두자!
1. 보낼게 없을 때 http status 204를 보내는게 맞나? 200대니까 성공은 맞는데 이걸 흔히 쓰는게 맞나..? 어디선 post나 delete 성공했을 때나 보내라는데 난 너무 남발한 것 같다.
-> 204는 delete나 put에서 변경된게 없을 때 쓰고 나머지는 200으로 바꾸기
2. MapStruct 이거 써도 되나? QueryDSL은 워낙 많이들 썼고 나도 쓰면서 어려움이 없었는데...얜 쓰면서 갑자기 뭐 dto를 인식 못한다거나 그랬는데...롬복이랑 같이 쓸 때 문제 생기는 이슈도 있었고...내가 잘 못쓴건지 아니면 아직 안정적이지 않은걸 쓴건지 모르겠다.
-> 일단 관련 이슈를 좀 더 찾아보고, MapStruct를 쓰지 않아도 가독성 좋게 매핑할 방법을 생각해보자!
3. 책 두께를 칼럼으로 넣은게 잘한 일인가? 이건 마지막 리패토링 때 변경한건데...일단 책 데이터를 정말 많이 넣어봐야 알 것 같긴하다...근데 암튼 잘한 짓인지 모르겠음. 데이터의 일부를 변경할 때 쓰는 patch 같은게 있는걸로 봐선 괜찮나? 아니 근데 데이터가 이렇게 자주 바뀌어도 되나 싶어서...4. 테스트 유저를 만든건 잘한 일인가? 뭔가 아닌 것 같으면서도 테스트 유저가 없으면 그 많은걸 어떻게 테스트하나 싶기도 하면서...유닛 테스트를 제대로 하면 문제가 없으려나? 그치만 통합 테스트도 하긴 해야 할텐데 이건 정말 알 수 없다.
-> 테스트 유저를 빡세게 관리하자 어떤게 들어있는지 기록해둬야지
: 해결 중 https://myunji.tistory.com/6595. Cors 에러. 이건 진짜 수정해야 한다. 이 상태에서 발전하지 못했다. 이거 때문에 프론트를 좀 공부하려고 했던건데 시간이 문제지 항상...
-> 귀찮다고 *을 하는게 아니었다...!
-> 이걸로 테스트 해보자 그래 뭔가 있을 줄 알았어...! https://www.popit.kr/curl-%EB%AA%85%EB%A0%B9%EC%96%B4%EB%A1%9C-%ED%95%98%EB%8A%94-%EC%B4%88%EA%B0%84%EB%8B%A8-cors-%ED%85%8C%EC%8A%A4%ED%8A%B8/
: 해결 https://myunji.tistory.com/515
6. 양방향 매핑 괜찮은거 맞나? 일단 자주 참조하는 것에 대해선 다 해놓았는데 join이 더 나을 수도 있을까..? 이것도 성능 테스트를 해봐야 하는 문제다.
-> join 쿼리를 많이 써보기도 해야하니 수정하자!
7. 스트림 남발 괜찮나? 이건 내가 저번에 보기론 stream보다 join 쿼리 날리는게 더 빠르다고 한 것 같은데 그럼 이건 6번이랑 연결돼서 양방향 매핑을 포기할 사유가 된다.
-> N+1을 좀 더 공부해보자 그래도 그때보단 뭔가 머리에 채워진게 있으니까!
-> N+1에 대해 더 알아봤다. 흠 처음봤을 땐 뭔소리지 했는데 이젠 좀 뭔지 알 것 같다. 근데 페지 조인 방식을 권장하는 것 같은데, 일대다일 때 중복된 결과가 나타날 수 있으니 distinct를 사용하라고 한다. 근데 SQL 튜닝에 대한 글을 읽었을 때 distinct는 성능에 좋지 않으니 쓰지 말라고 했었는데??? 흠 이 문제를 실제로 해결할 때 어떤 방법을 쓰는지 좀 더 알아봐야겠다.
8. Book 도메인 관련...이거 뭔가 추상클래스로 하거나 아무튼 최적화 할 수 있는 방법이 있지 않을까...지금은 모든 상태를 하나에 저장해서 뭔가 불안정한 느낌이다.
9. access token 만료되면 널포인트익셉션 띄우는거. 원래 이게 아니었던 것 같은데...다른 익셉션으로 기억하는데 왜 이제 널포인터인지 알 수 없다. 프론트가 관리한다고는 하지만 오류가능성이 없진 않을텐
->비슷한 키워드로 좀 더 찾아보자 https://jydlove.tistory.com/65
10. transactional 어노테이션 쓸때 모든 익셉션 발생에 대해 roll back 하는 옵션이 있단걸 알게됐다. 내가 책 추가하고 캐릭터 추가하는 과정에서 초반에 캐릭터 db에 값을 채우지 않아 발생한 예외를 그냥 자바 코드 순서로 rollback 처리했는데 이 옵션을 줘서 확실히 명시하는게 좋겠다
-> 오호 난 정말 모르는게 많구만 검색해보니까 관련 글이 굉장히 많다. 일단 이 어노테이션이 어떻게 트랜잭션을 수행하는건지 제대로 알아보자
-> https://www.podo-dev.com/blogs/133?search=aop
다른거 검색하다 이런 글을 발견했다. 지금 읽어보는 중인데 여러번 읽어보는게 좋으니까 기록용
-> 와 일단 이해는 별로 못했는데 충격적인 사실을 하나 발견했다.
와 그래서 pk값이 그렇게 중구난방으로 커졌던건가?? 근데 내가 그렇게 테스트를 많이 돌렸었나...?
어쩐지 테스트에는 휘발성 DB같은거 써도 좋다고 하셨는데 다 이유가 있었구나. 이것도 할 일에 넣어야겠다.
: 해결 https://myunji.tistory.com/659
그나저나 일단 내용이 이해가 잘 안되는데 예시 코드를 더 찾아봐야겠군
-> 음...내가 처음에 이걸 굳이 왜..? 라고 생각했던 부분이 트랜잭션이 설정된 메서드가 트랜잭션이 설정된 또 다른 메서드를 호출한다는 부분이었다. 그래서 밥먹으면서 이런 경우가 뭐가 있지 생각해봤는데...
지금 면적면적에서 책 추가/수정/삭제하면 상태에 따라 캐릭터가 갱신된다. 근데 난 지금 갱신 여부를 다른 메서드에서 받아와서..? 한 번에 반영하는데 이걸 분리하는걸까?
그니까 책 추가/삭제/수정 따로 하고 경우에 따라서 그 안에서 캐릭터를 추가/삭제하는 메서드를 호출하면...이게 맞는 것 같기도 하고...그럼 이게 어떻게 보면 둘 이상의 트랜잭션이 실행되는거니까 격리 수준으로도 이어지는건가? 암튼...잘은 모르겠지만 이것도 해봐야겠다.
11. DTO...너무 지저분하지 않나..? 솔직히 뭐가 뭔지 나도 모르겠는데 이렇게 관리하는게 맞나싶다
12. 로그인 여부로 페이지 접근 권한 만들어 제발
-> https://employee.tistory.com/entry/Spring-Boot-Security-%EC%A0%91%EA%B7%BC-%EC%A0%9C%EC%96%B4
13. 이건 찝찝한거 아니고 해볼예정 간단하게 AOP 적용해서 실행시간 로그 찍어보자!
그래도 이렇게 떠오르는 찝찝함은 양반이다. VIVA때에 의하면 날 기절하게 만드는 문제들은 여기서 뭐든 더 배워야 발견하게 되더라...
+
요구사항을 바꿔야겠다! 아주 똑같이 구현하란 법은 없으니까
오호 대공사가 되겠구만
대충 어떻게 수정할지 적어두자
기존
1. 사용자가 책 정보를 수정할 수 있었음. 그래서 같은 책이어도 사용자의 수정에 따라 정보가 다 변할 수 있어서 user에 바로 연결했었음.
2. 그러다보니 book 도메인도 커짐
3. isbn도 수정가능했는데 이건 아니다 싶어서 막아두긴 했음
4. 책 추가할때마다 페이지 정보 찾으러 알라딘 api 가야했음. 근데 알라딘 api는 사용제한이 있어서 남발 못함
수정(예정)
1. 사용자가 책 정보를 수정 못하도록 하자 (나중에 괜찮은 방법이 생기면 추가)
2. Book 도메인에서 책 정보랑 상태 정보를 분리
3. 책 정보에 대한 도메인이 있고, 이걸 사용자와 다대다 맵핑할건데 자동 생성되는 map 사용하지 않고 매핑 도메인(?) 직접 만들어서 거기에 칼럼 추가해서 책 상태 저장? (책 상태를 어떻게 할지는 좀 더 고민해보자!)
4. 통합 검색은 그대로 네이버 api를 사용하겠지만, 책을 추가하기 위해서 상세 검색을 했을 때 알라딘 api를 거치지 말고 먼저 book 테이블에 해당 isbn의 책이 있는지 확인하고 없을 때만 알라딘 api를 쓰자 (TLB같네 ㅎㅎ)
5. 그럼 isbn에 인덱스가 있는게 좋은데 이 테이블은 갱신이 많을거라 적절하진 않음...어차피 isbn은 유일한 값인게 보장되니까 그걸 pk로 쓰면..? 링크 흠...이게 정말 수정될 여지가 전혀 없는지 좀 더 찾아봐야겠다. 주민번호와 같은거라고 해도 주민번호도 수정될 여지가 있으니까 (물론 개인정보라서 pk로 못쓰는 이유가 크지만,,,)
링크 정말 안되는게 맞는건가??
5-1. 책을 미리 다 넣어놓는건...좀 그렇잖아..?
6. 실험할게 많은데 여기에 하기엔 뭐가 이미 너무 많아서 실험용 플젝을 간단하게 만들어야겠다
신문물을 맞이한 기념...
이상하네...글씨가 이 수준은 아니었는데...
진짜 이것보단 잘쓰는데...펜이 두꺼워서 그런 것 같다. 난 손이 작아서 펜 두꺼우면 글씨를 잘 못씀
암튼 대충 이런식으로 바뀌지 않을까..?
원래 user-book-memo의 관계였는데 이렇게 바꾼거다...
join 연산이 정말 많을텐데 성능에 대한 고민도 해야하지만...일단 구현해보고 하자
구현도 제대로 안해놓고 성능고민할 때가 아니다
