Shoes-Ordering-System 개발 일지, SpringBoot Up & Running, Effective Java

요즘 재밌게 보고 있는 두 책

 

 

요즘 매일 아침 재미나게 보고 있는 책이 두권있다. 하나는 처음부터 제대로 배우는 스프링부트(SpringBoot Up & Running), 이펙티브 자바(Effective Java) 이다. 처음부터 제대로 배우는 스프링부트(SpringBoot Up & Running)는 자바와 코틀린를 활용한 웹개발을위해 Spring 을 공부하는데 마음에 드는 책이 없어서 고민하다 일고리즘의 추천으로 이 책을 구매해서 보게되었다. 사실 공식문서를 통해 공부하면 좋지만, 나는 정리되고, 필요한 내용이 들어있고, 무엇보다 검증된 자료가 필요해서 책을 구매했다.(공식문서.. 영어 해석하는게 더 오래걸리는것같아서.. 어느정도 공부가 되면 공식문서로 공부할거다..ㅎ) 이펙티브 자바의 경우, 옛날에 잠깐~ 봤었는데, 코드 작성에 있어서 시니어분들과 책을 통해 이야기를 듣는 기분이라서, 그냥 꾸준하게 읽어보고 있다(재밌다. 리팩토링2판을 처음 읽을 때 기분이 든다.)

---

 

처음부터 제대로 배우는 스프링부트(SpringBoot Up & Running)

 

오늘 읽은 처음부터 제대로 배우는 스프링부트(SpringBoot Up & Running) 는 기본적으로 Spring Boot 를 사용하는 이유, 프로젝트 빌드 도구의 비교(gradle vs maven) 을 공부했다.

 

Spring 을 처음 들었을 때, 나는 너무나도 다양한 Spring에 당황했었다. Spring Web, Spring MVC, Spring Cloud, Spring Security, Spring Boot, Spring WebFlux 등등.. 너무나도 다양한 Spring 에 다음에보자 했었다. 지금보면 이것들은 Spring의 거대한 생태계를 말하는 것이였는데, Spring을 사용하면 해당 Spring*를 사용할 수 있다.  다양한 라이브러리를 사용한다는 것은 의존성 관리가 필수적인데, Spring Boot 는 이러한 의존성 관리를 편리하게 해주는 도구였다. 결론만 이야기한다면 Spring Boot 는 의존성 관리(dependency management) 간소화, 배포(deployment) 간소화, 자동설정(auto configuration) 을 통해 개발자를 생산적으로 만들어주는 도구였다. 그래서 사용한다.(최고다.)

 

 

Java 와 Spring을 활용해서 공부를 시작하면서, 나는 스크립트언어(Python, PHP 등)을 사용해서 개발을 해왔기에, 인터프리터언어인(자바, 코틀린)에는 익숙하지 않았다. 그래도 다 알아서해주는데 큰 문제는 없었다. 정확히는 문제는 없었고 고민은 있었다. 현재 빌드도구는 크게 Gradle 과 Maven 으로 총 2가지로 나눠지는 것을 알 수 있었다.나는 Maven 으로 Spring 개발을 처음 공부했고 당시에는 gradle을 알지 못했다. 점점 더 깊게 공부하면서, 다른 자바와 코틀린을 공부하는 분들과 이야기하면서, Maven을 사용하면서 라이브러리 버전 업그레이드 관련해서 궁금한게 있어서 이야기를 했었는데, 다들 Maven 은 사용안해보고 Gradle 을 사용한다고 했다.

 

이 떄부터 고민이 되기 시작했다. Gradle을 선택하는것과 Maven 을 선택하는 기준이 뭘까.. 간단하게 검색을 해보면 결론은 없고 각 빌드도구에 대한 설명만 가득했다. 설명은 알겠는데..그래서 기준이 뭔지 몰랐는데 이번에 책을 통해 알 수 있었다.

 

Maven Vs Gradle

 

둘을 선택하는 기준은 1. 개발환경 과 2. 빌드속도 를 이야기 할 수 있다.

 

1. 개발환경

 

개발환경을 몹시 일관되게 만들고 싶다면 Maven 을 사용하자. 엄격하고, 때로는 독단적이까지한 선언적 접근법은 빌드에 신경쓰지 않고 코드에만 집중할 수 있다.

Gradle은 개발환경이 유연하다. 유연함은 개인적으로 단점이라고 생각한다.(개발환경 한정) 스크립팅 중심은 gradle은 빌드 시 프로젝트에서 출시된 버전의 프로그래밍 언어를 사용할 때 문제가 생길 수 있다. 이는 큰 문제점이라고 나는 생각한다. (호환성 문제를 안고 간다는것이니깐?)

 

2. 빌드속도

 

Maven 와 Gradle 을 비교하는 글을 찾아볼 때, 가장 많이 언급된 것이 빌드 속도였다. Gradle이 Maven 보다 무진장 빠르다는데, 맞긴하지만 그 이유에 대한 이야기는 알 수 없었다.(그래서 빌드속도 떄문에 gradle을 선택해야한다! 는 생각은 들지 않았다.) 다만 대규모 프로젝트에서는 grdle이 우세하다고 한다. 하지만 이것도 대규모 프로젝트라면, MSA로 갈텐데.. 작은 프로젝트 단위로 나눠지는데 큰 차이가 있을까 싶다. 이에 더해, MSA에서의 다른 개발환경을 일치하는것(Template) 에 대한 생각도 해본다면.. 나는 이것이 큰 메리트로 느껴지지 않았다.

 

종합적으로 나는 Maven 이 더 내가 추가하는 개발에 맞다는 생각이 들었다. 확실한 버전관리와, 몹시 일관된 개발환경 만으로도 Maven 을 선택했을 것 같다.(근데 이번 Shoes Ordering System 에서는 gradle을 사용하고 있다. 그래도 써보긴 해야지 ~!)

 

하지만 이건 내 생각이고, Grdle을 사용하는 개발팀에 일하게 된다면(혹은 대화할 기회가 있다면) 해당 빌드 도구를 사용한 이유를 물어보고 그 선택의 이유를 들어보고 싶다.

 

---

이펙티브 자바(Effective Java)

 

이펙티브 자바(Effective Java)는 사실 읽는데 속도가 잘 안나는 책이다. 가볍게 읽고 넘어가는게 잘 안되는 것 같다. 그냥 짧은 글인데 짧은 글 이상으로 생각을 하게 만드는 마성의 책이다.(근데 고작 이제 아이템 1까지 읽었다.) 나는 보통 들어가기 전에 글을 꼭 읽어보는데, 읽어보길 잘한 것 같다. 나는 최근 가장 큰 관심사 중 한 부분이 성능에 대한 부분이다. 최근에 친구를 만나 성능의 트레이드오프가 무엇이라고 생각하는지 이야기를 해봤는데, 친구는 글쎄... 라는 말만 했었다. 그래서 혼자 성능을 얻으면서 잃게되는 트레이드 오프에 대한 생각을 많이 하고 있었는데, 마침 관련된 내용이 책에 있었다. 책의 내용을 읽고서 든 생각은, 성능의 트레이드 오프는 명확성, 정확성, 유용성, 견고성, 유연성, 유지보수성 을 이야기하는구나. 싶었다.

 

이 책에서 성능에 집중하는 부분은 많지 않다. 대신 프로그램을 명확하고, 정확하고, 견고하고, 유연하고, 관리하기 쉽게 짜는데 집중한다.

 

다시 본문의 글을 보니.. 내가 잘못생각한 것 같다..

 

---

 

Shoes-Ordering-System 개발 일지

 

원래는 오늘이 Member 도메인 개발을 마치는 것이 목표였는데, 목표를 이루지 못했다. Shoes-Ordering-System 은 이전에는 고려하지 않았던, 계층과 도메인 설계 에 대한 부분을 많이 고려하다보니, 예상한 기간보다 더 오래 걸리는 것 같다. 그래도 가장 오래 걸릴 것으로 예상한(그리고 실제로도 가장 오래걸리는) Domain 계층 개발을 마치고, 테스트를 진행하는 과정에서 문제가 발생했다.

 

Domain-Application 계층을 테스트 하는 도중 createMemberTest 에서 문제가 발생했다.

 클라이언트의 요청을 나는 수행해야 할 명령(Command) 로 분류하고, createMemberCommand 를 memberApplicationService 의 createMember 메서드를 통해 CommandHandler 를 거쳐,  Domain-Core 에서 값을 검증하고, MemberCreatedEvent 를 발행하는 로직을 개발했다.(말로하니깐 너무 복잡해보인다. 시퀀스 다이어그램을 만들어야겠다.)

 

memberCreateEvent가 null 이라고 한다.

그런데 Domain-Core 로직에서 발행하는 MemberCreatedEvent 에서 문제가 발생했다.

 

memberDomainService.validateAndInitiateMember 메서드가 건너 뛰었다.

persistMember 로직이 문제였다. 로깅을 하는 부분에서 memberCreatedEvent가 null 이라서 정보가 없다 한 것이다.

 

 

해당 함수에 프린트를 통해 디버그를 시도했다.

정말 이상하게, println 이 찍히지 않았다. 근데 신기하게 테스트결과는  validateAndInitiateMember 전 후의 println 은 잘 출력이 되었다.

 

출력이 잘 나왔다.. 근데 왜 validateAndInitiateMember 는..?

 

 

내가 생각한 원인은 딱 하나였다. MemberDomainService 는 순수한 자바 클래스로, Spring Bean 에 등록이 되지 않은것 아닐까? 하는 생각이었다. 하지만 나는 TestConfiguration 을 통해, MemberDomainService 를 Bean 으로 등록했다.

 

Bean 으로 잘 등록된모습이다.

진짜 원인을 알 수 없었다. 그렇게 고민하다 같이 공부하는 분들께 도움을 요청했다 역시나 memberDomainService 가 문제의 원인으로 예상했고, 생성되는지 한번 디버그 해보자 라는 생각으로 memberDomainService 를 println 해보았다.

 

Mock for MemberDomainServiceImpl

처음에는 역시 정상 생성됬는데.. 왜 안돼지? 였다. 그런데 보다보니 의문이 들었다. 엥? 왠 Mock for MemberDomainServiceImpl..?  그제서야 다시 TestConfiguration을 확인했다.

 

나 왜 Mock 으로 만들고 있지..?

바로 해당 부분을 정상으로 수정했다.

 

정상적으로 MemberDomainServiceImpl 을 등록했다.

이후 드디어 나는 초록불을 볼 수 있었다.

 

정상 Member 생성 확인

 

장장 3시간이 걸려 문제를 해결했다. 아직도 내가 왜 MemberDomainService를 Mock 으로 등록했는지 의문이지만.. 그래도 원인을 파악하고 문제를 해결할 수 있어서 다행이다. 비록 오늘 DB 연결 및 API 개발을 완료하지는 못했지만, 그래도 이제 금방 할 수 있을 듯하다! 내일은 예비군이라서 많이 공부를 못할 것 같아서 아침에 책을 읽고 예비군 받으면서 다음 도메인 설계나 더 해봐야겠다.