spring 은 전통적으로 http client 로 RestTemplate 을 제공해왔다. 그러다가 webflux 의 등장과 함께 비동기로 동작하는 http client 인 WebClient 라는 모던 http client 를 제공하기 시작했는데, 초기엔 mvc 에서도 이 WebClient 를 이용하는걸 권장했다. 하지만 WebClient 를 이용하기 위해선 webflux 전체에 의존해야하고, reactive 라이브러리인 proejct reactor API 를 사용해야하는 불편함이 있었다. 불편함이라고 썼지만 개인적으론 최악의 경험이었다. 그러다가 spring boot 3.2 에 신규 동기 http client 가 들어왔으니 그게 RestClient 이다. 오늘은 RestClient 를 잘 사용하기 위한..
github 의 Pull Request 를 이용해서 코드리뷰를 하고 있다. 코드리뷰라고 하면 참 좋은데 하다보면 다양한 어려움도 있기 마련이다. PR이 너무 커서 보기 힘든 경우도 있고, 내가 얼른 리뷰받아서 배포해야하는데 리뷰가 늦어져서 답답한 경우도 있다. 좋은 PR과 코드리뷰를 하려면 무엇을 고려해야할까 고민해보다가 나름의 고민결과를 적어본다. # 작은 PR리뷰를 요청하는 개발자는 본인의 변경이니 코드가 눈에 잘 들어오지만, 타인이 작성한 코드를 봐야하는 리뷰어 입장에서는 큰 PR은 검토하기가 쉽지 않다. 그리고 결과적으로 큰 PR은 리뷰어들이 리뷰를 진행하는데 시간을 오래 걸리게 만든다. 이는 리뷰어 입장에서도 고통이지만 얼른 리뷰를 받아야하는 요청자 입장에서도 답답한 상황이 된다. 때문에 개발하..
이번엔 예외처리에 대한 이야기를 해보려한다. 실무에서도 흔히 보이는 방식과 그 방식에서 아쉬웠던 부분도 함께 정리해보고자 한다. # 1개의 Exception 클래스와 error enum실무에서 가장 많이 본 예외처리 방식이다. 대다수가 이런 방식을 사용하고 있을거라고 생각한다.// 예외 클래스 정의@Getterpublic class ApiException extends RuntimeException { private ErrorCode errorCode;}// 에러 코드를 담는 상수 정의, 사용자노출 메시지와 http status 코드를 관리@AllArgsConstructor@Getterpublic enum ErrorCode { ENTITY_NOT_FOUND("엔티티를 찾지 못했습니다.", 40..
- Total
- Today
- Yesterday
- clean code
- frontcode
- java8
- generics
- code
- backend개발환경
- MySQL
- Git
- EffectiveJava
- 정규표현식
- Spring
- servlet
- OOP
- Jackson
- go-core
- java
- TEST
- http
- toby
- programming
- DesignPattern
- Kotlin
- frontend개발환경
- javascript
- spring cloud
- mariadb
- JavaScript Core
- db
- Design Pattern
- JPA
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |