회고
Facts(사실, 객관)
- api 테스트 통과
- e2e 테스트 통과
- interceptor 추가중
- 개발환경 재설정중
Feelings(느낌, 주관)
- 개발 속도가 빨라졌다.
- 빨라진 개발 속도를 개발환경 재설정으로 다 날려먹었다.
Findings(배운 점)
- 204 http status code 사용법
- 코드 변경에 대한 의사결정 경험
-> interceptor 추가시 발생하는 장점과 단점을 기반으로 어떤 선택이 더 나은 선택인지 고민해보았음
- gradle/springboot 개발환경 설정
Affirmation(자기 선언)
- 내일 금요일 저녁에 개발을 하겠다.
- 아래의 내용을 완료하겠다.
-> spring devtools를 이용한 re-start 기능 설정
-> "/tasks/{id}" http request 요청시 id를 가지고 task를 확인하는 작업 interceptor에서 수행하도록 수정
-> 메서드 및 클래스에 주석 달기
-> http status code가 204이고 response body를 전달하는경우 테스트
05:44 ~ 06:34
Facts(사실, 객관)
- api 테스트 통과
- e2e 테스트 통과
- interceptor 추가중
-> 간헐적으로 interceptor preHandle 메서드 두번 불리는 문제 확인
-> preHandle 메서드에서 생성한 값 controller 메서드로 넘기는 방법 확인
Feelings(느낌, 주관)
- 50분 개발 / 10분 TIL 작성 사이클을 사용하니 확실히 속도가 빨라진 느낌이다.
Findings(배운 점)
- http post 요청으로 데이터 생성 성공 시 201(CREATED) http status code 사용해야한다.
- http delete 요청으로 데이터 삭제 성공 시 204(NO CONTENT) http status code 사용해야한다.
Affirmation(자기 선언)
- "/tasks/{id}" 요청시 발생하는 코드중복 없애기(id -> task 찾는 작업)
- 메서드 및 클래스에 주석 달기
06:45 ~ 07:35
Facts(사실, 객관)
Feelings(느낌, 주관)
- interceptor 추가시 많은 코드를 수정해야 함
-> interceptor에서 저장된 task에 접근 할 수 있도록 TaskRepository를 새로 추가해야함
-> task가 없는 경우 RuntimeException을 발생시켰는데 해당 예외를 없애야 할 수도 있을것 같음
-> 현재 "/tasks/{id}" GET PUT PATCH DELETE 만 가능함
-> "/tasks/{id}" 아래의 경로와 처리해야하는 http method가 지속적으로 늘어난다고 가정
-> 기존의 코드를 그대로 두는것보다 interceptor에서 한번에 처리하는것이 효율적이라고 판단
-> TaskRepository를 TaskController에서 분리하는 작업은 지금 수행하지 않더라도 언젠가는 꼭 필요한 작업이라고 판단
Findings(배운 점)
- 코드 변경시 부수적으로 더 많은 코드 변경이 일어날 수 있음
- 초반에 모든 코드 변경 사항을 알 수 없으므로 중간에 다시 한번 판단할수 있게 하는 프로세스가 필요함
- interceptor의 preHandle메서드가 두 번 불리는 이유 파악
-> 프론트엔드의 axios가 필요한 Http Request를 보내기 전에 Option http method로 Http Request를 먼저 보내기 때문
- interceptor에서 생성한 데이터 컨트롤러로 넘겨주는 방법 확인
-> HttpServletResponse의 attribute로 저장하여 넘겨줌
Affirmation(자기 선언)
- "/tasks/{id}" http request 요청시 id를 가지고 task를 확인하는 작업 interceptor에서 수행하도록 수정
- 메서드 및 클래스에 주석 달기
- http status code가 204이고 response body를 전달하는경우 테스트
21:04 ~ 21:54
Facts(사실, 객관)
- TaskController에서 Task 데이터 처리 코드 TaskRepository로 분리
- interceptor에서 path variable을 가져오는 방법 확인 중
Feelings(느낌, 주관)
- 갑자기 스프링을 작동시키는 설정이 intellij에서 사라졌다.
-> vscode로 변경할지 고민중에 있다.
Findings(배운 점)
Affirmation(자기 선언)
- "/tasks/{id}" http request 요청시 id를 가지고 task를 확인하는 작업 interceptor에서 수행하도록 수정
- 메서드 및 클래스에 주석 달기
- http status code가 204이고 response body를 전달하는경우 테스트
22:09 ~ 22:59
Facts(사실, 객관)
- ./gradlew 명령으로 스프링 동작 할 수 있도록 하였음
Feelings(느낌, 주관)
- 애초에 자바를 좋아하지도 않았지만, 점점더 자바/스프링에대한 개발 경험이 안좋아지는 느낌이다.
Findings(배운 점)
- spring boot를 터미널에서 어떻게 작동시키는지 알게 되었다.
- 기존의 ./gradlew run이 제대로 작동하지 않는 문제의 원인을 알게되었다.
-> 래포지토리에 설정되어 있는 gradle/jdk버전과 로컬의 gradle/jdk 버전의 차이로 생기는 문제였음
Affirmation(자기 선언)
- spring devtools를 이용한 re-start 기능 설정
- "/tasks/{id}" http request 요청시 id를 가지고 task를 확인하는 작업 interceptor에서 수행하도록 수정
- 메서드 및 클래스에 주석 달기
- http status code가 204이고 response body를 전달하는경우 테스트