셀프 리뷰, 오류 수정과 개선

어제 잠들기 전, 메시징을 빠트린것이 자꾸 생각이나 잠에 못들었었다. 그래서 결국에는 다시 책상에 앉아 실행을 해보았었다. 당시에는 몇가지 문제들이 존재하여, 메시징 발행이 되지 않았고, 에러의 원인을 고민하다가 시간이 너무 늦어져 그냥 아침에보자는 마음으로 잠에 들었다. 그리고 아침, 피곤했지만, 책상에 앉아 해당 문제를 고민하고 해결했다.

 

---

메시징 에러 해결: snappy M1 이슈, Avro 포맷 문제

 

너무 작아서 잘 안보이지만.. 총 발생했던 에러2개 중 하나이다.

가장 먼저 발생한 에러는 snappy에러 였다. 에러의 내용은 간단했다. M1에 지원하지 않는 버전이라는 에러였다. 그리고 이 문제는 블로그 검색을 통해 손쉽게 해결할 수 있었다.

 

참고블로그

OSX - M1 개발환경 오류 snappy-java - [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Mac and os.arc

 

그리고 다음 문제는 Avro 클래스에서 발생했다. 내가 파일에 형식을 잘못했었다.

 

문제의 형식과 올바른 형식

나는 uuid 타입명시를 logicalType 을 통해 명시하였는데, 해당 포맷은 잘못된 것이었다. 그리고 나는 이게 문제가 되는것을 알지못했다가 이제서야 제대로된 이벤트 프로듀싱을 통해 알게되었다.

 

이번 에러들을 너무나 친절(?)했다. 모든 에러의 해결이 에러메시지를 통해 해결할 수 있었다. 이것을 보면 정말 에러메시지의 중요성과 편리함을 다시한번 느끼게 되는 것같다.

정상 생성된 product 생성 이벤트. 보고서 너무 기뻤다!

그리고 해당 문제를 해결하고난 뒤, 모든불이 초록불이고, 내가 작성해둔 로그를 통해 정상 이벤트 발행이 됬음을 알 수 있었다. 그리고 완벽한 확인을 위해 kcat 명령 을 통해 확인했다.

 

정상적으로 확인된 create-product-request 이벤트

 

---

셀프리뷰: 문제 개선

 

나는 셀프리뷰를 시작했다.

 

나는 어제 이제 스스로 리뷰를 진행하기로 다짐했고, 오늘 그것을 실행하였다. 어제 한번 다시 스스로 코드를 쭉 돌아봤었기에, 무엇을 수정하고 개선할지 어느정도 정해두었기에 그리고, 이것을 작성해두기 전 다른 분들이 리뷰를 진행하는데 방해가 되지는 않을까 하는 마음에 로컬에서 작업할 부분들을 고민하고 있었다.

 

하지만 셀프리뷰를 시작할 때까지, 결코 다른 사람들의 리뷰는 진행되지않았다. 테스트부분에 대한 고민도 있어서 테스트의 중요성을 강조해주는 승원이에게도 리뷰를 부탁했지만.. 아쉽게도 리뷰는 없었다.

 

하지만 괜찮다. 내가 내 코드를 비판적으로 바라볼 수 있는 기회가 될테고 또 더 나은 코드를 스스로 만들 수 있는 소중한 경험이 될테니깐말이다!

 

PR 링크

Feature/product adapter: Messaging, Web by KEEMSY · Pull Request #5 · KEEMSY/shoes-ordering-system

 

---

입력 유효성 검사의 적절한 위치

 

 

가장 먼저 나는 고민이 되었던 부분을 스스로 답을 내리고 해결해보고자 하였다.

 

내가 작성한 고민, 입력 유효성 검사의 위치에 대한 고민이 되었다.

나는 입력 유효성 검사는 입력모델에서 진행하는 것이 올바른 것(입력 유효성의 검사는 입력모델의 책임)이라고 생각하고 있었다. 그리고 그에 알맞은(?) 입력 유효성 검사를 TrackProductListQuery 모델에서 진행했다. 하지만 개발을 진행하면서, 문제가 발생했다.

 

문제는 다음과 같았다. 입력 값이 들어왔을 때 값은 String 이지만 내가 검증하는 타입은 ProductCategory 였다. 그리고 나는 입력 모델이 생성될 때, 생성자를 통해 입력 유효성 검사를 진행했는데 이 로직으로서는 입력 유효성 검사를 진행 할 수 없었다.

 

그래서 나는 입력 유효성 검사를 웹계층에서 진행하고, 유효한 값을 ProductCategory 리스트로 담아 TrackProductListQuery 로 만들었으며, 유효한 ProductCatgory에서도 사용가능한 카테고리인지 확인했다. 그리고 이 로직은 누가봐도 문제가 존재한다.

 

첫번째로, 그래서 어디서 입력 유효성 검사를 진행하는데? 하는 물음표가 나온다. 웹계층에서할 수도 있고, 입력모델에서도 할 수 있어 는 너무 무책임한 말이라고 생각한다. 나는 책임이 분명하게 나눠져야한다 생각했고, 입력 모델에서 해당 검사를 진행해야한다고 생각하며 만들었었다.(하지만 지금의 문제가 발생했지)

 

두번째로, 이전에 작성한 유효성 검사는 책임이 두가지이다. 입력유효성검사와 비즈니스로직유효성 검사이다. 그리고 이것이 이 문제의 시발점이 되었다고 나는 생각하고 있다.

• ProductCategory의 모든 값을 담은 집합을 만들고 이에 들어있지 않은 값을 검증했다. = 입력 유효성 검사
• 존재하는 ProductCategory 지만 이용불가한 카테고리인지 검증했다. = 비즈니스 규칙검사

 

이를 파악하고 난 뒤, 나는 다음과 같이 로직을 개선했다.

 

가장먼저, 입력모델인 만큼 입력값이 특정 클래스가 아닌 기본 String 으로 받을 수 있도록 수정하였다.

TrackProductListQuery의 일부분. 입력 유효성 검사를 입력 받을 때 진행했다.

 

입력 유효성 검사를 진행하면서 한가지 문제가 있었는데, 바로 null 인 경우를 잡아내지 못한다는 것이었다. 해당 부분도 입력 유효성 검사에 일부분으로서, 나는 해당 부분에 대한 고민을 하면서 SelfValidating 을 만들어 입력 유효성검사(NotNull 체크)를 진행했었으나, 이게 순서가 맞지 않는지.. 로직을 수정한 뒤에는 null 인경우를 잡아내지 못하였다. 그래서 나는 NotNull 입력 유효성 검사를 직접 작성했다.

 

그리고 기존의 유효성 검사 로직은 다음과 같이 개선하였다.

생성자와 유효성 검사 로직

이용 불가한 ProductCategory 를 만들어 비즈니스 로직을 검증하였다. 사실 비즈니스 로직의 검증은 애플리케이션 계층에서 이뤄져야하는데.. 하는 고민이 있었지만, 이것은 할 수있는 것이라는 생각이 들었다.

 

여기서 이용불가한 ProductCategory 가 하나여서 이게 왜이렇게 했냐할 수 있지만, 저것은 고도화가 된다는 가정하에, 수 많은 카테고리가 생겼을 때, 다양한 카테고리가 이용불가한 카테고리로 변경될 때를 고려하였다.

 

해당 부분 수정 후, 다른 모듈 및 테스트를 개선하였다.

---

이외에도 다른 사소한 부분, 메서드명 개선이 있었는데 이건 너무 간단해서 기록하는것을 패스했다. 그리고 대망의 메시징 부분을 개선하는것인데 문제가 된 부분을 하나하나 다시 거꾸로 돌아가 정리하고 있어서 해당 부분은 지금 작성해두지 못했다. 아마도 포스팅을 마치면 메시징 부분도 거의 마무리 하거나, 내일 아침에 마무리를 지을 수 있을 것 같다.

 

내일은 초기 설계한 Product 도메인을 마무리지으려고한다. 그리고 Member 이슈등록, Product 이슈작업, Order 문서작성을 시작할 계획이다. 여기에 책도 봐야하고.. 문제도 풀어야하고... 바쁘다 바빠.... 오늘은 잡생각없이 푹 자고 일찍 일어났으면 좋겠다.