Writing

작업 노트

기술 자체보다 어떤 문제를 왜 그렇게 풀었는지에 초점을 둡니다.

이펙티브 코틀린 아이템 15: 리시버를 명시적으로 참조하라

이펙티브 코틀린(가독성) 아이템 15: 리시버를 명시적으로 참조하라 무언가를 더 자세하기 설명하기 위해 명시적으로 긴코드를 사용할때가 있다. 대표적으로 함수와 프로퍼티 지역 또는 톱레벨 변수가 아닌 다른 리시버로부터 가지고 온다는것을 나타낼때가 있다. 예를 들면 클래스의 메서드라는것을 나타내기 위한 this가 있다. 리시

4 min read

이펙티브 코틀린 아이템 14: 변수 타입이 명확하지 않은 경우 확실하게 지정하라

이펙티브 코틀린(가독성) 아이템 14: 변수 타입이 명확하지 않은 경우 확실하게 지정하라 코틀린은 개발자가 타입을 지정하지 않아도 타입을 지정해서 넣어주는 굉장히 수준 높은 타입 추론 시스템을 가지고 있다. 이는 개발시간을 줄여주거나 코드를 줄여줘서 가독성이 크게 향상 된다. 하지만 유형이 명확하지 않을때 남용하지 말자.

2 min read

이펙티브 코틀린 아이템 13: Unit? 을 리턴하지 말라

이펙티브 코틀린(가독성) 아이템 13: Unit? 을 리턴하지 말라 Unit? 은 Unit 과 null을 반환할수 있다. 하지만 읽을때 오해의 소지가 있으며 예측하기 어려운 오류를 만들수 있다. Unit? 이 붙은 함수가 만들어지면 아래와 같은 코드가 나올수 있다. 이부분은 가독성 측면에서 이해하기 어렵다. 참조

1 min read

이펙티브 코틀린 아이템 12: 연산자 오버로드를 할 때는 의미에 맞게 사용하라

이펙티브 코틀린(가독성) 아이템 12: 연산자 오버로드를 할 때는 의미에 맞게 사용하라 연산자 오버로딩 할때는 항상 신중 해야 된다. 코틀린에서는 각 연산자의 의미는 항상 같게 유지된다. 그래서 오버로딩해서 연산자의 의미를 바꾸면 혼란스럽게 된다. 분명하지 않는 경우 Infix functions(두개의 변수 가운데 오는

2 min read

이펙티브 코틀린 아이템 11: 가독성을 목표로 설계하라

이펙티브 코틀린(가독성) 아이템 11: 가독성을 목표로 설계하라 코틀린은 간결성을 목표로 설계된 언어가 아니다 가독성을 항상 신경쓰자. 개발자가 코드를 작성하는데 1분 읽는데 10분 걸린다. 인식 부하 감소 가독성은 사람마다 다르게 느낄수 있다. 이해하기 쉬운지는 읽는 사람이 얼마나 많은 관용구(구조, 함수, 패턴)에 익

4 min read

이펙티브 코틀린 아이템 10: 단위 테스트를 만들어라

이펙티브 코틀린(안정성) 아이템 10: 단위 테스트를 만들어라 지금 까지 코드를 안전하게 만드는 방법에 대해 이야기 했다 코드를 안전하게 만드는 가장 좋은 방법은 다양한 테스트를 해보는것이다. 단위 테스트의 일반적인 내용 일반적인 유즈케이스(happy path) 일반적인 오류케이스 와 잠재적 문제 에지 케이스와 잘못된 아

2 min read

이펙티브 코틀린 아이템 7: 결과 부족이 발생할 경우 null과 Failure를 사용하라

이펙티브 코틀린(안정성) 아이템 7: 결과 부족이 발생할 경우 null과 Failure를 사용하라 함수가 원하는 결과를 만들어 낼 수 없을때 이러한 상황을 처리하는 방법은 크게 두가지가 있다. null 또는 실패를 나타내는 sealed 클래스를 리턴한다. 예외를 throw 한다 예외는 예외 적인 상황이 발생했을때 사용하는

2 min read