인프런워밍업스터디_BE_0기 2주차 발자국

2주차 학습 내용 요약

6일차 스프링컨테이너의 의미와 사용방법

6일차 스프링 컨테이너의 개념 미션 수행

강의에서는 스프링 빈과 컨테이너 개념에 대해 알아보았다.

@Component @Bean 어노테이션을 넣으면 해당 클래스가 런타임 시에 스프링컨테이너에 등록을 하게 된다는 점을 배웠다.

인스턴스화를 자동화 해준다는 느낌이다.

미션으로는 기존의 코드를 Controller - Service - Repository 로 코드를 분리시켜서 리펙토링하는 것이 미션이였다.

리펙토링하는 코드를 작성 할 때 Controller 클래스가 기존에 작성한 코드에 종속되어 있어서 api를 호출 할 때마다 오류가 났었다.

그래서 아예 새로운 Controller 클래스를 만들었다.

7일차 JPA를 왜 사용하는가_어떻게 JPA 사용하는가

JPA에 대해 학습하고, 기존 코드를 JPA로 리펙토링하는 것을 미션으로 수행했다.

아직은 왜 정확히 sql 쿼리문에 JPA를 사용하는지 납득이 되지 않는다.

JPA를 사용할 때 제일 큰 장점은 유지보수성을 높여준다는 것이라고 한다.

객체지향 구조 사용해 이미 만들어진 객체를 활용할 수 있다. sql쿼리문으로 db 테이블마다 crud sql문들을 다 작성해야 하지만 jpa 코드는 기존에 만들어진 메서드와 엔티티 객체를 사용해서 중복을 줄이고 유지보수 하기도 편해진다고 한다.

🤔 몇 만줄 되는 복잡한 코드를 유지보수 해본 경험이 없으니 JPA의 이점에 대해 납득하지 못하는 것 같다.
직접 프로젝트를 진행하면서 JPA를 사용하는 것과 사용 안하는 프로젝트를 비교를 해볼 수 밖에 없겠다.

그리고 직접 코드를 작성 했을 때는 JPA 코드가 sql 쿼리문에 비해 직관적이지 않았다.

JPA repository 인터페이스의 메서드들을 직접 코드를 사용하기 전까지는 무슨 뜻인지 알 수 없었다.

🤔이 부분은 아직 JPA코드를 많이 작성 해보지 않아서 생기는 문제인 것 같다.
최대한 다양한 JPA 코드를 작성해보자.

8일차 트랜잭션이 무엇이고_왜 사용해야 하는가

🔥 데이터베이스는 원자성 속성을 보장하지 않습니다. 여러 데이터베이스 작업이 "전부 아니면 전무" 기준에 따라 하나의 원자 단위로 실행된다는 보장은 없습니다. 일련의 작업에서 한 번 작업이 실패하면 데이터베이스는 계속해서 다음 작업을 실행합니다

https://www.java4coding.com/contents/oracle/oracle-transaction)

트랜잭션을 사용해야 데이터베이스의 원자성을 회복시킬 수 있다.

예를 들자면 이런 식이다.

유저를 등록하고 해당 유저에 대한 반납 기록 저장하는 sql로직을 둘을 동시에 해야 되는데, 트랜잭션을 사용하지 않으면 유저는 등록했는데 반납 기록이 저장되지 않는다거나 반납 기록만 저장되서 DB 저장에 문제가 생길 수 있다.

@Transaction을 사용한 코드는 한쪽 sql 로직이 이루어지지 않으면 다른 로직도 롤백시키는 일을 해준다.

🤔 생각해보면 트랜잭션을 사용하지 않으면 있어야 될 내용이 DB에 없거나, 없어야 될 내용이 있는 등 끔찍한 일이 벌어질 게 뻔하다.
정말정말 트랜잭션을 중요한 내용인 것 같다.

9일차 조금 더 복잡한 기능을 API로 구성하기

libraryapp에 반납기능과 책 대출 기능을 만드는 것을 실습했었다.

show tables 는 sql문은 해당 데이터베이스 안에 어떤 테이블이 있는지 알려준다.

🤔 show tables 를 정말 자주 사용했다.
테이블 삭제, 생성, 구조 변경 코드도 많이 사용했던 것 같다. 왜 일까?
쿼리문 여러개를 동시에 실행하다보니 비슷한 이름의 테이블이 중복되서 만들어지는 일이 많았다. 그래서 데이터베이스에 어떤 테이블이 있는지 확인하는 코드가 필요했다. 그래서 use tables
또 다른 DB 관련 문제로는 같은 이름을 지닌 책이 중복해서 등록이 되거나 같은 이름을 가진 유저가 중복되서 등록되는 일이 벌어지기도 했었다.
이 문제는 나중에 이름 부분을 unique key로 등록해서 중복 등록을 방지하는 것으로 해결했다.

간단한 ERD를 먼저 그려보고 코딩을 하거나, DB 설계 내용을 그림에 먼저 그려 보고 나서 코딩을 했다면 이렇게 복잡해지지 않았을 것 같다.

정리

뭔가 미션을 수행하면 시간이 없어서 허겁지겁 끝내는 느낌이다.

시간이 없다면 최대한 미션에서 명세한 기능만이라도 만들어서 코드를 제출하던가 해야되는데 뭔가 쓸떼 없는 일에 집착하다가 늦어지는 것 같다.

무작정 코드를 짜게 되면서 문제가 생기는 경우도 많은 것 같다.

erd를 그려본다거나 간단한 코드라도 종이에 먼저 어떻게 코드를 작성할지 써보고 코드를 작성하는 습관을 만드는 것이 좋을 것 같다.

이런 나의 생각과 느낌을 최대한 넣어서 작성하는 회고도 좋지만,
정량적인 지표들(코드 작성 시간, 미션 수행에 들어간 시간 측정, 미션 수행 난이도, 등)을 이번 주에 대해 최대한 객관적으로 평가해볼 필요가 있을 것 같다.
내가 아닌 제3자의 피드백도 필요하다.