[5주차 개인과제] 익명 게시판 서버 개발

목표

---

5주차 개인과제로 익명 게시판의 API서버를 개발하는 과제를 받았다. 과제를 제출하고 멘토님께서 앞으로 유지해야할 부분과 개선해야할 부분에 대한 몇 가지 피드백을 주셨고, 과제 코드를 리팩토링한 코드와 과제를 수행하며 느낀점을 회고하고자 글을 작성한다. 

GitHub - zzzzseong/sparta_todo_app_backend: 내일배움캠프 Spring 3기 5주차 개인과제 스파르타 익명 게시판

 

과제 피드백

---

1️⃣ 전체적인 코드가 매우 깔끔해서 크게 코멘트 드릴 내용은 없으나, 모든 DTO에 대한 생성 방식이 지금은 AllArgsConstructor를 사용하시는데, 이 보다는 Builder 패턴을 이용할 것을 권장드립니다. 생성자 레벨에 @Builder를 걸 수 있는데, 이는 AllArgsConstructor보다 안전하게 객체를 생성할 수 있습니다.

과제 피드백을 받고 가장 개선해보고 싶다고 생각한 부분이다. DTO가 꼭 필요하지만, 복잡한 로직이나 어려운 개념이 아니었기 때문에 신경을 쓰지 않고 있었던 것 같다. DTO를 개발할때 아무 생각 없이 @AllArgsConstructor, @NoArgsConstructor 등을 남발했었다. 피드백을 받고 간단한 Builder Pattern개념과 DTO 클래스/생성자 레벨의 @Builder 사용법을 정리하면서 앞으로 DTO코드를 어떻게 작성해야할 지 고민해볼 수 있었다.

[Spring] @Builder를 이용한 DTO 생성

 

2️⃣ 별도의 Enum 에러 코드를 정의해서 커스텀 예외 클래스를 구현해주신 것 매우 좋습니다. 실제 저희 백엔드 팀에서도 수강생님이 구현해주신 구조와 같이 예외를 정의해서 활용하고 있습니다.

예전에 프로젝트를 하면서 프론트엔드 개발자분들의 예외처리를 돕고자 구글의 도움을 받아 CustomException을 구현했던적이 있는데 쓰다보니 익숙해져 개발을 할때면 예외처리를 직접 구현해 사용하고 있었다. 내가 사용하는 방식이 맞을까 의심이 드는 순간이 몇 있었는데 멘토님께 이러한 피드백을 받으니 기분이 매우 좋았다.

 

예전에 논리적인 말하기와 MECE라는 개념을 설명하는 글을 본 적이 있는데 겹치지 않고 빈틈이 없는 것이 논리적인 말하기라는 내용이었다. 개발자로서도 중복되는 작업과 코드를 줄이고, 가능한 모든 예외에 대비하는것이 논리적인 코드를 작성하는 길이라고 생각한다. 앞으로도 런타임시 발생하는 예외에 대해 빈틈없이 다룰 수 있는 개발자가 되어야겠다.

 

3️⃣ 트랜젝션에 대한 이해가 있으신 것으로 보입니다. 다만, 조회 시에도 @Transactional(readOnly = true)를 걸어주시면 JPA영속성 컨텍스트를 활용하여 트랜잭션 처리 및 영속화를 시켜주기 때문에 조회 시에도 넣어줄 것을 권장합니다. (물론, 추가적인 과정이 더 생겨서 해당 어노테이션을 넣지 않았을 때 보다는 조회 속도가 느립니다.)

과제의 Service코드에 데이터의 조작이 일어나는 부분에 @Transactional을 붙혀놨는데 그걸 보시고 말씀해주신 것 같다. 멘토님께 좀 서운했다. 사실 클래스 레벨에 @Transactional(readOnly = true)를 작성해놨는데 보지 못하신 것 같다. 하지만, 피드백을 받아서 좋았던게 readOnly를 이용하면 단순히 Transactional이 진행되지 않는다고만 알고 있었지 readOnly를 사용했을 때와 하지 않았을때의 차이점은 인지하지 못하고 있었다. @Transactional(readOnly = true)을 사용하면 메모리, 가독성 등 여러 측면에서 이점을 얻을 수 있다고 한다.