[내일배움캠프/백엔드] Spring 숙련. 뉴스 피드 프로젝트 트러블 슈팅

1. Git 충돌 해결

1) 개요

develop 브랜치에서 동시에 작업을 진행하면서 push, pull 하는 과정에서 다른 팀원이 작성한 내용을 pull로 가져올 때, 현재 작업하고 있던 내용과 충돌이 발생

 

2) 문제상황

-모든 작업을 develop 브랜치에서 직접 진행을 하면서 문제가 생김

-작업 중 서로 다른 파일을 수정하면서 충돌이 발생

 

3) 해결

-작업을 개별 브랜치 feature에서 진행하도록 변경

-작업 완료 후, 로컬에서 develop 브랜치로 병합하고, 충돌이 있다면 로컬에서 해결한 후에 git push

-develop이 최신화되면 브랜치를 pull 받아 최신으로 유지하고 다시 feature에서 개발

1. feature 브랜치 생성
git checkout -b feature/<branch-name>

2. 로컬에서 작업 후 병합
git checkout develop
git merge feature/<branch-name>

3. develop이 최신화되면 develop 브랜치 가져오기
git pull origin develop

 

4) 결론

-충돌이 최소화되었고, git branch를 전략적으로 활용하여 협업이 개선되었음

-동일한 문제가 반복되지 않도록 팀원들과 수시로 공유

---

2. 특정 기간 게시물 조회

1) 개요

특정 기간 동안의 게시물을 조회하는 기능을 구현 후 Postman으로 테스트했는데, LocalDateTime을 기준으로 구현하여 클라이언트가 날짜 뿐 아니라 시간까지 입력해야하는 불편함이 있었음

 

2) 문제 상황

 

<처음 작성한 코드>

-클라이언트가 시간까지 정확히 입력해야만 조회가 가능

LocalDateTime startDate = LocalDateTime.parse();
LocalDateTime endDate = LocalDateTime.parse();

 

<변경 후 코드>

-Entity와 다른 코드들이 LocalDateTime을 기준으로 작성되어있었기 때문에, 사용자의 편리를 위해 LocalDate로 구현을 했을 때 기간안의 게시물이 전부 불러와지지 않는 오류발생

LocalDate startDate = LocalDate.parse();
LocalDate endDate = LocalDate.parse();

 

3) 해결

1. 클라이언트의 요청은 LocalDate로 입력받아 날짜만 전달하도록 변경

2. 내부적으로 LocalDateTime으로 변환하여 기존 엔티티와의 호환성 유지

3. LocalDate를 LocalDateTime으로 변환 설정

• 시작날짜 : 00:00:00
• 종료날짜 : 23:59:59

<최종 변경된 코드>

LocalDate startDate = LocalDate.parse();
LocalDate endDate = LocalDate.parse();

LocalDateTime start = startDate.atStartOfDay(); // 00:00:00
LocalDateTime end = endDate.atTime(23, 59, 59); // 23:59:59

 

4) 결론

-클라이언트가 날짜만 입력해도 조회 가능하도록 구현, 내부적으로는 기존 코드와 호환성을 유지해야 한다는 것을 알게됨

-코드를 짜는 것도 중요하지만 사용자의 편의성도 고려해야한다는 것을 알게 되었음

---

3. 페이징 크기처리

1) 개요

클라이언트에서 page와 size를 파라미터를 통해 페이징 요청을 보냈지만, 다른 결과가 나오게 됨

예를 들면 size=10을 요청했는데 20개의 게시물이 반환

 

2) 문제 상황

-컨트롤러에서 Pageable 객체를 생성할 때 기본 값을 명시하지 않아 Spring JPA의 기본 페이지 크기가 적용되어 원하는 크기인 10이 아닌 20개의 게시물이 반환됨

-페이지 크기를 직접 지정해야 할 것 같음

 

3) 해결

-컨트롤러에서 @PageableDefault로 페이지 사이즈를 10으로 설정해두고, 정렬도 작성일 기준으로 조회되도록 설정

@GetMapping
public ResponseEntity<Page<PostResponseDto>> getAllPosts(
        @PageableDefault(
                size = 10,
                page = 0,
                sort = "createdAt",
                direction = Sort.Direction.DESC
        )
        Pageable pageable,
        HttpSession session

){
    validateSession(session);
    Page<PostResponseDto> posts = postService.getAllPosts(pageable);
    return new ResponseEntity<>(posts, HttpStatus.OK);
}

 

4) 결론

-기본 페이지 크기를 명시적으로 설정을 하여 요청한 개수만큼의 게시물이 반환되도록 수정

-조건에 맞는 기본값을 설정하는 것이 중요하다는 것을 깨달음

---

4. 예외처리

1) 개요

예외처리를 Service계층에 수행하면서 HTTP 상태코드와 함께 에러메세지를 전달하려고 하는데 페이지네이션 처리와 동적인 매개변수가 겹치면서 반환타입이 명확해지지 않는 문제가 발생

검색을 통해 <?> 와 같은 제네릭 와일드카드를 사용하면 된다는 것을 발견했지만 이런 방법을 사용할 경우 다른 개발자가 코드를 이해하기 어렵다는 문제가 발생

 

2) 문제 상황

1. 반환 타입 명확하지 않음

-페이지네이션과 동적 매개변수가 겹치면서 반환 타입이 명확하지 않아 <?>와 같은 제네릭 와일드 카드를 사용

-다른 개발자가 반환 데이터를 예측하기 어렵고, 유지보수 시에도 디버깅이 복잡해지는 문제가 있음

 

2. 에러 메세지 전달 부족

-예외처리 시, HTTP 상태코드만 반환한다면 클라이언트가 명확한 에러원인을 파악하기 어려움

-상태코드와 함께 에러메세지를 전달해야함.

 

3) 해결

-<?> 제거 : 와일드 카드를 제거하고 명확한 타입을 지정, if문을 사용하여 예외를 바로 던지면서 메세지도 함께 전달하는 방법으로 변경함

-ResponseStatusException 활용

• ResponseStatusException을 사용하여 에러메세지와 상태코드를 클라이언트에게 함께 전달 할 수 있도록 함
• 클라이언트가 요청 실패 원인을 쉽게 이해할 수 있도록 개선
• 중복된 조건문과 예외처리 로직이 줄어듬

<변경 전 코드>

public ResponseEntity<?> getPostsByUser(...) {
    Page<PostResponseDto> posts = postService.getPostsByUser(userId, pageable);

    if (posts.isEmpty()) {
        return new ResponseEntity<>("해당 사용자의 게시물이 없습니다.", HttpStatus.NOT_FOUND);
    }

    return new ResponseEntity<>(posts, HttpStatus.OK);
}

<변경 후 코드>

public ResponseEntity<Page<PostResponseDto>> getPostsByUser(
        @PathVariable Long userId,
        @PageableDefault(size = 10, page = 0, sort = "createdAt", direction = Sort.Direction.DESC) Pageable pageable,
        HttpSession session
) {
    validateSession(session);

    Page<PostResponseDto> posts = postService.getPostsByUser(userId, pageable);

    if (posts.isEmpty()) {
        throw new ResponseStatusException(HttpStatus.NOT_FOUND, "해당 사용자의 게시물이 없습니다.");
    }

    return ResponseEntity.ok(posts);
}

 

4) 결론

-반환타입을 일치시키면서 명확히 해야 사용자와 개발자 모두 편리하다는 것을 이해하게 되었음

-에러메세지를 전달해야 클라이언트가 요청 실패 원인을 쉽게 파악하고 이해할 수 있으니 예외처리를 할 때 클라이언트와 서버 간의 커뮤니케이션을 고려해야함

-가독성과 유지보수를 위해 코드 중복이 많을 경우 중복을 줄이고 일관성 있는 구조로 작성