가변성을 제한하라 상태를 구현하는 방법 var 프로퍼티 사용 mutable 객체 사용 (MutableList, MutableSet 등) 상태를 가질 때 문제점 상태를 추적해야되기 때문에, 프로그램을 이해하고 디버그하기 힘들어진다. 시점에 따라서 값이 달라질 수 있으므로, 코드의 실행을 추론하기 어려워진다. 멀티스레드 프로그램일 때는 적절한 동기화가 필요하다. 모든 상태를 테스트해야 하므로, 테스트하기 어렵다. 상태 변경이 일어날 때, 이러한 변경을 다른 부분에 알려야 하는 경우가 있다. 코루틴: 프로그램의 실행 흐름을 일시적으로 중단하고, 나중에 중단한 시점부터 실행을 재개할 수 있는 멀티 태스킹 기법....
하나 이상의 처리 단계를 가진 경우에는 스퀀스를 사용하라 시퀀스 처리 함수들을 사용하면, 데코레이터 패턴으로 꾸며진 새로운 시퀀스가 리턴된다. 컬렉션 처리 연산은 호출할 때 연산이 이루어지는 반면, 시퀀스 처리 함수는 최종 연산이 이루어지기 전까지는 각 단계에서 연산이 일어나지 않는다. 시퀀스의 지연 처리 장점 자연스러운 처리 순서를 유지한다. 최소한만 연산한다. 무한 시퀀스 형태로 사용할 수 있다. 각각의 단계에서 컬렉션을 만들어 내지 않는다. 순서의 중요성 시퀀스 처리는 요소 하나하나에 지정한 연산을 한꺼번에 적용한다. element-by-element order 또는 lazy order라고 부른다....
최적화를 초기 단계에서부터 하는 것은 얻는 것보다 잃는 것이 많은 경우가 많다. 가독성과 성능 사이에서 트레이드 오프가 발생할 때, 개발하는 컴포넌트에서 무엇이 더 중요한지 스스로 답할 수 있어야 한다. 불필요한 객체 생성을 피하라 객체 생성은 언제나 비용이 들어간다. JVM에서는 하나의 가상 머신에서 동일한 문자열을 처리하는 코드가 여러개 있다면, 기존의 문자열을 재사용한다. Integer나 Long처럼 박스화한 기본 자료형도 작은 경우에는 재사용한다. (기본적으로 Int는 -128~127 범위를 캐시해 둔다.) 객체 생성 비용은 항상 클까?...
상속보다는 컴포지션을 사용하라 간단한 행위 재사용 재사용을 위해 상속을 사용했을 때 단점 상속은 하나의 클래스만을 대상으로 할 수 있다. 상속을 사용해서 행위를 추출하다 보면, 많은 함수를 갖는 거대한 BaseXXX 클래스를 만들게 되고, 굉장히 깊고 복잡한 계층 구조가 만들어진다. 상속은 클래스의 모든 것을 가져오게 된다. 따라서 불필요한 함수를 갖는 클래스가 만들어질 수 있다. 인터페이스 분리 원칙 위반 상속은 이해하기 어렵다. 작동 방식을 이해하기 위해 슈퍼클래스를 여러 번 확인해야 한다. 재사용을 위해 컴포지션을 사용했을 때 장점 코드의 실행을 더 명확하게 예측할 수 있다....
생성자 대신 팩토리 함수를 사용하라 팩토리 함수: 생성자 역할을 대신 해주는 함수 팩토리 함수의 장점 생성자와 다르게, 함수에 이름을 붙일 수 있다. 생성자와 다르게, 함수가 원하는 형태의 타입을 리턴할 수 있다. 또한 인터페이스 뒤에 실제 객체의 구현을 숨길 수 있다. 생성자와 다르게, 호출될 때마다 새 객체를 만들 필요가 없다. 싱글턴 패턴, 캐싱 메커니즘 팩토리 함수는 아직 존재하지 않는 객체를 리턴할 수도 있다. 객체 외부에 팩토리 함수를 만들면, 그 가시성을 원하는 대로 제어할 수 있다....
추상화: 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것 복잡성을 숨기기 위해 사용되는 단순한 형식 객체는 여러 형태로 추상화해서 표현할 수 있다. 추상화를 하려면 객체에서 무엇을 감추고 무엇을 노출해야 하는지 결정해야 한다. 프로그래밍에서는 다음과 같은 목적으로 추상화를 사용한다. 복잡성을 숨기기 위해 코드를 체계화하기 위해 만드는 사람에게 변화의 자유를 주기 위해 함수 내부의 추상화 레벨을 통일하라 계층이 잘 분리되었을 때 장점 어떤 계층에서 작업할 때 그 아래의 계층은 이미 완성되어 있으므로, 해당 계층만 생각하면 된다....
knowledge를 반복해서 사용하지 말라 프로젝트에세 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다. knowledge knowledge: 의도적인 정보 프로젝트를 진행할 때 정의한 모든 것 알고리즘의 작동 방식, UI의 형태, 우리가 원하는 결과 등 knowledge는 코드, 설정, 템플릿 등으로 표현할 수 있다. 프로그램에서 중요한 knowledge 두 가지 로직: 프로그램이 어떤 식으로 동작하는지와 프로그램이 어떻게 보이는지 공통 알고리즘: 원하는 동작을 하기 위한 알고리즘 비즈니스 로직은 시간이 지나면서 계속해서 변하지만, 공통 알고리즘은 한 번 정의된 이후에는 크게 변하지 않는다....
가독성을 목표로 설계하라 개발자는 어떤 코드를 작성하는 것보다 읽는 데 많은 시간을 소모한다. 인식 부하 감소 기본적으로 ‘인지 부하’를 줄이는 방향으로 코드를 작성해라. 구현 A가 훨씬 가독성 좋은 코드다. 일반적인 관용구를 사용해서 이해하기 쉽도록 작성해야된다. 구현 A가 수정하기 더 쉽고, 디버깅도 간단하다. 구현 B는 showPerson() 호출에 null이 발생하면, showError()도 호출된다. 이처럼 잘못된 동작이 발생할 수 있다. 극단적이 되지 않기 위의 내용이 ’let은 절대로 쓰면 안 된다’를 의미하는 것은 아니다. let을 사용하면 좋은 경우 nullable 가변 프로퍼티의 안전 호출이 필요할 때 연산을 아규먼트처리 후로 이동시킬 때 데코레이터를 사용해서 객체를 랩할 때 인식 부하 비용이 발생해도 지불만한 가치가 있는지 고려해야된다....