WOONY's 인사이트

Background 사내 MSA 서버에 들어갈 외부 설정값들은 Spring cloud config 서버에서 중앙 관리하고 있다. 그런데 config 서버가 꽤나 오랫동안 존재했던지라, properties로 관리되는 설정값이 대다수였다. 그런데 YML 파일로 관리했을 때의 이점이 더 많기 때문에, 해당 설정값을 만질 일이 있을 때마다 Properties를 YML로 바꾸자는 것이 사내 컨벤션이었다. 이때 잠깐, 왜 properties보다 YML로 관리하는 게 더 좋을까? 이는 이전 글에서도 언급한 내용이지만 간단히 짚고 넘어가면 계층 구조 → 중복 코드를 줄일 수 있음. 가독성이 좋음(중복코드가 줄어들고 계층이 나뉘니까) 하나의 YML 파일에서 여러 profile을 관리할 수 있음 기존 properties의..

Introduction 현재 사내 대출 관리 시스템을 담당하는 서버에서는 매일 특정 시간마다 대출자에게 reminder 메시지를 보내는 작업을 배치(Batch)를 돌려 수행한다. 그런데 해당 배치 작업 시간과 배포 시간대가 겹쳐, 서버 불안정으로 인해 간혹 배치 작업이 종료되는 상황이 일어나는 것을 발견했다. 이때 왜 수시 배포가 아닌 정기 배포냐면, 글로벌 핀테크 도메인인 우리 서비스의 특성상 해당 국가의 법적 이슈로 인해 수시로 배포가 불가능한 상황이다..(심지어 배포도 개발자, 즉 코드를 짠 사람이 배포하면 안된다..까다롭기 그지 없다) 이로 인한 비즈니스 임팩트가 상당한지라 (리마인더 메시지를 보내지 않게 됐을 때 대출 상환에 문제가 있을 수밖에 없으니) 당장 할 수 있는 조치로 배치 작업 시간대..

Introduction 모든 예제는 github에 올려뒀습니다 예전에 했던 작업에서 클라이언트로부터 날짜값을 받는데 쓰는 requestDTO를 만들었다. 날짜값이 클라이언트로부터 String 타입으로 들어오기에 requestDTO에서는 String으로 받고 서비스 로직에서 String을 LocalDateTime으로 변환하도록 로직을 짰다. UpdateDateRequestWithString package com.woony.core.domain.request; import lombok.AllArgsConstructor; import lombok.Getter; import lombok. import lombok.NoArgsConstructor; @Valid @Getter public class UpdateDa..

Abstract localhost:8080/ 페이지 요청 시 스프링부트에서 리액트 화면을 불러오는 과정에서 Whitelabel Error Page 에러 발생 서버 단 에러 로그 확인 시 MethodArgumentTypeMismatchException와 NumberFormatException이 발생 → 프론트 단의 index.html을 불러오는 과정에서 이슈가 발생 MethodArgumentTypeMismatchException: Failed to convert value of type 'java.lang.String' to required type 'java.lang.Long'; nested exception is java.lang.NumberFormatException: For input string:..

Introduction 지난주에 첫 PR을 올렸다! 책을 참고해 작성한 POST 로직 관련 기능이었다. 기대 반 걱정 반으로 PR을 올렸는데 아니나 다를까 피드백이 줄줄이 달리기 시작했다. 그 중에서 꽤나 인상적인 리뷰가 있었다. nit: How about thinking this? 🙇‍♂️ but, You don't need to fix it now (N)ot (I)mportant, (T)hough Controller(package-web) has a dependency on Service(business logic/package-service) Service(business logic/package-service) has a dependency on DTO(package-web) what is the..

Current status 첫 실무로 기존 프로젝트(프로젝트명 DR)를 개선하는 업무를 받았다. 그러나 기존 프로젝트의 구조가 워낙 복잡한지라.. 일단 형태 자체는 CRUD 기반의 게시판이었기에 책을 참고해가며 클론 코딩하기로 결정했다. 기존 프로젝트 DR 역시 엔티티 클래스와 이에 대응하는 Repository 인터페이스를 갖고 있었다. 책의 진행 흐름(3장)을 보면 프로젝트를 진행할 때 가장 먼저 Posts 클래스와 PostsRepository 인터페이스를 만드는 것을 확인할 수 있다. (여기가 문제의 시작..) 클론 코딩에서 역시 기존 코드에 있는 엔티티 클래스와 Jpa Repository 인터페이스를 만들고 DB와 잘 연동하는지 테스트코드까지 작성을 완료했다. 정리하면 DR 클래스 & DRRepos..

프레임워크에 대해 배울 때, 이것이 무엇인지를 아는 것뿐만 아니라 어떤 원리를 따르는지를 아는 것 역시 중요하다. 아래는 스프링 프레임워크를 이끄는 원리이다. 모든 레벨에서 선택권을 제공한다. Spring은 설계 의사결정을 최대한 늦게 하도록 연기할 수 있게 한다. 예를 들어, 코드를 변경하지 않고 configuration을 통해 지속성 제공자를 바꿀 수 있다. 이는 다른 많은 인프라 문제와 타사 API와의 통합에 대해서도 마찬가지다. 다양한 관점을 수용한다. Spring은 유연성을 포용하며 일을 처리하는 방법에 대한 의견을 제시하지 않는다. 또한, Spring은 서로 다른 관점을 갖는 넓은 범위의 애플리케이션 요구 사항을 제공한다. 이전 버전과의 강력한 호환성을 유지한다. Spring의 진화는 버전 간..

빌더 패턴이란? 디자인 패턴 중 생성 패턴에 해당. 생성 패턴은 인스턴스를 만드는 절차를 추상화하는 패턴이다. 생성 패턴에 속하는 패턴들은 객체를 생성, 합성하는 방법이나 객체의 표현 방법을 시스템과 분리해준다. 생성 패턴에는 중요한 이슈가 두 가지가 있는데 생성 패턴은 시스템이 어떤 Concrete Class를 사용하는지에 대한 정보를 캡슐화한다. 생성 패턴은 이들 클래스의 인스턴스들이 어떻게 만들고 어떻게 결합하는지에 대한 부분을 완전히 가려준다. 즉, 생성 패턴을 이용하면 무엇이 생성되고, 누가 이것을 생성하며, 이것이 어떻게 생성되는지, 언제 생성할 것인지 결정하는데 유연성을 확보할 수 있게 된다. 빌더 패턴은 복잡한 객체를 생성하는 클래스와 표현하는 클래스를 분리하여 동일한 절차에서도 서로 다른..

Our server coding convention: Prefer early return style! 우리 회사의 Coding convention 중 하나로 Code Readability가 있다. 그 중 하나가 “Prefer early return style”이다. boolean someMethod() { if (!someCondition) { return false; } if (!someOtherCondition) { return false; } ...do more work... return true; } 이것만 보면 “그렇구나”라고 말텐데, 실제로 리뷰를 받아보면 느낌이 확 다르다. 이전에 올렸던 글에서 예제로 풀었던 코드를 닐이 직접 리뷰봐주셨다(어디선가 보고 계실 닐..사랑합니다..ㅎ) case ..