반찬가게 프로젝트 - 공식문서 읽는 법, 유의미한 삽질

2주간 프로젝트를 진행하면서 배운 것들을 적어보았다.

사용기술

• Spring Data JDBC
• [△] OAuth
• [] nginx를 통해 java application tomcat서버와 통신 셋팅
• [] 배포

프로젝트 때 배운 점

• Spring Data JDBC 자료가 별로 없어서 공식문서를 보면서 기술을 익힐 수 있는 기회가 되었고 , 막연하고 읽기 힘들었던 공식문서 읽는 방법을 감을 잡은 것 같아 뿌듯했다.
• 새로운 기술을 적용하면서 기술과 상관없는 것들을 삽질하는 일도 많았고, 그 과정들을 적어보려고 한다.

내가 파악한 공식문서 읽는 법

1 먼저 근간이 되는 개념을 알기

그래야 전체적인 흐름을 잡을 수 있는데 근간이 되는 개념이 무엇인지 어떻게 알 수 있는가?
그것 또한 공식 문서에 나와 있었다.

All Spring Data modules are inspired by the concepts of “repository”, “aggregate”, and “aggregate root” from Domain Driven Design. 
These are possibly even more important for Spring Data JDBC, 
because they are, to some extent, contrary to normal practice when working with relational databases.

처음에 Spring Data JDBC 관련 자료가 없음을 확인하고 공식문서를 볼 수 밖에 없어서 보게 되었는데 처음엔 무조건 튜토리얼을 따라서 금방 해보고 싶은 마음에 "Get Started"부터 살펴보았다.
그런데 DB통신과 관련한 기술에서 아는 것 없는 상태에서 튜토리얼을 따라하려고 하니 조금이라도 에러가 생기면 진전이 되지 않았다.
의미 없는 삽질만 저녁시간 3시간 정도를 사용하고 나니 지치기도 하고 이거 어떻게 해결해야하는 걸까 답답한 마음도 들었다.

그래서 일단 자고 다음날 다시 차근히 공식문서를 처음부터 보았을 때 위에서 본 Spring Data JDBC의 가장 중요한 개념을 나열해놓은 것을 보았다.
repository, aggregate, aggregate root

해당 개념을 검색해보니 잘 정리된 한글 자료가 있었다.
해당 문서로 개념을 파악하니 무릎이 탁 쳐졌다.

일반적인 관계형DB에 종속적인 프로그램 설계가 아니라 DDD란 이런 것이구나.
엔티티 설계부터 repository의 활용이 이전 JDBC Template과 이렇게 달라질 수 있구나를 볼 수 있었다.

그리고 나서 조금이라도 활용하는 것을 보고 싶어서 유튜브에서도 'Spring Data JDBC'를 검색해서 해당 링크 자료를 찾았다.
튜토리얼을 빠른 라이브코딩을 통해서 전체적인 사용방법을 빠르게 확인해 볼 수 있어 좋았다.

2 개념 파악 후엔 전체 목차를 파악하기

그렇게 개념을 파악하고 공식문서를 읽으니 더 수월하게 읽혔고, 왜 이런 이야기들이 나오는지 알게되어 문서 읽는 것 자체가 재미 있었다.
그런데 또 하나의 의문이 생겼다.

" 얼마나 자세히 읽어야 할까? "

지식은 습득했지만 아직 개발은 하나도 못한 상황이다. 그리고 공식문서량이 꽤 많았고, 이거 다 읽고 정리하고 적용할 수는 없는 노릇이였다.
그렇다면 어떻게 해야할까?

Application 에서 DB에 접근해서 데이터를 가져오는 과정을 리스트업 해보자

JDBC Template과 Spring Data JDBC를 사용하면서 일련의 과정이 있다는 것은 어렴풋이 느껴지는데 그 과정을 리스트업해보면 아래와 같다.

1. DataSource를 통해서 DB서버와 연결한다.
2. DB와 연결하기 위해 접속 정보들을 적는다.
3. Transaction을 사용을 위해 어떤 구현체를 사용할지 config에 작성한다.
4. 어떤 JDBCTemplate 사용을 위해 어떤 구현체를 사용할지 config에 작성한다.
5. Repository에 쿼리를 작성한다.
6. 작성한 쿼리의 실행결과를 자바 빈과 매핑하기 위해서 rowMapper를 사용한다.

여기에서 Spring Boot를 사용하면 자동으로 해주는 경우들이 많다. 그런 것이 처음 셋팅이 어려운 스프링을 더 쉽게 사용하게 해주는 것임을 느꼈다.
그리고 JDBCTemplate을 사용할 때 왜 Repository를 쓰는지 이해하지 못했고 궁금했지만 넘어갔는데 이번에 Repository라는 것이 프레임워크에서 사용하는 것임을 더 피부로 느끼면서 공부하고 정리해봐야겠다는 생각이 들었다.
그리고 '아 이래서 라이브러리가 아니라 프레임워크구나'를 느꼈달까
Repsoitory는 프레임워크의 전체 흐름에 맞춰 개발자가 작성해야 하는 부분 중에 한 부분임을 느꼈다.

이렇게 흐름을 알면 공식문서의 목차들이 그것들을 어떻게 해나가는지 자세히 나열하고 있음을 느낀다.
특히나 DDD를 표방하는 Spring Data JDBC는 propery popluation 부분이 JDBCTemplate과는 다른 부분이라 인상적이었다.

JDBCTemplate은 개발자가 수동으로 쿼리를 날려 엔티티의 프로퍼티 값을 가져오지만 ORM기술에서는 프레임워크가 알아서 DB값을 가져와 변경해주는 부분이 있으므로 기본적으로 엔티티는 불변이지만 변경해야 할 때 각 속성에 대해 수정하는 부분이 파트가 있는 것이고
그 수정을 Spring Data JDBC는 기본 속성 접근, setter, with사용등을 한다는 것을 알 수 있었다.

이렇게 파악하기 위해서는 초반에 한글자 한글자 자세히 읽는 과정이 있었고
하루 정도 보고 나니 이렇게 하다가는 개발을 못하겠는데 생각하다가 이 기술의 핵심을 파악하면 목차가 보이고 목차를 통해 상세 부분을 찾아 개발하면 된다는 것을 알게 되었다.

이렇게 스스로 알게 되니 사실 너무 뿌듯했고, 그 어려웠던 공식문서 보는 것에 재미를 느꼈다.

그리고 실제 개발할 때는 공식문서에 Examples Repository로 링크되어 있던 깃헙 예제 소스가 실질적으로 사용하는데 많은 도움이 되었다.

첫번째 삽질 : 생성자를 통한 의존성 주입

그렇게하고 간단하게 튜토리얼 수준을 프로젝트에 적용하려고 했다.
실습차원으로 다른 엔티티와 관계를 맺지 않은 상태의 category 엔티티에서 간단하게 findAll() 이나 findById()를 실행하려고 했다.
근데 자꾸 DB에 접근도 못하고 에러가 났는데 그 에러가 어디에서 난 에러고 왜 났는지도 해결못하고 있었다.

무의미한 삽질

• 에러메세지가 상세하지 않고 개념적이라 생각했다.
• 현재 상태에서 개념을 파악하기엔 힘들꺼라 생각해 그냥 이것저것 붙였다 때었다 해봤다.
• 결국 되지 않았고, 심지어 프로젝트를 새로 파서 해봐도 똑같이 안됐다! 왜지?
• 이건 새로 도입하는 Spring Data JDBC를 잘못적용해서가 아니라 거기까지 가지도 못하는 문제였다.

무의미한 삽질을 반복했고, 해결도 못했고, 사실 문제 해결 과정 자체가 어떤 체크리스트를 세워두고 하나씩 해결해 나가보면서 문제의 원인을 찾으려 했다기보다 안되니깐 실행이 되도록 여러가지 해보는 과정만 반복했다.
그러니 그 과정 자체가 지치고 왜 안되는지 파악이 안되니깐 답답하기만 했다.

삽질도 하나의 공부라는데 그럼 삽질을 잘 하기 위해서는 어떻게 해야할까?
삽질 이라는 것을 어떻게 해야 하는지? 몇 시간 정도 해보고 물어봐야 하는건지? 의미 있는 삽질은 어떤 것인지? 가 궁금해졌다.

유의미한 삽질

유의미한 삽질이란 이번의 경우를 예로,

• 제일 먼저 의존성 주입이 안되는 것을 파악
• 의존성 주입이 안되는데 왜 안될까?
• 의존성 주입은 어떻게 이뤄지고, 어떤 방법이 있지?
• 나는 어떤 방법으로 의존성 주입을 하려고 했지? -> 생성자를 통한 의존성 주입
• 생성자를 통한 의존성 주입은 어떤 조건을 충족해야 하지?

이렇게 전체적인 그림을 보려고 하면서 이해하고 있는 원리의 흐름을 따라서 그 흐름이 맞는지 확인하면서 디버깅을 해보는 것이라고 한다.

나의 경우 생성자를 통한 의존성 주입이 안되었으니 왜 안되었는지를 확인해보면 된다.
그리고 생성자는 롬복을 이용해서 작성했었다.
그러므로 롬복 생성자 어노테이션에 대해서도 공부했어야 했다.

그리고 처음에는 의존성 주입이 안됐다는 것 자체를 몰랐는데, 어디에서 에러가 발생하는지 파악하기 위해서는 디버깅을 제대로 할 줄 알아야 한다.

• 에러메세지를 잘 읽고
• Exception 이름만 보는 것이 아니라 stack trace를 보고 어디가 문제인지를 확인해야 한다.
• 그리고 의심되는 부분에 브레이크 포인트를 걸고 브레이크 포인트까지 의도한 것이 잘 되었는지 확인하면 된다.
• 아마 해당 속성(클래스)을 확인했다면 null이였을 것이다.
  .
  인텔리제이로 디버깅하는 방법은 유튜브 링크에 잘 나와있다.

결론적으로 의존성주입이 되지 않았던 이유

Repository Bean을 다른 클래스에서 사용할 때 속성으로 두고, @RequeriedArgConstrutor를 사용했는데
@RequeriedArgConstrutor은 final이 붙은 속성에 대해서만 생성자 의존성 주입을 하게 된다. 이름 그대로 요구되는 속성에 대해서 생성자를 만들어 주니깐 그런 것이다.
그런데 나는 속성에 대해 final을 붙이지 않았던 것이다.

그렇다면 @AllArgsConstructor를 사용했으면 문제가 없었을까?
그렇게 체크리스트를 두고 확인해보면 된다.