본문 바로가기

전체 글156

Kafka Consumer Retry를 위한 노력 대충 히스토리 설명 consumer에서 이벤트 받아서 처리하는 로직에 써드파티 api를 호출하는 부분이 있는데, 너무 빠르게 호출하는지 자꾸 Throttling Exception 을 뱉는다. 근데 이게 초당 요청을 몇으로 제한하라는 이런 가이드가 없어서, 실패시 retry 하는 방향으로 개선을 해보려고 한다 첫번째 시도 - retryTemplate batch listen(단건으로 말고 레코드 뭉탱이로 들고오는거)을 하고 있어서 retryTemplate 사용 불가능 batch records에서 몇번째 record인지 알 수가 없다고 한다. 실패 두번째 시도 - SeekToBatchErrorHandler 위에서 말했듯이 batch listen을 하고 있어서 여기저기 찾아보다가 스택오버플로보고 시도한 방법이다.. 2022. 6. 25.
12. 상속 다루기 12.1 메서드 올리기 배경 중복된 두 메서드가 미래에는 냄새나는 쓰레기가 될 수 있다. 무언가 중복되었다는 것은 한쪽의 변경이 다른 쪽에는 반영되지 않을 수 있다는 위험을 항상 수반한다. 메서드 올리기를 적용하기 가장 쉬운 상황은 메서드들의 본문 코드가 똑같을 때이다. 절차 똑같이 동작하는 메서드인지 면밀히 살펴본다 메서드 안에서 호출하는 다른 메서드와 참조하는 필드들을 슈퍼클래스에서도 호출하고 참조할 수 있는지 확인한다. 메서드 시그니처가 다르다면 함수 선언 바꾸기로 슈퍼클래스에서 사용하고 싶은 형태로 통일한다. 슈퍼클래스에 새로운 메서드를 생성하고, 대상 메서드의 코드를 복사해넣는다. 서브클래스 중 하나의 메서드를 제거한다. 모든 서브 클래스의 메서드가 없어질 때까지 다른 서브클래스의 메서드를 하나.. 2022. 6. 19.
11. API 리팩터링 11. API 리팩터링 모듈과 함수는 소프트웨어를 구성하는 빌딩 블록이며, API는 이 블록들을 끼워 맞추는 연결부다. 좋은 API는 데이터를 갱신하는 함수와 조회만 하는 함수를 구분한다. 11.1 질의 함수와 변경 함수 분리하기 배경 외부에서 관찰할 수 있는 겉보기 부수효과가 전혀 없이 값을 반환해주는 함수를 추구해야 한다. 이런 함수는 원하는 만큼 호출해도 아무 문제가 없다. 겉보기 부수효과가 있는 함수와 없는 함수는 명확히 구분하는 것이 좋다. 상태를 변경하는 부분과 질의하는 부분을 분리하자 절차 대상 함수를 복제하고 질의 목적에 충실한 이름을 짓는다. 새 질의 함수에서 부수효과를 모두 제거한다. 원래 함수를 호출하는 곳을 모두 찾아낸다. 호출하는 곳에서 반환 값을 사용한다면 질의 함수를 호출하도록.. 2022. 6. 19.
11. DSL 만들기 11. DSL 만들기 invoke 관계를 사용하면 DSL 코드 안에서 람다와 프로퍼티 대입을 더 유연하게 조합할 수 있다. 11.1 API에서 DSL로 궁극적인 목표는 코드의 가독성과 유지 보수성을 좋게 유지하는 것이다. 상호작용을 이해하기 쉽고 명확하게 표현할 수 있게 만들어야 프로젝트를 계속 유지 보수할 수 있다. 깔끔한 api의 특징 이름과 개념을 잘 선택하면 클라이언트가 해당 코드에 대해 어떤 일이 벌어질지 명확하게 이해할 수 있다. 코드가 간결해야한다. 불필요한 구문이나 번잡한 준비 코드가 가능한 한 적어야 한다. 코틀린 DSL은 간결한 구문을 제공하는 기능과 그런 구문을 확장해서 여러 메소드 호출을 조함으로써 구조를 만들어내는 기능에 의존한다. 코틀린 언어의 다른 특성과 마찬가지로 코틀린 DS.. 2022. 4. 28.

티스토리툴바