각 아이템 별로 단락을 분리하였음

• 가변성을 제한하라

  • var 보다는 val을 이용하자
  • 읽기 전용인 list를 다운캐스팅하여 mutableList로 변경하는 행위는 하지말자!! → 버그 발생 가능성이 농후하며 add 와 같은 함수는 구현되어 있지 않다

• 변수의 스코프를 최소화 하라

• 플랫폼 타입(xxx!로 리턴됨)은 null check를 해야 한다

• 리턴 타입이 명확하지 않은 경우에는 노출하라 → 정보를 은닉하지 마라

• 예외 블록를 활용하라

  • require: 함수의 아규먼트가 조건을 만족하지 못할 때 사용
  • check: 상태가 올바른지 확인하기 위해 사용
  • assert: 테스트 용도
  • 직접 오류를 정의하기 보다 최대한 표준 오류를 이용하라

• Not null assertion(!! 연산자) 는 최대한 사용하지 마라

  • 확실한 경우에만 사용하라

• Let은 가독성을 향상 시키거나 Nullable 프로퍼티 처리를 위해 써야한다

• @DslMarker 어노테이션은 가장 가까운 리시버만 사용 가능하도록 막아버린다

• 디폴트 아규먼트를 가지는 경우 나머지 변수를 이름 있는 아규먼트를 써서 명시적으로 보여주는게 좋다

  fun A(a: String, b: String = "c")
  A(a = "b")
  

• 코드가 반복 될 때 비즈니스 규칙이 서로 다른 곳에서 왔다면 독립적으로 변경될 가능성이 있다

• Generic은 기본이 Nullable이다 NotNull로 만들고 싶다면 **<T: Any>**로 제한해야 한다

• 함수는 기본적으로 아규먼트는 반 공변, 리턴에는 공변이 적용된다

• Generic 가장 뒤에 where 를 이용하여 둘 이상의 제한 조건을 걸 수 있다

• 테스트 코드를 작성하기에는 인터페이스 페이킹이 클래스 목킹보다 간단하다

• 버저닝할 때 Major가 증가할때는 Minor와 Patch는 0으로, Minor가 증가할 때는 Patch는 0으로 둔다

• 외부 API의 응답은 한번 랩핑해서 사용하는 것이 좋다

  • 내 도메인 객체가 오염되는 현상을 방지하고 에러 지점을 정확히 외부로 한정할 수 있다

• 생성자 대신 팩토리 함수(패턴)를 사용하라

  • 일반적으로 대상 객체의 Companion 으로 선언하여 정적 팩토리 함수를 만들도록 하라
  • from, of, valueOf와 같은 일반적인 이름을 사용하라

• 상속보다는 위임 패턴(mixin)을, 그보다는 합성을 사용하라