세번째 발자국

이 글은 자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]를 수강하고 인프런 워밍업 클럽에 참여하여 쓰는 두번째 회고록입니다.

3주차 내용

Day 11 객체지향과 JPA 연관관계(강의 33~36강)

33강

전체적으로 api를 개발할 때 어떤 순서로 짜야하는지 정리할 수 있었다. 그리고 처음부터 강의를 듣지 않고 내가 먼저 구현을 해보고 최태현님은 어떻게 구현을 하시는지 비교해봄으로써 좀 더 집중해서 들을 수 있는 강의였다.

api 개발 순서

1. 요구사항 정확하게 분석

2. API spec 정의

3. 머릿속으로 전체적인 이미지 구상

4. 테이블 설계 (4,5번 할 때 스펠링 틀리는 거 각별히 신경)

5. 엔티티(객체) 구현 & Repository 구현(둘이는 셋트라고 생각)

6. API 스펙에 맞는 dto 만들기

7. controller, service 도 마저 만들기

책 생성 API

• 최태현님과 나의 비교

  • is_return 테이블을 설계할 때 tinyint(1)을 쓰셨다

  • 미리 낱개의 실험 데이터를 가정하고 그려보았다

  • 요구사항을 제대로 파악하고 주석을 쓴다

  • 생성자에 뭔가 고정값이 담긴다거나 파라미터가 너무 많아 보이면 리팩토링 함으로써 깔끔하게 해준다

• '그'의 요구사항 내용

  1. 책 정보를 가져온다.

  2. 대출 기록 정보를 확인해서 대출 중인지 확인한다.

  3. 만약에 확인했는데 대출 중이라면 예외를 발생시킵니다.

  4. 유저 정보를 가져온다.

  5. 책과 유저 정보를 바탕으로 유저 대출 정보에 등록해준다.

• '나'의 요구사항 내용

  1. 유저를 찾는다.

  2. 책정보를 찾는다.

  3. 만약 내가 빌려가려는 책이 이미 다른 사람이 빌렸다면 예외 처리

  4. 요청한 책을 내 이름으로 등록한다

34강

JPA를 쓰는 이유 중에 패러다임을 객체지향적으로 하기 위해서 쓰는 것도 있었다. 그러나, 이전까지의 코드를 살펴보면 절차지향에 가까웠다. 객체들끼리 서로 협력을 하는 것이 아니라 각자의 객체가 스스로 처리했다. BookService에서 반납 기능은 User에서 정보를 가져오고 UserLoanHistroy에서 대출 정보를 가져와 반납으로 처리한다.

이러한 패러다임을 객체지향적으로 바꾸려면 객체 간의 관계가 필요하다. 그 관계를 JPA에서 연관 관계로 표현할 수 있다.

1:1 관계 - @OneToOne

Person이랑 Address 연관 관계 실험

1. 두 개의 테이블에 각각의 연관된 id를 만들어서 실험

[결과]

• address가 주체일 때 address테이블에만 person_id가 저장

• person이 주체일 때 person테이블에만 address_id가 저장

2. 두 개의 엔티티에 전부 mappedBy를 입력해줬을 때

다음과 같이 AnnotationException이 발생한다.

@Transactional이 끝나기 전에 객체를 가져왔을 때 null이 안나오게 하는 해결책 setter로 한 번에 둘로 이어주게끔 하면 된다.

N : 1 관계 - @ManyToOne

@JoinColumn

• 연관관계 주인(owner Entity)에게 쓰는 거

• @Column과 쓰임이 비슷, 필드의 이름을 정할 수 있다.

N : M 관계 - @ManyToMany

사용 X

cascade 옵션

폭포수

관계들이 쭉 폭포수처럼 이어져 있게 하는 개념

orphanRemoval 옵션

• orpthan: 고아

• removal: 제거

연결되어 있던 관계에서 한 엔티티가 없어지면 연결되있던 엔티티의 데이터도 사라지는 개념

Day 12 기본적인 배포를 위한 준비

api구현을 마무리하고 배포를 어떻게 하는지 배웠다. 새롭게 알게 된 내용만 간단하게 추려보았다.

37강. 배포란 무엇인가

배포란 쉽게 말해서 전용 컴퓨터로 코드(우리의 서버)를 옮긴다! 라고 한다. 최종 사용자에게 SW를 전달하는 과정이란걸 알았다.

38강. profile과 H2 DB

내 컴퓨터 로컬에 설치한 mysql을 쓰게 해줬던 것처럼 전용 컴퓨터로 내 코드를 옮겼을때도 똑같은 환경을 만들어 줘야 한다는 것을 알 수 있었다.

그리고 데이터베이스는 데이터가 영구적이기 때문에 테스트로 활용하기엔 불편한 점이 있는데 이를 해결하기 위해 H2데이터베이스를 쓴다는 걸 알 수 있었다.

39~40강. git github

개발 처음 시작할 때 바로 깃과 깃허브부터 접했어서 생소한 개념이 있지는 않았다. 새로 배웠다거나 깨달은 건 두가지였다.

• git push --set-upstream origin main 여태까지 이걸 한번만 하면 다음부터는 git push만 쓰면된다는 걸 모르고 있었다.

• .gitignore언제 생성시켜야 하는지 타이밍을 제대로 알 수 있었다.

Day 13 AWS와 EC2 배포

배포를 통해 localhost에서만 돌아가는 서버를 aws ec2에 배포해 보았다. 이 과정을 혼자 막연하게 부딪히면서 했다면 하루를 온전히 다 투자해야 됐을 것 같다.

네트워크에 대해서 조금 찍먹해 볼 수 있는 경험을 가졌다. ssh, DNS, 인바운드 규칙, IP 같은 키워드를 궁금하게 하는 실습이었다.

Day14, 15 Spring Boot 설정, 버전업 이해하기, 마무리 및 추가 꿀팁 영상

gradle, .yml, 버전업 등을 통해 스프링 프로젝트를 구성하는 요소를 좀 더 이해할 수 있었다. 게다가 마무리에 추가 영상도 있었다. 질문자들에 대한 답을 영상으로 따로 만든 것이었다.

최태현님은 항상 느끼는 거지만 질문에 대한 답을 너무 성실하게 해주신다. 볼 때마다 감탄한다.

미니 프로젝트

프로젝트 레파지토리: https://github.com/hyungjunn/employee-commute

결국 머리에 제일 땀이 많이 나는 건 고민하면서 진행하는 프로젝트인 거 같다. 가장 의미있는 시간이었다. 진행하면서 그리고 다른 사람 코드리뷰를 보면서 느낀 점은 다음과 같다.

• 서비스로직에서의 코드 분리 조금만 복잡한 비지니스 로직을 구현하려고 하면 서비스가 점점 뚱뚱해져서 스스로 느낄 때도 메서드가 여러 일을 하고 있어 알아보기가 힘들어 졌었다. 결국 기본으로 돌아가 객체 지향적인 개념이 너무 중요한 거 같다.

• 연관 관계에 대한 것 JPA를 이 강의를 통해 처음 배웠었다. 또 결국 비판적 사고를 하지 않고 JPA는 연관관계를 무조건 써야 좋은지 알고 프로젝트 하면서 최대한 쓸려고 했었다. 피드백을 듣고 연관 관계가 단점이 많다는걸 이제서야 깨달았다. 연관관계 뿐만 아니라 어느걸 쓸 때 최대한 합당한 이유로 써야하는 습관을 길러야 겠다.

• 일급 컬렉션, 그리고 상황에 따른 변수 선언 서비스 로직에서 코드를 분리할 때 어떤식으로 하는지 보여주셨는데 그게 일급 컬렉션이란 걸 말씀해주셨다. 그리고 도메인 로직에서는 어떠한 값을 담을 것이 필요하면 바로 변수를 새로 선언하는 걸 보여주셨다. 코드를 짤 때 유연해야 된다는걸 너무 크게 느꼈다.

이 외에도 너무너무 많다. 결국 계속해서 고민하면서 코드를 만들고 고치는거 밖에 방법이 없다는걸 느꼈다.

인프런 워밍업 클럽을 참여하지 않았다면 큰일날 뻔 했다. 마침 너무 이론만 배우고 있던 시기라 사이드 프로젝트를 하고 싶었는데 이 스터디를 통해 사이드 프로젝트를 혼자 만들 수 있을 거 같다는 자신감을 조금 높일 수 있어서 좋았다.