[인프런 워밍업 클럽_0기] 2주차, 두 번째 발자국 #2

2주차, 두 번째 발자국

2주차는 계속 되는 야근으로 인해 시간에 쫓기듯이 공부하고, 과제했던 주였다. 속도가 급하면 체하기 마련! 그래서 오타 등의 실수도 많이해서 삽질로 많은 시간을 보내기도 했다.

이전 발자국에서도 남겼지만 강의 별 요약본은 notion에 있다.

Day 7. 스프링 컨테이너의 의미와 사용 방법

스프링 컨테이너의 역할을 정확히알게 되었다.
- 스프링 컨테이너 : 서로 필요한 관계(의존 관계)에 있는 스프링 빈을 연결해주는 역할
스프링 컨테이너의 동작 과정을 알게 되었다.
- 스프링이 서버를 시작한다 > 스프링 컨테이너가 시작된다 > 기본적으로 설정된 스프링 빈들이 등록된다 > 개발자가 설정한 스프링 빈이 등록된다 > 필요한 의존성이 자동으로 설정된다.
스프링에서 등록한 스프링 빈을 어떤식으로 땡겨와야하는지 알게 되었다.
- 등록된 스프링 빈을 사용하려면 해당 클래스 파일을 스프링 빈에 등록해야 땡겨올 수 있다!
Interface를 이용하여 코드 수정 시 수정하는 부분을 최소화 할 수 있다.
- 다른 클래스에서 Interface를 상속받게하고 생성자에서 교체하고 싶은 구현체를 변경만해주면 되기 때문!
하지만 위의 방법도 어찌저찌 됐든 생성자를 수정해야하기 때문에 수정은 불가피하다! 이런 걸 해결할 수 있는 어노테이션이 @Primary 와 @Qualifier를 사용하면 구현체 주입 우선순위를 설정해줄 수 있다.
- 참고로 Primary와 Qualifier 중 우선순위가 더 높은 건 Qualifier이다.

https://devhan.tistory.com/323
기존에 작성했던 코드를 Controller, Service, Repository 3단계로 분리하는 과제였다. 다른 건 다 괜찮았는데 Repository가 Interface로 변경되고 MemoryRepository와 MySQLRepository로 구현체를 나뉘어서 개발하는 부분에 시간을 너무 많이 쏟았던 기억이 난다.
그래도 개발하면서 기존에 작성했던 코드를 리팩토링 하는 과정도 거칠 수 있어서 더 재밌게 코딩할 수 있었던 거 같다.

https://devhan.tistory.com/324
이번 과제도 기존에 작성했던 코드 중 문자열로 작성된 쿼리를 JPA로 변경하는 과제였다.
warehousingDate 필드가 제대로 맵핑되지 않는 문제때문에 골머리를 앓았다. 찾아보니 스프링에서는 카멜케이스로 작성된 필드는 DB 컬럼에서는 '_'로 단어를 구분한다고 한다. ex) warehousingDate -> warehousing_date
- 이 에러는 ddl-auto를 create로 만들어주고 처음부터 다시 매핑해서 해결되었다.
그 외에는 딱히 어려운 점은 없었다!

트랜잭션의 이론에 대해서 알게 되었다. 트랜잭션이 뭘 하는지는 대략적으로 알았는데 딱 정의할 수는 없었다.
- 트랜잭션 -> 쪼갤 수 없는 업무의 최소 단위
@Transactional의 사용 범위와 readOnly 옵션에 대해 알게 되었다.
- Select 쿼리에서는 readOnly 옵션을 사용하는게 성능상 더 좋다
영속성 컨텍스트에 대해 알게 되었다.
- 테이블과 매핑된 엔티티 객체를 관리하고 보관
- 스프링에서는 트랜잭션을 사용하면 영속성 컨텍스트가 생겨남
- 트랜잭션을 종료하면 영속성 컨텍스트가 종료됨
영속성 컨텍스트의 4가지 장점
- 변경 감지(Dirty Check) : 영속성 컨텍스트 안에서 불러와진 객체는 명시적으로 save 하지 않더라도, 기존 정보와의 변경을 감지해 자동으로 저장된다.
- 쓰기 지연 : DB의 INSERT, UPDATE, DELETE SQL을 바로바로 날리는게 아니라 트랜잭션이 commit될 때 한번에 모아서 한 번만 날린다.
- 1차 캐싱 : 아이디를 기준으로 객체를 기억하고, 해당 객체가 DB에서 다시 불려와질 때 변경된 정보가 없다면 굳이 DB를 통하지 않고 영속성 컨텍스트에서 해당 정보를 돌려준다.
  - 캐싱된 객체는 완전히 동일하다 -> 객체의 인스턴스 주소까지 완전 동일

책 생성, 대출, 반납 기능을 개발하면서 전체적인 개념을 다시 잡기도하고 좀 더 객체지향적으로 코딩하는 방법을 알았던 날이다.
되게 좋았던 건 얼마 전에 객체지향의 사실과 오해라는 책을 읽었었는데 사실 책에서는 예시 코드가 나오지 않아 약간 실무에서는 어떤식으로 접근해야할까에 대한 의문이 좀 남아있었다. 책을 읽어도 약간 반만 알겠는 느낌..? 근데 이 강의에서 딱 객체지향적으로 코딩을 해볼 수 있어서 그래도 느낌을 좀 알 것 같았다. 평소 회사에서 전혀 객체지향적으로 개발하지 않아 domain에 비즈니스 로직을 직접 넣어도 되는지 조차 몰랐었는데 이번 강의에서 그 부분에 대한 갈증을 조금 해소할 수 있어서 아주 마음에 들었다.

https://devhan.tistory.com/326
어느정도 개발이 끝났던 시기였던 거 같다. 과제를 하면서 Team과 Employee의 연관관계를 담은 테이블을 강의처럼 따로 만들어야할지 말지 고민이 많았었고 또, Team의 ID를 Long 타입의 id로 하느냐, String 타입의 name으로 하느냐의 고민도 많았다..! Long 타입의 id로 하면 나중에 Employee를 조회할 때마다 Team의 객체를 가져와서 name을 또 Response 객체에 저장해줘야할 것 같은 번거로움 때문에 그냥 String name을 primary key로 지정했다. 코드에 대한 많은 생각을 할 수 있어서 좋은 시간이었던 거 같다.