item26 : 함수 내부의 추상화 레벨을 통일하라 추상화 계층화 어떤 계층에서 작업할 때 그 아래 수준의 층은 깊게 생각하지 않아도 된다 높은 레벨일수록 단순함을 얻고, 제어력을 잃는다. 추상화 레벨 통일 CS 와 같이 코드또한 계층화가 가능한데, 이를 위한 기본적인 도구가 함수이다. 함수에서 SLA 추상화 레벨 통일 원칙을 통해 추상화가 가능하다. 아키텍처 추상화 아키텍처 수준에서 추상화하여 서브시스템의 세부 사항을 숨겨 상호 운영성과 플랫폼 독립성을 얻을 수 있다. 이는 문제 중심으로 프로그래밍 할 수 있음 모듈을 분리하여 계유의 요소를 숨길 수 있다. item27 : 변화로 부터 코드를 보호하려면 추상화를 사용하라 상수 추상화 val MAX_THREADS = 10 상수를 추출하여 이름을 붙여 관리..

item19 : knowledge를 반복하여 사용하지 말라 프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다 knowledge가 뭘까 넓은 의미로 의도적인 정보 비즈니스 로직 또는 공통 알고리즘 로직은 시간에 따라 변활 수 있다 왜 반복해서 쓰면 안되는데 프로그래밍에서 유일하게 유지되는 것은 "변화한다는 속성" knowledge가 반복되면 변화에 취약하다. 이는 프로젝트의 scalable을 제한하고, fragile하게 한다. 반복되는 부분을 추출하여 재사용성을 높임으로써 해결 이건 반복이 아니에요 추출멈춰 반복처럼 보이는데 사실 알고보니 짜잔 다른 knowledge였습니다 2개의 안드로이드 프로젝트에서 빌드 설정이 비슷하다고 추출하면 안됨 어떻게 판단하지 그럼 비즈니스 규칙..

item 11 : 가독성을 목표로 설계하라 짧은 것보다 익숙한게 읽기 좋다 A는 범용적인 관용구, B는 코틀린 문법의 관용구를 사용하고 있다. /* Style A */ if (person != null && person.isAdult) { view.showPerson(person) } else { view.showError() } /* Style B */ person?.takeIf { it.isAdult } ?.let(::view.showPerson) ?: view.showError() B가 cool 해보일 수 있지만 쉽게 읽을 수 있는 코드가 아니므로 A가 더 가독성이 좋다고 할 수 있다. B와 같은 코드는 수정에도 불리하다. B에서 만약 showError가 null을 리턴한다면 else 에 해당하는 ..

item 1 : 가변성을 제한하라 상태를 제어하는 것은 양날의 검 장점 : 시간의 변화에 따라서 변하는 요소를 표현 단점 : 상태를 관리하는 것은 어려움이 따른다 프로그램을 이해하고 디버그하기 힘들다 가변성이 많아지면 코드의 실행을 추론하기 힘들다 동시성에서 충돌이 생길 수 있다 테스트하기 어렵다 상태 변경에 따라 다른 부분에 알려야하는 경우가 존재 따라서 변할 수 있는 지점은 줄일 수록 좋다. 가변성을 제한하기 위해서 순수 함수형 언어를 사용하는 방법이 있지만 이는 프로그램 작성이 매우 어렵다. 코틀린에서 가변성을 제한하기 위해 property를 변경할 수 없게 하거나 immutable 객체를 만드는 것을 쉽게 할 수 있다. 읽기 전용 프로퍼티 val mutable 객체를 가지고 있다면 내부적으로 변할..