오늘은 오전에 좋은 코드, 나쁜코드 책을 독서하고나서, 하루 왠종일 Product Adapter out 계층 개발을 진행했다.
좋은 코드, 나쁜코드: 오류전달 기법
계속해서 같은 책만 보다가, 최근 PR 리뷰를 진행하면서, 좀 더 명확한 예외처리에 대한 고민에 책을 오랜만에 다시 꺼내보게되었다. 사실 이 책을 완독하지는 않았다. 책의 내용이 실제 개발 업무 간 사용되는 내용이 많지 않거나, 이전에 봤던 내용들과 중복되는(복습하기 딱인데..) 내용들이 많았다. 그래서 나는 다른 책들을 좀 더 우선적으로 보았었다.
이 책을 처음 사서 읽을 당시에는 혼자서 공부할 떄였다. 그래서 책을 보면서 당시 생각을 작성해 두었었다. 나중에 이와 관련해서 이야기를 해보겠다고 다짐했었건만, 이걸 잊고서 퇴사해버렸다..(바보...)
오랜만에 다시보니, 상당한 내용을 까먹었고, 나도 모르게 사용한 부분들이 많았다. 어떤 오류전달 기법이 좋은 것일까? 에 대한 답은 아직 내리지 못했지만, 지난 담당한 프로젝트에서의 경험을 돌이켜 본다면, 나는 암시적 기법을 선호하는 듯하다.
지난 담당 프로젝트에서는 오류 전달 기법과 관련하여 문제가 있었다. 어느 API 에서는 명시적 오류기법을 사용하고, 또 어떤 부분에서는 암시적 오류전달 기법을 사용하였다.(그래서 이것과 관련하여 고민도 했었는데.. 왜 이책을 까먹었을까?) 이전 프로젝트에서는 최악의 상황으로써, 한가지 관행을 따르는 것이 아닌 서로 완전히 다른 관행을 혼합해서 사용하고 있었다. 이 문제를 인식한 뒤에는 사수님과 이야기를 통해, 앞으로의 개발에서는 어떤식의 에러핸들링(오류전달 기법)을 사용할지 협의 후에 우리는 암시적 기법을 사용하기로 했었다.
그리고 이 후로는 이게 내 개발 습관이 되어, 명지님의 리뷰에 대한 명확한 내 코드의 의도를 전달하지 못했던 것같다.
지금 해당 리뷰에 대한 생각을 다시 정리해본다면, 이렇게 이야기 할 수 있을 것 같다.
현 프로젝트에서의 오류 전달 기법으로 비검사 예외(암시적 오류전달)를 사용하여 에러를 핸들링하고 있습니다. 이를 좀 더 자세하게 이야기를 한다면, 대부분의 오류처리는 코드의 상위 계층에서 다뤄, 코드 구조를 개선한 프로젝트 입니다.
리뷰에 덧붙여 명지님이 말씀해주신 방법은 명시적 오류전달 기법에 해당하는데요! 나중에 시간이 되신다면, 명시적 오류전달 기법과 암시적 오류전달기법을 주제로 이야기를 해보면 좋을 것 같습니다. 명지님은 어떤 오류전달 기법을 선호하시나요? 그리고 해당 기법을 선호하시는 이유가 있을까요?
Product Adapter out 개발
오늘 하루 대부분을 Product Adapter out 개발하는데 시간을 할애했다. 하지만, 결과물이 없다..(럴수가..)
지난 개발간, 영속성 어댑터를 어떻게 구현할지에 대한 계획을 세우고, 오늘은 해당 내용을 구현하고자 하였다. 설계는 끝이났기에, 크게 어렵지 않을 것이라고 생각했다.
Querydsl을 사용하기 위해 나는 build.gradle에 설정 값을 추가하고, QuerydslConfig, ProductQuerydslRepository 를 생성했다. 여기까진 잘 됬다. 근데 문제는 테스트를 진행해보기 위해 테스트 작성 간 문제가 발생했다.
Spring 설정에 무엇인가 문제가 발생했다. initializationError 가 발생해서 Spring Test를 진행할 수가 없다.
Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]:
Invocation of init method failed; nested exception is org.hibernate.AnnotationException:
mappedBy reference an unknown target entity property:
com.shoes.ordering.system.domains.product.adapter.out.dataaccess.entity.ProductImageEntity.products in com.shoes.ordering.system.domains.product.adapter.out.dataaccess.entity.ProductEntity.productImages
대략적으로 현재 개발중인com.shoes.ordering.system.domains.product.adapter.out.dataaccess.entity.ProductImageEntity.products in com.shoes.ordering.system.domains.product.adapter.out.dataaccess.entity.ProductEntity.productImages
에 문제가 있다고 한다.
확인을 해보니, 문제점을 찾지 못하겠다..
나는 문제가 무엇인지 모르겠다.. 하지만 다른 문제점들을 확인했다.. 그리고 이 허점과 구멍이 생각보다 크다..
이제서야 발견한 문제점들
내가 가장 먼저 발견한 문제점은, 기존의 ProductEntity 에 Product 의 필드(price)가 누락된 것이다.(위의 사진은 문제를 확인하고 개선한 모습이다.)
이 부분은 크게 문제가 되지 않았다. ProductEntity 에서 필드값만 추가하면 해결되는 문제이기 때문이다.
이번에 발견한 것은 꽤 수정할 부분들이 많은 부분이다... ProductEntity는 ProductImageEntity 를 여러개 가질 수 있다. 이는 Product는 ProductImage를 여러개 가질 수 있음을 의미한다. JPA Entity를 설계하면서 이 문제를 확인했다. 이를 고치기 위해 Product 를 생성하는 모든 부분(에서 ProductImage를 생성하기때문이다.대부분 Mapper) 에서 수정을 해야한다. 사실 이 부분도 크게 어렵지않다. 단지 귀찮을 뿐.. 그리고 테스트가 있기에 두렵지 않다.(근데 테스트가 안되네?)
다음 오늘 마지막으로 확인한 부분이다.. 진짜 내가 왜이랬을까 싶다.
나는 기존의 Command, Query에서 사용을 할 때, ProductImage의 사용을 해야했다. 그리고 나는 어차피ProductImage 에서 URL(String) 만 사용하는건데, 이거 처음에 가져올 때, 변환해서 가져오면 되겠네? 하는 잘못된 생각과 판단을 했다.. 멀쩡히 있는 DataMapper 냅두고.. 내가 왜 그랬을까... 아주 바보같다.. 과거 이 스노우볼이 굴러 지금 현재, 해당 부분을 사용하는 Command, Query, DataMapper, ProductImageEntity 모두를 수정해야한다. 사실 수정은 별로 큰 문제가 안된다. 생성에 대한 테스트가 있으니깐! Command, Query 생성 부분은 =Spring Test로 작성하지 않고, 정상 생성 및 검증 테스트로 작성하여 다행히 잘 동작한다.
지금 파악한 문제점들만 수정한다고, 처음 발생한 문제가 해결될지가 의문이다.. 하지만 일단 발견한 문제점을 고쳐보고 다음에 생각해야겠다.. 오늘 어제 고민한 부분을 어떻게 설계하고 개발할까? 고민하고, 도식화하고 그랬는데.. 한게 없는 것 같아 너무 속상하다. 어서빨리 Product 를 마치고, Order 를 개발하고싶다.. 정말 Order 가 정말 재밌을텐데..(물론지금의 Product 도 재밌긴 하지만..) 어서 핵심을 하고싶다.. 더 힘내보자 !!! 아좌좌!!!!!
'회고 > TIL' 카테고리의 다른 글
만들면서 배우는 클린아키텍처 독서: 테스트, Product Adapter(out.dataaccess) 개발 및 테스트, 알고리즘 문제풀이 (1) | 2023.07.12 |
---|---|
원인 파악 및 삽질, 알고리즘 문제풀이 (0) | 2023.07.11 |
Product DataAccess 계층 개발 시작 (1) | 2023.07.07 |
PR 피드백 반영, 편두통 (1) | 2023.07.06 |
Product Domain 완료 (0) | 2023.07.04 |