2022.05.25 기록장

ToDo

• 이펙티브 코틀린

Done

• 이펙티브 코틀린
• 검색어 로그 저장
• 기획 확인 (포인트 다운그레이드 확인)

Weekly goal

• 피드백 정리
• 회고

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

- 변하는 상태가 있으면 프로그램의 이해와 디버그가 힘들어짐, 테스트가 힘듬, 멀티스레드 동기화, 상태 변경시 추가 작업 필요 -> 불변 객체로 작성하자
- 읽기 전용 컬렉션을 다운 캐스팅해서 사용하지 말자 -> 굳이 해야한다면 copy해서 사용하자
- 해시맵은 처음 상태를 기반으로 버킷을 정하기에 나중에 내부의 값이 바뀌면 찾지 못한다

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

- 프로퍼티보다는 지역 변수를 사용하는 것이 좋다
- 최대한 좁은 스코프를 갖게 하라
- 람다는 변수를 캡처한다. 해당 값을 필드로 같는 final 클래스로 만드는데 시퀀스는 지연 계산되기 때문에 내부 람다 변경의 최종 값이 사용되었다

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

- 코틀린은 다른 언어에서 넘어온 타입을 특수하게 다룬다 -> 플랫폼 타입 -> nullable인지 알 수 없는 타입

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

- 타입 추론을 반환하면 타입이 고정될 수 있다 -> 사용자가 부모타입이 아닌 자식으로 반환할 수 있기 때문

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

- 코틀리은 여러 예외 발생 블록을 제안한다
- require 블록 : 아규먼트를 제한할 수 있다
- check 블록 : 상태와 관련된 동작을 제한할 수 있다
- assert 블록 : test에만 돌아감. 어떤 것이 true인지 확인할 수 있다
- return 또는 throw와 할께 활용하는 엘비스 연산자

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

- 적절한 오류가 없을 때는 만들지만 많은 개발자가 알고 있는 표준 오류를 사용하자

결과 부족이 발생하는 경우 null과 failure를 사용하라

- null 또는 실패를 나타내는 Failure라는 이름이 붙은 class를 리턴한다.
- 예상되는 오류는 null이나 Faulure를 사용하자. 예외는 비용이 많이 든다.
- try catch 블록 내부에 코드를 배치하면 컴파일러가 할 수 있는 최적화가 제한됨
- null과 result는 명시적으로 처리해야함
- list의 get과 getOrNull을 생각하자.

아이템8 적절하게 null을 처리하라

- elvis에는 return이나 throw가 들어갈 수 있다.
-  위는 방어적 코딩이 였다면 이전 아이템5에서본 check나 requre는 공격적 코딩이다. 사용자에게 직접 알려주는 것이다.
- 공격적 코딩은 특정 값이 예상을 벗어나면 안되는 경우에 사용할 수 있다 (!!,requireNotNull, check 등)
- Delegates.notNull()은 프리미티브 타입의 lateinit이라고 보면된다​

아이템9 use를 사용해서 리소스를 닫아라

- autoClosealble을 상속받은 애들은 use를 사용해 닫자​

아이템11 가독성을 목표로 설계하라

- 가독성 측면이나 앞으로의 수정을 생각한다면 ifOriginal이 더 가독성이 좋다​

아이템13 Unit?을 리턴하지 말라

- Unit?은 Boolean 반환과 동일함. 가독성을 낮춤​

아이템16 프로퍼티는 동작이 아닌 상태를 나타내야 한다

- var를 통해 읽고 쓸 수 있는 프로퍼티는 파생 프로퍼티라고 한다
- 프로퍼티는 본질적으로 함수이다
- 프로퍼티 getter에 많은 로직을 담지 말라​

GitHub - ChoiGiSung/Effective-Kotlin