본문 바로가기

개발 일지/TIL

[ #24 ] TIL

✏️ 0520      


Spring 개인 과제 피드백 수정

[ 특강 ] 디버깅


피드백 

 

 

시간이 부족해서 JPA 반영을 못해서 JDBC 상태로 제출했었는데 바로 적어주셨다 ㅎㅎ

 

 

 

피드백 반영~

반영하면서 어려웠던 건 없었던 것 같다

 

+) 의존성 주입 수정 (05/21)

@Service
@RequiredArgsConstructor
public class ScheduleService {
    private final ScheduleRepository scheduleRepository;
    ...
}

 

@RequiredArgsConstructor

필드에 대한 의존성 주입을 자동으로 처리할 수 있게 도와주는 어노테이션

생성자 주입을 간편하게 구현할 수 있다

 

Lombok 라이브러리에서 제공하는 어노테이션 중 하나,

final 필드나 @NonNull 어노테이션이 적용된 필드에 대한 생성자를 자동으로 생성해준다

 

  • 장점
    • 생성자를 명시적으로 작성하는 번거로움을 줄일 수 있고
      필드에 대한 의존성 주입을 자동으로 처리하기 때문에 코드를 간결하게 유지할 수 있다
    • final 필드에 대한 의존성 주입을 처리하는 생성자를 자동으로 생성해서
      객체 생성 시 필수적인 의존성이 제공되지 않으면 컴파일 오류가 발생
      => 의존성 주입의 안정성을 높여준다

 

 

 

처음에 일정 삭제 기능에서 URL 쪽에 비밀번호를 받아넣었는데

그렇게 하는 사이트는 당연히 없고 보안에도 매우 문제가 있으니 바로 수정해봤다

// 일정 삭제 DELETE
@DeleteMapping("/schedule/{id}")
public ResponseEntity<Long> deleteSchedule(@PathVariable Long id, @RequestBody SchedulePasswdDto passwdDto) throws IllegalAccessException {
    Long deletedId = scheduleService.deleteSchedule(id, passwdDto);
    return new ResponseEntity<>(deletedId, HttpStatus.OK);
}

 

password 만 받기 위해 따로 Dto 를 추가

 

// 일정 삭제
public Long deleteSchedule(Long id, SchedulePasswdDto passwdDto) throws IllegalAccessException {
    Schedule schedule = findScheduleById(id);
    checkPasswd(schedule.getPassword(), passwdDto.getPassword());
    scheduleRepository.delete(schedule);
    return id;
}

// Password 가 일치하는지 확인
private void checkPasswd(String password, String passwordDto) throws IllegalAccessException {
    if (!Objects.equals(password, passwordDto)) {
        throw new IllegalAccessException("등록하신 비밀번호와 일치하지 않습니다.");
    }
}

 

여기서 조금 헷갈렸던 건 password 검사할 때 파라미터의 데이터 타입이었다

아무 생각없이 여기서도 Dto 적었다가 빨간줄이 생겨서 어라🤔 했지만

일정 삭제 메서드에서 password만 get 메서드로 불러오니 password 의 데이터 타입인 String 으로

선언해주면 되는 것이었다 ㅎㅎ

 

 

Conteroller 의 return 값을 ResponseEntity 를 활용해보라고 하셔서 찾아봤다

 

 

ResponseEntity 란,

스프링 프레임워크의 일부로, HTTP 응답의 전체 메타데이터를 캡슐화하여 반환하는 데 사용된다

응답 상태 코드, 헤더, 본문을 포함할 수 있으며, 클라이언트에게 보다 세밀하게 응답을 제어할 수 있도록 도와준다

ResponseEntity는 주로 RESTful 웹 서비스에서 사용

 

HttpEntity 클래스를 상속받고 ResponseEnitiy 뿐만 아니라 RequestEntity 도 있다

 

HttpStatus (상태 코드), HttpHeaders (웹서버가 웹브라우저에 응답하는 메시지), HttpBody (데이터값) 를 포함하고 있다

 

에러 코드와 같은 HTTP 상태 코드를 전송하고 싶은 데이터와 함께 전송할 수 있기 때문에

좀 더 세밀한 제어가 필요한 경우에 사용한다고 한다!

제네릭 클래스로 제공되므로, 반환할 데이터의 타입을 명시적으로 지정할 수 있다

 

 

Header 와 Body 의 차이

  • Header
    • HTTP 메시지의 메타 정보를 포함하는 부분
    • 요청하는 헤더는 클라이언트가 서버에서 요청에 대한 추가 정보를 전달하는 데 사용 ( ex: Accept 헤더)
    • 응답 헤더는 서버가 클라이언트에게 응답과 관련된 정보를 제공하는 데 사용 (Content-Type 헤더)
    • 헤더는 키-값 쌍으로 구성되며, 각 키와 그에 대응하는 값을 콜론(;)으로 구분
  • Body
    • HTTP 메시지의 본문 데이터를 포함하는 부분
    • 요청 바디는 클라이언트가 서버에서 전달하려는 데이터를 포함
      주로 POST, PUT 요청 같은 HTTP 메서드를 사용하여 서버에게 전송
    • 응답 바디는 서버가 클라이언트에게 반환하는 데이터를 포함 (HTML문서, JSON데이터, 이미지, 동영상 등)

 

👉 간단하게 정리

HTTP 헤더는 메시지에 대한 메타 정보 포함

HTTP 바디는 실제 데이터 포함

// 일정 작성 POST
    @PostMapping("/schedule")
    public ResponseEntity<ScheduleResponseDto> saveSchedule(@RequestBody ScheduleRequestDto requestDto) {
        ScheduleResponseDto responseDto = scheduleService.saveSchedule(requestDto);
        return new ResponseEntity<>(responseDto, HttpStatus.CREATED);
    }

    // 일정 전체 조회 GET
    @GetMapping("/schedules")
    public ResponseEntity<List<ScheduleResponseDto>> getAllSchedules() {
        List<ScheduleResponseDto> responseDtos = scheduleService.getAllSchedules();
        return new ResponseEntity<>(responseDtos, HttpStatus.OK);
    }

 

요렇게 수정~

 

 

createAt 와 modifiedAt 가 자꾸 null 값으로 들어와서 코드를 다시 다 확인해봤지만

전혀(?) 문제가 없다고 생각했는데 알고보니

 

 

..ㅎㅎ

JPA Auditing 기능을 사용하고 싶다면...!!!

@SpringBootApplication 이 있는 class에 @EnableJpaAuditing 추가 !!!

 

꼭꼭 잊지말자 🫠

 

 

디버깅

 

디버깅은 개발에 있어서 선택이 아닌 필수 ❗
버그는 소프트웨어에 발생한 잘못된 결과나 오류를 말한다

 

디버깅 모드란
디버깅 모드는 개발툴에서 제공하는 디버그를 하기 위한 모드
모드를 사용하게 되면 코드를 한 줄씩 순서대로 실행할 수 있고,
그 시점에 변수의 값 조작 또는 확인할 수 있다

 

개발자가 되려면 디버깅 모드 사용법은 필수로 알아야 하는 내용 !

 

 

점 세개 있는 곳에도 있고

 

 

오른쪽 상단에도 있고

 

 

요기 메뉴란에도 들어가있다

숨은 벌레 찾기 느낌...

 

 

 

 

Breakpoint

멈추고 싶은 코드의 위치를 설정해주는 것

ctrl + F8  /  라인 번호쪽 클릭!

 

 

디버깅을 시작하면 요렇게 디버그 창이 열린다

디버깅 모드를 이용하여 값을 확인하고 무엇이 문제였는지 알 수 있다
조건도 넣기 가능!

 

그리고 특강보면서 제일 신기했던 것

 

고것은 바로

find in files 기능!!

 

아니 이렇게 검색하는 방법이 있었다고!?

단축키는 ctrl+shift+f (윈도우) 이다

 

모르는 사람 없게 해주세요 !!!

이 기능 모르고 모든 파일 들어가서 Ctrl + F 했던 사람.. 나야 나...

 

 

회고

 

다음 단계인 Swagger 도 같이 해보려고 했는데 시간이 생각보다 많이 지났었다

약간의 막힘은 있었지만 오래 걸리진 않았다고 생각했는데 아니었나 보다 😅

'개발 일지 > TIL' 카테고리의 다른 글

[ #26 ] TIL  (0) 2024.05.22
[ #25 ] TIL  (0) 2024.05.21
[ #23 ] TIL  (3) 2024.05.19
[ #22 ] TIL  (1) 2024.05.17
[ #21 ] TIL  (2) 2024.05.14