[내배캠][TIL] 23일 차 - 금요일, 수준별 수업 전부 듣기

 

 

📢 오늘의 목표 📢

✔️ 알고리즘, SQL 문제 풀이
✔️ 알고리즘 코드카타
✔️ SQL 코드카타
✔️ 프로그래머스 Level 2

✔️ 수준별 수업
✔️ 스탠다드 실습 OT
✔️ 스탠다드 이론 이전 강의
✔️ 챌린지 OT

✔️ 개인 과제 개선

 

 

⏱️ 오늘의 일정 ⏱️

9:00 ~ 10:30 - 알고리즘 문제 풀기
10:30 ~ 11:00 - 튜터님 면담
11:00 ~ 12:30 - 수준별 수업 : 스탠다드 실습 OT
12:30 ~ 14:00 - 점심시간
14:00 ~ 17:00 - 수준별 수업 : 스탠다드 이론 이전 강의
17:00 ~ 18:00 - 개인 과제 개선
18:00 ~ 19:00 - 저녁 시간
19:00 ~ 20:00 - TIL 작성
20:00 ~ 21:00 - 수준별 수업 : 챌린지 OT

 

 

📜 Chapter 1. 알고리즘 문제 풀기

✔️ 알고리즘 코드카타

음양 더하기

CodingTest_AutoSave/프로그래머스/1/76501. 음양 더하기 at main · MetroDefro/CodingTest_AutoSave

 

✔️ SQL 코드카타

입양 시각 구하기（1）

CodingTest_AutoSave/프로그래머스/2/59412. 입양 시각 구하기（1） at main · MetroDefro/CodingTest_AutoSave

 

✔️ 프로그래머스 Level 2

기능 개발

CodingTest_AutoSave/프로그래머스/2/42586. 기능개발 at main · MetroDefro/CodingTest_AutoSave

 

튜플

CodingTest_AutoSave/프로그래머스/2/64065. 튜플 at main · MetroDefro/CodingTest_AutoSave

 

 

📜 Chapter 2. 수준별 수업 : 스탠다드 실습, 이론

내가 신청한 반은 아니지만 이번 주차에는 다른 반에도 참여할 수 있었고 당장 할 것도 없어서 슬쩍 도강을 하러 갔다.

✔️ 스탠다드 실습

백엔드 업무 프로세스

1. 요구사항 확인
2. API 스펙 협의
3. API 명세서 작성: URI, Method, Request, Response (+ 예외 케이스). 예외의 경우 http 상태코드로 알려주기도 함.
4. 개발: 상황에 따라 프론트 개발과 병렬적으로 진행하기 위해 Controller 레벨에서 정상응답, 예외응답을 바로 하드코딩으로 리턴하게 만든다.
5. 테스트 및 배포

이 후에는 CRUD를 만드는 라이브 코딩을 하였다.

 

✔️ 스탠다드 이론 - 1회차

이론 반도 강의 내용에 흥미가 있어 꼭 보고 싶었는데 다행히 녹화본과 강의자료를 올려주셨다~

 

Error: 코드로 복구되지 않는 오류

Exception: 개발자가 직접 처리할 수 있는 오류로Compile Exception, Runtime Exception로 나뉜다.

Complie은 Checked Exception으로 컴파일 단계에서 잡아낼 수 있으나 Runtime는 Unchecked Exception으로 아무래도 Runtime 중에 발생하다 보니 잡아내기가 힘들다.

 

try ~ catch ~ finally, throw

try {
	// 예외가 발생할 코드
} catch (Exception) {
  // 예외 발생하면 처리하는 코드
  throw new TestCheckedException("내가 만든 메세지");
} finally {

	// 예외를 발생하던, 안하던 최종적으로 실행될 코드 
	
}

thorws: 나를 호출한 곳에서 예외를 처리해 주십시오...

 

Checked Exception은 thorws, catch를 꼭 써야 하지만 Unchecked Exception은 쓰지 않아도 된다...

그래도 예외가 발생했는데 catch되지 않을 경우 프로그램이 종료되기 때문에 예외 처리를 잘 하자...

 

try-with-resources

자원 반납을 위한 구조라고 한다.

보통 여기서 자원(resource)란 외부의 데이터(DB, Network, File)를 말한다.

그런데 예를 들어 파일을 쓰다가 오류가 발생할 경우 반드시 닫아주어야 하기 때문에 원래는 finally 문으로 파일을 닫았다.

하지만 파일을 닫는 동작도 IOException이 일어날 수 있어서 이 부분도 예외 처리를 해줘야 한다.

이런 불편함을 개선하기 위해 try - with - resource 문이 나왔다.

try (파일을 열거나 자원을 할당하는 명령문) {
     ...
}

try 블럭을 빠져나오는 순간 자동으로 괄호에 대한 close가 호출된다.

 

 

GlobalExceptionHandler

전체 예외를 한 번에 처리할 수 있는 방법이라고 함.

 

 

 

📜 Chapter 3. 개인 과제 개선

1시간 18분...이나 되는 해설 영상을 보니 역시 내가 구현한 거랑 다른 부분이 꽤 보였다.

• 일정 목록 조회 내림차순 정렬하기
• ResponseEntity 사용하기
• Builder 사용하기
• 일정 삭제에서 비밀번호 받는 부분 dto 객체 받는 걸로 변경

나중에 더 추가 될 수도 있지만 일단 오늘 작업할 것은 이거다.

이 중에서 뒤의 두 개는 나도 과제를 진행하며 고민했던 부분이다.

여러 스프링 예제에서 빌더를 사용했던 걸 봤어서 이걸 과제에 추가할까 고민 하다가 하지 않았는데 이 기회에 넣어야겠다.

그리고 비밀번호는 비밀번호만 보내고 싶으면 비밀번호만 있는 dto를 또 따로 만들거나 해야하는 줄 알았는데 그냥 dto 객체에 받아도...상관이 없는 것 같다.

 

상태 코드와 에러 메세지를 위해 응답을 위한 클래스로 dto를 또 한 번 감싸는 것도 흥미로운데 이건 위 기능들을 구현 완료한 뒤 다시 봐보도록 하겠다. 어차피 상태 코드는 ResponseEntity에 있지만 모든 response에 메세지를 달 수 있으니 꽤 편리해 보이는 방법 같았다.

 

✔️ 일정 목록 조회 내림차순 정렬하기

    public List<ScheduleResponseDto> getSchedules() {
        return scheduleRepository.findAll(Sort.by("createdAt").descending())
                .stream().map(ScheduleResponseDto::new).toList();
    }

내림차순 정렬 적용 파라미터 하나만 추가해줬다.

 

✔️ ResponseEntity 사용하기

@GetMapping("/schedule")
@Operation(summary = "선택한 일정 조회")
public ResponseEntity<ScheduleResponseDto> getSchedule(@RequestParam Long id) {
    return ResponseEntity.ok(scheduleService.getSchedule(id));
}

ResponseEntity로 한 번 감싸줬다.

 

✔️ Builder 사용하기

public Schedule toEntity() {
    return Schedule.builder()
            .title(title)
            .contents(contents)
            .charge(charge)
            .password(password)
            .build();
}

@Builder를 엔티티 클래스에 추가해 주고 RequestDto 클래스에서 빌더를 사용했다.

원래 엔티티 클래스에서 생성자에 dto를 받아 만들었던 것인데, 계속 늘어날 dto들 마다 엔티티 내에 생성자를 만드는 것은 나중에 골치가 아파질 것이다. 그래서 확장성을 위해 빌더를 사용하고 엔티티 생성하는 부분을 dto에 위임한 것.

public Schedule update(String title, String contents, String charge) {
    this.title = title;
    this.contents = contents;
    this.charge = charge;
    return this;
}

엔티티는 최대한 dto에 대해 몰랐으면 해서 update 메서드도 이렇게 수정하였다.

 

✔️ 일정 삭제에서 비밀번호 받는 부분 dto 객체 받는 걸로 변경

이건 수정했더니...

그렇다.

유효성 체크를 dto 객체에 해 놓았기 때문에 이런 문구가 나오는 것...

일단 이 부분은 롤백하도록 했다...

 

일단 월요일 재제출까지 시간이 있기도 하니~ 오늘은 여기까지 하자!

 

 

🌙 오늘을 마치며 🌙 

챌린지 수업은 앞으로 뭘 할 지에 대해 OT를 진행하고 끝났다.

오늘도 너무 피곤했는데 잘 버텼다~