[메모 구현] 리팩토링

• 유저 등록(완료)
• 유저 단건 조회(완료)
• 유저 모두 조회(완료)
• 유저 삭제(완료)
• 서비스 추상화(완료)
• JPA 사용(완료)
• Postman으로 확인(완료)
• H2 사용(완료)
• 엔티티 생성(완료)
• dto 생성(완료)
• REST API(완료)
• 리팩토링(진행중)

 

 

1.  컨트롤러에서 List로 응답하지 말자.

findAll api를 보면 List로 응답한다.

 

 

이렇게 ArrayList형태로 나오게 된다. 즉, 배열로 나온다는 말인데 그러면 유연성이 확 떨어지게 된다.

그럼 Object형태로 나오게 바꾸자.

 

 

이렇게 result라는 필드를 만들고 

 

 

이렇게 바꾸면 배열 형태가 아닌 오브젝트 형태로 감싸서 나오는 것을 확인할 수 있다.

 

 

자꾸 유연성이 떨어진다고 하는데 무슨 뜻일까 ?

좋은 에플리케이션은 좋은 기능을 구현했거나, 보기좋은 UI가 아니다. 지금 잘나가는 네카라쿠베 등 IT기업을 보면 공통점이 있는데,

바로 확장의 용이성을 가지고 있다. 다른 요구사항이 들어와도 유연하게 확장하는 것이 좋은 에플리케이션이라 볼 수 있다.

 

 

2.  복잡한 로직을 컬렉션으로 바꾸자.

기존의 모두 조회하는 로직을 보면 가독성이 떨어지고 다른 개발자들이 볼 때 별로 좋지 않은 코드로 보일 수 있다.

 

 

이제 복잡해 보이는 코드를 간결하게 줄이는 방법을 쓰자. 바로 컬렉션이다.

 

 

누가 봐도 간결해진 것을 알 수 있다. 또한 간결해짐으로써 가독성을 높일 수 있다.

빨간줄을 지우기 위해 MemoResponseDto의 코드를 살짝 변경해 주겠다.

 

 

마찬가지로 detail로직도 컬렉션으로 바꾸어 주도록 하겠다.

 

 

 

3. DTO를 기능적으로 나누자.

기능적으로 나눌 때 무의미한 클래스의 이름도 바꿔주자.

원래 MemoRequestDto는 생성DTO이고 업데이트를 할 때는 다른 DTO를 만들어 요청하는게 더 좋다. 

그럼 나누어주도록 하겠다.

 

먼저 MemoRequestDto의 이름을 CreateMemoRequestDto로 변경하고, UpdateMemoRequestDto를 생성하자.

 

 

그리고 MemoServiceImpl의 update로직에서 CreateMemoRequestDto -> UpdateMemoRequestDto로 변경하고

MemoService, MemoApiController에서도 바꿔주자.

 

MemoServiceImpl

 

MemoService

 

MemoApiController

 

 

4. 예외처리

원래 예외처리는 @RestControllerAdvice를 써서 그 안에 @ExceptionHandler메서드들을 모아놓는 방법 등 확실하게 처리를 해야하지만, 워낙 간단한 CRUD기에.. 간단히 id체크하는 예외만 처리하도록 하겠다. 

 

detail과 update로직은 다 작성되어있기 때문에 delete로직만 바꿔주도록 하자.

 

 

같은 예외는 통일된 메세지로 전달하는게 좋기 때문에 업데이트로직에서 메세지를 바꿔주도록 하자.

 

 

드디어 끝이 났다. 마지막 리팩토링은 굳이 안해도 되는 사이즈의 프로젝트여서 고민을 많이 했지만, 기왕 블로그에 적을 거 끝까지 적어보자는 마음으로 적었다. 많은 개발자들이 강조하면서 하는 말이 있다. 

그냥 알고 대충 넘어가는 것 보다 프로젝트 한 개를 완성하는 것이 백배 더 성장할 것이다.

고작 CRUD였지만, 프로젝트를 완성했다는거에 의미를 두고 앞으로도 계속해서 더 나은 프로젝트를 만들어봐야겠다.

 

 

 

전체코드 링크 : https://github.com/nswon/blog--code