얼떨결에 개발자

별거아닌 기본인데 자꾸만 헷갈려서 안되겠다.. 내가보려고 써놓는 간단한 정리 @NoArgsConstructor - 기본생성자를 만든다. - public Member() {} @RequiredArgsConstructor - 선언된 모든 final필드가 포함된 생성자를 생성한다. - final이 없는 필드는 생성자에 포함되지 않는다. @Autowired를 사용하지 않고 이렇게 사용하는 것을 권장한다. @RequiredArgsConstructor @Controller public class IndexController { private final PostsService postsService; ... } @AllArgsConstructor - 선언된 모든 필드의 생성자를 생선한다. 만약 DTO클래스 내부에서 ..

코드를 까보다가 이런 주석을 발견했다. 저 method에 진입했을 때 null로 return 시켜서 method를 호출하는 부분에서 exception을 시키는 코드인데, 주석에 저 상태에서 Exception을 발생시키라고 되어있었다. null을 보내는 것 보다 Exception을 발생시키는 것이 좋기야 하겠지만, 저 코드를 실행시켰을 때는 둘의 차이가 없는 것 같아 둘의 차이가 무엇일지 궁금해 찾아보았더니 https://chrisshennan.com/blog/return-null-or-throw-exception-best-practice

내가 관리하는 서비스엔 너무나도 많은 엔드포인트들이 존재한다. 업체 별로 버전을 만들거나 버전을 올리거나.. 하면서 우후죽순으로 생겨난 url들이다..... 그래서 처음엔 비슷한 이름으로 너무 여러 개 있어서 외부로 나가는 API 연동문서 없이는 일할 수 없었지.. 이번에 어떤 프로젝트를 진행하면서 소스를 대대적으로 검토하고 있는데, 이런 쓰이는지 안쓰이는지도 모르는 엔드포인트를 정리할 필요성을 느꼈다. 그렇게 해서 알게된 것은 Spring boot의 어노테이션 @Deprecated 이것은 앞으로 사용하지 않는 소스라는 표시를 하는 것이다. 그렇다고 해서 호출 자체를 막는 것은 아니고 그냥 표시를 해두는 것으로 알고있다. @Deprecated @PostMapping("/v1/deprecated") pub..

허허 지금까지 깃플로우를 조금 잘못쓰고 있었던 것 같다. main hotfix (임시) realease (임시) develop feature (임시) 우리회사는 보통 이렇게 쓰고 있다. 사실 release가 도입된 지는 얼마 되지 않았고 주로 feature > develop > main로 merge하고 있다. 정말 긴급한 상황이 아닌 이상 hotfix는 쓰지 않기 때문에, 또 다행히도 hotfix를 딸 일이 많이 없었어서!! hotfix 사용법을 제대로 몰랐다.... 그래서 제대로 뒷처리(?)를 안해두었더니 지금 ㅠ 그래프가 몹시 이상해졌다..흑 hotfix branch는 master에서 바로 따서 merge하는 것이다. 그렇게 되면 develop에는 이번 수정내용이 반영되지 않은 상태로 있게 된다. 이..

오늘 또 하나 배웠다... 사실 전 부터 배웠는데 오늘 좀 생각을 정리했다...? 여러 번 듣고 여러 번 책에서 본 내용인데도 제대로 개념을 이해 못했던 것이지.... 전 부터 buffer를 한 번 사용해서 빈다 spring Controller에 도달하기 전, filter에서 buffer를 한번 사용하고 빈다.-> Controller에 도달하는 response body가 없다-> Error : Required request body is missing 이럴 때 wrapper 를 사용하는데, 내가 계속 사용했던 것은 ContentCachingResponseWrapper, ContentCachingRequestWrapper class이다. 당연하게 ContentCachingRequestWrapper 를 이용..

filter에서 request값을 빼와 log에도 찍고 MDC에도 넣고.. 다양하게 활용하고 싶었다. 만약 필요한 값이 header에 있는 값이라면? HttpServletRequest.getHeader("header name") 을 사용하여 해결할 수 있다. 그런데 header에 없는 값이라면? HttpServletRequest.getParameter("key name") 을 사용했더니 request로 들어오는 값을 가져올 수 있었다. 이렇게 해서 순조롭게 쓰다가 계속 여러 엔드포인트들에서 null이 찍혀 찾아보았더니 이것은 GET방식에서만 가능하고 POST방식에선..... null로 들어오는 것을 알게 되었다 바보다..🤦‍♀️ POST는 json 형태기 때문에 json은 inputStream으로 rea..

이상하다 이상해.. logback 설정에 따라 console에 찍히는 log가 달라진다. log4j 설정 때문인줄 알았는데 아니었던거지…. 믿을 수 없다…. 이렇게 또 하나 배우네 맨 밑에 부분 어느부분에서 영향을 주는지 모르겠다. 일단 additivity="true" 가 되면 같은 로그가 두번씩 찍히는 것은 알겠다. 일단 얘가 영향을 주진 않는다. log 쌓일 때 특정한 값으로 쌓이게 하기 CONFIG_CODE DEFAULT ${LOGS}/${CONFIG_CODE}.log %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} TEST : [%X{CONFIG_CODE}] - %msg%n 여기서 ${CONFIG_CODE} 값은 MDC에 있는 값을 읽어와 사용한다.

그동안 내가 관리하는 서비스들을 확인할 때 주로 서버에 접속하여 로그를 확인하였다. 회사에 ELK가 도입되기 전 부터 서버로그를 확인하는 것이 습관이 되어서.. 아무래도 서버로그를 확인하는 편이 조금 편하기 때문이다. 그러다가 모든 요청을 한번에 확인해서 전수조사를 해야하는 일이 생겼는데 이때 핀포인트를 확인하면 좋을 것 같아 핀포인트로 확인해보았다. https://pinpoint-apm.github.io/pinpoint/ Pinpoint | Leading Open-Source APM Tweets by Pinpoint_APM Is your application created with PHP? Pinpoint has started to support application written in PHP. Che..

오늘도 평화롭게 try-catch문으로 코드를 짰는데 코드리뷰를 받다가 inputstream을 close하지 않았다는 사실을 알게되었다. 사용했던 resource객체는 마지막에 finally로 반드시 닫아줘야 하는데, 놓쳐버린 것이다..! 이렇게 수동으로 close해야 되는 경우들은 놓치는 일들이 발생한다. 이러한 일을 방지하기 위해 사용할 수 있는 구문 // 기존 try() { //리소스 객체를 사용하는 코드 } catch (Exception e) { e.printStackTrace(); } finally { try() { 객체.close(); } catch(Exception e) { e.printStackTrace(); } } // auto closable try(리소스 객체를 사용하는 코드) { }..

기초적인 것을 오늘 또 하나 배웠다...... 나는 그동안 spring의 영역과 일반 java의 영역을 잘 몰랐는데, 일을 하다가 filter는 spring의 영역이 아니라는 것을 확실히 알게되었다. 예전에 학원다니면서 배웠을 때는 크게 와닿지 않았던 것인데 일을 하며 filter를 직접 만들고 사용해보니 더 확실하게 알게 된 것이겠지. 필터를 사용해야겠다고 생각한 것은 호출되는 URI를 로그에 남기고 싶어서였다. 스프링의 기능중에 있으려나? (이것도 찾아봐야지.) 필터를 통해 로그를 찍고 싶었다. 인증 관련된 다른 것들은 둘째치고, 정리가 안되어 있고 로그보기가 너무 까다로운 서비스들은 개선해야 했으니... 로그를 보기 쉽게 URI를 남기는 작업부터했다. 필터는 요청이 들어왔을 때 dispatcher ..