항해99 31일차 TIL1 스프링 심화 주차 코드 리뷰

오늘 기술매니저님께 받은 개인 과제 피드백 내용으로 TIL을 시작하려고 합니다. 코드 리뷰를 받다보면 그 사람이 어떤 생각을 가지고 개발을 하는 사람인지 알 수 있다고 생각하는데요. 피드백 해주신 부분들이 평소에 고민했던 내용들이었습니다. 제가 좋아하는 개발자라는 이야기입니다! 앞으로 기회가 된다면 질문을 드려서 조금 더 괴롭힐 예정입니다...ㅎ

 

1. equals 를 사용하는 자기자신은 항상 null이 아니어야한다.

내가 받은 피드백은 아니었지만 간과하고 있었던 부분이어서 첫번째로 꼽았다.

쉽게 말해 null이 될 수 있는 대상을 equal() 인자로 넣으라는 말이다. 그래야 nullpointException 을 막을 수 있다.

 

2.  boolean 타입의 변수명 작성 팁

existedXXX, isXXX 이런식으로 작성하는게 의미가 명확하다.

 

3. URI 패턴 고민

식별자를 사용할 때, id 보다는 commentId, postId를 더 선호한다. 물론 계층적인 구조이기 때문에 안써도 의미는 파악이 된다. 듣고보니 id 보다는 commentId 처럼 entity 이름을 붙이는게 좋아 보인다는 생각이 들었다. 첫 째는 실무에서는 내 코드를 팀원들도 볼테니 확실한 의미를 가지는 것이 더 많은 사람들이 편하게 이해할 수 있을 것이다. 둘 째는 내가 짠 코드를 매일 모니터링하는 것은 아니기 때문이다. 코드를 오랜만에 보다보면 어떤 생각을 가지고 로직을 구성했는데 잊어버리게 된다. 되도록이면 명확하게 변수명, URI를 작성하자.

 

4. DTO

DTO가 왜 필요한지에 대해 고민이 많았을 때가 있다. 직접 프로젝트를 진행해보니 명확하다.

DTO를 사용하지 않는다면...

1. 엔티티가 가진 것 외에는 넘길 수 없다.

예를 들면 예외에 따른 에러 메시지를 남길 수 없을 것이다. 

2. 엔티티가 가진 것 외에 넘길 수 없으니 엔티티의 변경 가능성 커질 수도 있다.

엔티티의 인스턴스 필드는 DB로 가게되는데 이것은 바람직하지 않을 수도 있다.

3. 필요에 따라 무수한 생성자가 필요하게 될 것이고 때에 따라 빌더나 세터를 사용할수도 있다.

무수한 생성자는 코드의 가독성을 떨어트린다.

빌더는 엔티티만 사용한다고 무수한 생성자를 막을 수 있는 괜찮은 선택지라고 보지만... DTO를 사용하자...ㅎ

세터는 피해야 한다고 생각한다. 엔티티의 외부 변경 가능성, 불완전한 객체 생성 등 문제가 발생할 여지가 존재한다.

 

적다보니 너무 장황한 것 같다. DTO를 사용하는 이유를 한 마디로 정의한다면 엔티티의 불변성을 보장하는 한 편 각각의 API에 맞게 response를 내려주기 위함이다. 적다보니 피드백이 아니라 내 생각을 적게 되어버렸네요

 

돌아와서 매니저님의 DTO에 대한 생각이다. 내가 DTO를 너무 보수적으로 잡고 있었나 보다. 매니저님의 코드를 보니 속이 뻥 뚤렸다. DTO를 잘 활용하자. DTO에 메서드가 존재해도 된다. DTO 를 잘 활용하면 서비스 단의 비즈니스 로직이 깔끔해질 수 있다. 그렇다고 핵심 로직을 DTO에 담으라는 이야기는 아니다.