바닥부터 천천히

스터디/이펙티브코틀린

아이템 6 - 사용자 정의 오류보다는 표준 오류를 사용하라

JSON 형식을 파싱하는 부분에 문제가 있다면 이를 코틀린의 표쥰 오류로 표현하기 어려울 수 있다. 이러한 경우 보통 사용자 정의 오류를 새로 생성해서 사용한다. 하지만 가능하다면, 직접 오류를 정의하지 말고 최대한 표준 라이브러리의 오류를 사용하도록 하자. 표준 라이브러리의 오류는 널리 알려질 규약이기 때문에 다른 사람이 API를 더 쉽게 배우고 이해할 수 있다. 대표적인 예외는 다음과 같다. IllegalArgumentException IllegalStateException IndexOutOfBoundsException ConcurrentModificationException UnsupportedOperationException NoSuchElementException 위 Exception중 Unsu..

스터디/이펙티브코틀린

아이템 5 - 예외를 활용해 코드에 제한을 걸어라

require : 아규먼트를 제한한다. check : 상태와 관련된 동작을 제한한다. assert : 어떤것이 true인지 확인한다. test 모드에서만 작동한다. return, throw와 함께 활용하는 엘비스(Elvis) 연산자 위 블럭을 이용하면 다양한 장점을 갖게 된다. require과 check 블럭을 통해 문서를 통하지 않고도 어느정도 요구사항을 파악할 수 있고 예상치 못한동작을 방어할 수 있게된다. 그리고 스마트 캐스트 기능을 활용할 수 있게 되면서 타입 변환을 적게 할 수 있다. 아래는 스터디를 하면서 구성원들과 이야기한 내용을 정리한 것이다. require 매개변수로 받은 값이 유효한지 검사하는 용도로 사용하는것이 올바른 것 같다. 예를들어 전달받은 Long이 양수여야만 하는지 검사를 하..

스터디/이펙티브코틀린

아이템 4 - inferred 타입으로 리턴하지 말라

코틀린은 타입추론을 지원한다. 이 때 주의할 점이 있다. 먼저 추론된(inferred)타입은 정확하게 오른쪽에 있는 피연산자에 맞게 설정된다. 따라서 슈퍼클래스 혹은 인터페이스로 설정되지 않음을 기억해야한다. 따라서 원하는 타입보다 제한된 타입으로 설정됐다면 명시적으로 타입을 지정해주어야 한다. 외부에 제공하는 라이브러리의 인터페이스 반환 타입을 명시적으로 지정하다 제거해버리면 사용을 하는 쪽에서 문제가 발생 할 수 있다. 따라서 안전을 위해 외부 제공 API를 만드는 경우 반드시 타입을 지정하고, 지정한 타입을 변경하거나 제거하지 않아야 한다. 책에서 나온 예시와 같이 명시적 타입을 제거함으로써 인터페이스 구현체에서 더 이상 Car가 아닌 Ferrari 구현체만 반환하는 인터페이스가 되버린다. 결론 타..

스터디/이펙티브코틀린

아이템 3 - 최대한 플랫폼 타입을 사용하지 말라

코틀린의 주요 기능 중 하나인 널 안정성 덕분에 자바를 사용하면서 자주 보던 NullPointerException을 덜 볼 수 있게 되었다. 하지만 널 안정성 기능이 없는 타 언어(Java, C) 등과 코틀린을 같이 사용하고 코틀린이 다른 언어를 이용하여 사용하는 경우 널 안정성이 보장되지 않아 NullPointerException을 만나게 될 수 있다. 자바의 경우 String 반환 타입에 어노테이션으로 @NotNull 혹은 @Nullable 의 존재 유무로 코틀린에서 String으로 사용할지 String? 으로 사용할지 구분지을수 있다. 하지만 어노테이션이 붙어있지 않다면 기본적으로 nullable 할수 있기 때문에 String? 으로 가정하고 다루어야 한다. 그러니 자바와 코틀린을 함께 사용하는 상..

스터디/이펙티브코틀린

아이템 2 - 변수의 스코프를 최소화하라

가시성 제한 상태를 정의할 때는 변수와 프로퍼티의 스코프를 최소화하는 것이 좋다. 프로프티보다 지역 변수를 사용하는 것이 좋다. 최대한 스코프를 좁게 가지도록 변수를 사용하자. 사용되는 곳에서만 사용될 수 있도록 ex) 반복문 내에서만 존재하는 경우 // AS-IS var user: User for (index in users.indices) { user = users[index] print("User at $index is $user") } // TO-BE for (index in users.indices) { val user = users[index] print("User at $index is $user") } // BEST for ((index, user) in users.indices) { pr..

스터디/이펙티브코틀린

아이템 1 - 가변성을 제한하라

어떠한 요소가 상태를 갖는 경우, 요소의 동작은 사용 방법뿐만 아니라 그 이력에도 의존하게된다. 상태를 갖게 하는 것은 양날의 검이다. 변하는 요소를 표현할 수 있다는 것은 유용하지만, 상태를 적절하게 관리하기 어렵기 때문이다. 이해하고 디버그하기 힘들어진다. 코드의 실행을 추론하기 어려워진다. 멀티스레드 프로그램일 때 동기화가 필요하다. 테스트하기 어렵다. 변경을 다른 부분에 알려야 하는 경우 불편하다. set, map의 key로 사용할 수 없다. hash 값이 변경되면 요소를 버킷에서 찾지 못할 수 있다. 코틀린에서 가변성 제한하기 코틀린은 가변성을 제한할 수 있게 설계되어 있습니다. val → 읽기전용 프로퍼티 가변(mutable) 컬렉션, 읽기전용(immutable) 컬렉션의 구분 데이터 클래스의..

스터디/JPA

AttributeConverter를 이용하여 비정형 데이터 저장하기

들어가며 이번 포스트에서는 Spring Data JPA를 사용하고 관계형 데이터베이스를 사용하는 환경에서 AttributeConverter를 이용하여 비정형 데이터를 저장하는 방법과 주의점에 대해 살펴보고자 한다. 관계형 데이터베이스에서 비정형 데이터를 저장할 일이 있는가? 할 수 있지만 화면에 뿌려줘야하는 view 성격의 데이터 혹은 구조의 변경이 잦은 데이터라면 사용하게되는 경우가 생긴다. MySQL과 같은 관계형 데이터 베이스는 각각의 column에 개별 데이터를 저장하는 방식으로 사용된다. 그러다 보니 비정형의 데이터를 저장할 때 하나의 column에 VARCHAR 형식으로 하나의 String 처럼 저장하여 사용해야한다. 사용법 이 예제에서는 편지를 나타내는 Letter 와 @Entity @Tab..

스터디/클린코드

소프트웨어 악취 - 명령 추상화

소프트웨어 악취를 제거하는 리펙토링을 읽고 내용을 재정리하였다. 명령 추상화로 인한 악취 연산 프로세스를 클래스로 표현하는 경우 발생한다. 연산 클래스라고 부르기도 한다. 문제는 클래스 내부에 연산 프로세스를 나타내는 메서드가 단 하나만 존재할 때 발생한다. 보통 다른 메서드의 내부 도우미 메서드로 사용된다. 다시 말해 클래스 내부에서 메서드로 존재해야 하는 연산이 클래스 자체로 표현된 것이다. 특정 개념의 추상화를 표현한 클래스는 데이터와 함께 관련된 메서드를 캡슐화 해야 하는데 그렇지 않을 때 발생한다. 이로 인해 추상화는 설계의 복잡성이 늘어나고 동일 데이터에 대해 동작하는 메서드가 여러 곳에 분리되어 응집성이 줄어들게 된다. 때로는 연산을 객체로 격상시키는 편이 나을 때도 있다. 원인 보통 객체지..

스터디/클린코드

Gradle TestFixtures 이용하여 테스트 코드 중복 줄이기

Gradle Test Fixture 사용해서 테스트 중복코드 줄이기 Gradle Test Fixture 테스트코드를 작성하다보면 테스트 코드에서도 중복된 코드가 굉장히 많이 발생하게 된다. 대표적인 예로 특정 도메인 객체를 생성해야하는 작업이다. 이러한 코드가 작성하기 어렵지는 않지만 그 양이 적지 않아서 테스트 코드를 작성할 때 시간을 잡아먹는 부분이기도 한다. Gradle 에서 제공하는 Test Fixture 기능을 이용하면 이를 쉽게 해결할 수 있다. 코틀린의 경우 gradle 문법만 달라져서 적용하는데 큰 문제 없었다. 예제코드는 Github 에서 확인할 수 있다. 문제 상황 테스트를 위해 간단하게 2개의 모듈을 가진 멀티모듈 구조를 만들었다. application 모듈이 core 모듈 의존성을 ..

스터디/Kotlin

Resilience4j CircuitBreaker 사용하기

들어가며 Resilience4j는 넷플릭스의 히스트릭스에 영감을 받아 개발된 경량화 Fault Tolerance 라이브러리이다. 그 중 Circuit Breaker(이하 서킷브레이커)를 분석하고 적용하였다. 서킷브레이커의 상태 서킷 브레이커는 유한한 개수의 상태를 가질 수 있는 장치인 FSM(finite state machine)으로 세가지 일반적인 상태와 세가지 특수 상태로 나뉜다. 일반적인 상태는 다음과 같다. CLOSED : 서킷브레이커가 닫혀 있는 상태로 서킷브레이커가 감싼 내부의 프로세스로 요청을 보내고 응답을 받을 수 있다. OPEN : 서킷브레이커가 열려 있는 상태로 서킷브레이커는 내부의 프로세스로 요청을 보내지 않는다. HALF_OPEN : 서킷브레이커가 열려 있는 상태지만 내부의 프로세스..