221212~13 TIL

오늘 배운 것 & 한 일

제네릭스와 Object

항해 5주차 프로젝트에서 공용 Response 클래스를 구현할 때 Object 타입을 사용했었다.

 

그런데 다른 분이 구현하신 Response클래스에서는 Object타입을 사용하지 않고 제네릭스를 사용하였다.

 

생각해보니 제네릭스를 사용하는 코드는 정말 많이 봤지만 Object를 사용하는 코드는 거의 본 적이 없었다. 찾아보니 자바 진영에서도 Object 대신 제네릭스의 사용을 권장하고 있었다.

 

그래서 Response 클래스를 제네릭스 방식으로 바꾸려 했는데 제네릭스와 @Builder를 같이 쓸 때 제네릭스의 타입을 정확하게 명시해줘야 하는 문제가 있었다..!

 

아직은 Builder와 제네릭스를 둘 다 제대로 이해하지 못한 상태라 일단 그 문제를 해결하기 보단 지금은 Object를 사용하고 나중에 찾아보기로 결심했다. 꼭 시간 여유가 생겼을 때 Builder 패턴을 사용하는 이유와 사용 방법, 제네릭스의 사용 방법을 찾아보도록 하자.

 

Commit을 잘게 나누어라

다른 조원 분이 풀 리퀘스트와 관련해서 주신 조언이었다. 

 

Commit은 작은 단위로 나눌수록 좋다. 늘 코드 리뷰어를 고려하여 커밋을 하자.

 

풀 리퀘스트를 하면 그동안 쌓여 있던 커밋들을 한꺼번에 볼 수 있다. 그리고 풀 리퀘스트를 리뷰할 때 해당 풀 리퀘스트의 각각의 커밋들을 하나씩 살펴볼 수 있다. 이때 커밋들이 작은 단위로 나누어져서 각 커밋의 내용을 쉽게 파악할 수 있다면 코드 리뷰가 굉장히 수월해진다.

 

늘 읽는 사람을 고려해서 작업하자. 커밋과 풀 리퀘스트는 코드 리뷰어를 위한 일이다. 

 

외래키와 참조 무결성 제약 조건

관계형 데이터베이스에 FK를 설정하면 참조 무결성 제약 조건이 생긴다. 이 조건은 어떤 테이블의 row를 삭제할 때 그 테이블의 FK를 들고 있는 모든 테이블의 row를 먼저 삭제하도록 강제한다. 그렇기에 참조 무결성 제약 조건을 어기고 잘못 삭제할 땐 DB측에서 자동으로 막아준다. JPA 또한 에러가 나온다.

 

그런데 실무에선 이 제약 조건 때문에 오히려 FK를 제거해야 하는 상황들이 벌어진다. 비즈니스 로직상 참조 무결성 제약 조건을 깨야하는 상황들이 종종 나오는데, 이걸 위해 데이터베이스의 정규화를 포기하는 경우가 많이 생긴다고 한다.

 

실제로 현업에선 이런 일을 미연에 방지하기 위해 대부분의 DB에서 아예 FK 설정을 잘 안해둔다고 한다. 다들 비정규화 데이터베이스를 사용하는 것이다.

 

만약 DB에선 연관 관계가 아닌데 Entity에서만 연관 관계를 만들어서 사용하면 어떻게 될까?? 

 

DDL을 사용하지 않는다면 (그리고 실무에선 전부 DDL을 꺼둔다고 한다) Entity에서만 연관 관계를 만들어서 사용할 수 있기는 하다. 다만 그렇게 할 경우 JPA 작업이 굉장히 복잡해지는 등 여러 가지 부가적인 문제들이 생길 수 있다고 하니 웬만해선 FK도 걸지 말고, 연관 관계도 하지 않은 채로 작업을 하도록 하자.

 

Entity에서 연관 관계를 구현하는 대신 Dto에서 필요한 다른 엔티티의 값을 리스트로 받아오는 형식으로 구현하면 모두가 행복해질 수 있지 않을까..?

 

잘한 점

 

개선할 점