코드 리팩토링

💡 https://github.com/cjh0412/spring-advanced

1. 예외처리 개선

문제

기존에는 User not found 와 같이 예외 메세지를 문자열로 직접 사용하여, 동일한 예외 문구라도 여러 곳에서 동일한 내용을 작성해야하는 문제가 존재함.

해결방안

• enum을 이용하여 예외 메세지를 한 곳에서 수정, 관리하도록 변경
• CommonErrorCode 로 메세지를 설정

변경 전

public class InvalidRequestException extends RuntimeException {
    public InvalidRequestException(String message) {
        super(message);
    }
}

변경 후

@Getter
public enum CommonErrorCode {

    // InvalidRequestException
    UNREGISTERED_USER("가입되지 않은 유저입니다."),
    TODO_NOT_FOUND("Todo not found"),
    MANAGER_NOT_ALLOWED("담당자를 등록하려고 하는 유저가 일정을 만든 유저가 유효하지 않습니다."),
    MANAGER_NOT_FOUND("등록하려고 하는 담당자 유저가 존재하지 않습니다."),
    TODO_CREATOR_CANNOT_BE_MANAGER("일정 작성자는 본인을 담당자로 등록할 수 없습니다.")
    ;


    private final String message;

    CommonErrorCode(String message) {
        this.message = message;
    }
}

적용 코드

// 기존코드
 User user = userRepository.findById(userId)
 		.orElseThrow(() -> new InvalidRequestException("User not found"));
        
// 수정된 코드       
User user = userRepository.findById(userId)
		.orElseThrow(() -> new InvalidRequestException(USER_NOT_FOUND));

변경 후 장점

• 예외 메세지를 한곳에서 관리하여 코드의 일관성 유지
• 동일한 메세지를 재사용하여 코드의 중복을 줄임
• 코드의 가독성과 유지보수성 향상

2. Response 변환 로직 개선

문제점

• 동일한 response 변환 로직을 반복적으로 사용됨
• service에서 변환 로직을 처리할 경우 service의 책임이 커짐

해결방안

• response 내부에 toDto 정적 메서드를 생성하여 변환 로직을 캡슐화

변경 전

public TodoResponse getTodo(long todoId) {
        Todo todo = todoRepository.findByIdWithUser(todoId)
                .orElseThrow(() -> new InvalidRequestException(TODO_NOT_FOUND));

        User user = todo.getUser();

        return new TodoResponse(
                todo.getId(),
                todo.getTitle(),
                todo.getContents(),
                todo.getWeather(),
                new UserResponse(user.getId(), user.getEmail()),
                todo.getCreatedAt(),
                todo.getModifiedAt()
        );
    }

변경후

• 정적 메서드 생성

public static TodoResponse toDto(Todo todo){
        return new TodoResponse(
                todo.getId(),
                todo.getTitle(),
                todo.getContents(),
                todo.getWeather(),
                new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()),
                todo.getCreatedAt(),
                todo.getModifiedAt()
        );
    }

코드 적용

 public TodoResponse getTodo(long todoId) {
        Todo todo = todoRepository.findByIdWithUser(todoId)
                .orElseThrow(() -> new InvalidRequestException(TODO_NOT_FOUND));

        return TodoResponse.toDto(todo);
    } 

정적메서드의 장점

• toDto 메서드를 재사용하여 코드의 중복을 줄임
• TodoResponse에서 todo가 TodoResponse로 변환하는 과정을 처리하여 service의 역할이 명확해짐
• 코드의 가독성 향상

3. Command 패턴 적용

문제점

• 할일 생성 이라는 기능을 위해서 요청 데이터를 그대로 service로 넘김
• serivce에서 객체를 직접 생성하면서 service의 책임이 커짐

해결방안

• Command를 생성하여 할일 생성에 필요한 매개변수를 정확히 정의
• 객체를 service가 생성하지 않고 command를 이용하도록 변경

변경 전

 @PostMapping("/todos")
    public ResponseEntity<TodoSaveResponse> saveTodo(
            @Auth AuthUser authUser,
            @Valid @RequestBody TodoSaveRequest todoSaveRequest
    ) {
        return ResponseEntity.ok(todoService.saveTodo(authUser, todoSaveRequest));

변경 후

@Getter
@AllArgsConstructor
public class CreateTodoCommand {
    private AuthUser authUser;
    private String title;
    private String contents;

    public Todo toDomain(String weather, User user){
        return new Todo(this.title, this.contents, weather, user);
    }
}


@PostMapping("/todos")
    public ResponseEntity<TodoSaveResponse> saveTodo(
            @Auth AuthUser authUser,
            @Valid @RequestBody TodoSaveRequest todoSaveRequest
    ) {
        CreateTodoCommand command =
                new CreateTodoCommand(authUser, todoSaveRequest.getTitle(), todoSaveRequest.getContents());
        return ResponseEntity.ok(todoService.saveTodo(command));
    }

서비스 코드 수정

@Transactional
    public TodoSaveResponse saveTodo(CreateTodoCommand command) {
        User user = User.fromAuthUser(command.getAuthUser());
        String weather = weatherClient.getTodayWeather();

        Todo newTodo = command.toDomain(weather, user);
        Todo savedTodo = todoRepository.save(newTodo);

        return TodoSaveResponse.toDto(savedTodo);
    }    

장점

• command를 생성하여 클라이언트의 요청과 작업을 명확히 분리 가능
• 객체 생성 을 command로 분리하여 service의 역할을 명확히 함
• 코드의 가독성과 유지보수성 향상

4. 결론

• 대부분의 리팩토링이 가독성, 유지보수성, 재사용성을 향상하는 위주로 진행됨