Chap 3. 다른 개발자와 코드 계약

[ 오늘 읽은 범위 ]
- 3.3.2 세부 조항에 너무 의존하지 말라

**3.2 체크 및 어서션**

- 3.4.1 체크
- 3.4.2 어서션

[📍 오늘 TIL 3줄 요약 ]

코드 계약으로 코드에 관해 설명하는 것이 더 바람직 할 때가 많다.

세부 조항에 있는 어떤 항목에 대해 발생 자체가 불가능 하도록 명백한 항목으로 바구는 것이 바람직하다.

컴파일러를 사용하여 강제할 수 없다면 런타임 검사(체크, 어서션)으로 확인하는 것이 아닌 것 보다 낫다.

[ 책에서 기억하고 싶은 내용을 써보세요 ]

세부 조항이 많은 코드

class UserSettings{
	UserSettings(){...}
	//이 함수를 사용해 설정이 올바르게 로드 되기 전 까지는 
	//다른 어떤 함수도 호출해서는 안된다.
	Boolean loadSettings(File location){...}
	//init()은 다른 하수 호출 이전에 호출해야 하지만
	//loadingSettings()함수 호출 이후 호출해야만 한다.
	void init(){...}
	//선택된 색상이 없거나, 초기화되지 않았따면 널을 반환한다
	Color? getUiColor(){...}
}

class UserSettings{
	private Usersettings(){...} //생성자가 아닌 create()를 사용하도록

	// 인스턴스를 만들기 위해선 무조건 이 함수를 호출하도록
	static UserSettings? create(File location){
	UserSettings settings = new UserSettings();
	if(!settings.loadSettings(location)){ return null }
	...
	}

	// 클래스의 상태 변경 함수는 전부 프라이빗
	private loadSettings(File location){...}
	private void init(){..}
	Color? getUIiColor(){..}

체크 및 어서션

체크

void init(){
	if(!haveSettingsBeenLoaded()){
		throw new StateException("Settings not loaded")
	}

어서션
성능 향상과 코드 오류 발생률을 낮추기 위해(배포 빌드시 제외되기 때문) 어서션 보단 체크를 선호

Color? getUiColor(){
assert(hasBeenInitialized(),"UserSettings가 초기화되지 않음");)
}

[ 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 ]

평소 레거시 코드나 저품질 코드를 접할 때 과도한 세부 조항들을 많이 접하게 된다는 점이 공감갔다.

구구절절 설명할 필요가 없는 코드가 가장 좋은 코드

[ **궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요 ]**

[ 오늘 읽은 범위 ]

**3.1 자신의 코드와 다른 개발자의 코드**

- 3.1.1 자신에게 분명하다고 해서 다른 사람에게도 분명한 것은 아니다.
- 3.1.2 다른 개발자는 무의식중에 여러분의 코드를 망가뜨릴 수 있다.
- 3.1.3 시간이 지나면 자신의 코드를 기억하지 못한다.

**3.2 여러분이 작성한 코드의 사용법을 다른 사람들은 어떻게 아는가?**

- 3.2.1 이름 확인
- 3.2.2 데이터 유형 확인
- 3.2.3 문서 읽기
- 3.2.4 직접 물어보기
- 3.2.5 코드를 살펴보는 것

**3.3 코드계약**

- 3.3.1 계약의 세부 조항

[📍 오늘 TIL 3줄 요약 ]

다른 개발자들을 고려하지 않고는 고품질 코드를 작성할 수 없다. 코드 자체로 설명하자

코드는 독립적이지 않으며 의존적이고 끊임없이 변화하며 요구사항이 변경되기도 한다.

작성한 코드를 개발자들에게 올바르게 알리기 위해선 이름 잘 짓기 , 정적 언어의 데이터 유형으로 오용 선제 조치 , 문서와 주석문으로 접근. 다만 문서는 완벽히 신뢰하기 어렵다.

추상화 계층은 한번에 몇 가지 개념만 처리해야하고, 어떻게 해결되었는지 정확히 알지 못하더라도 하위 문제에 대한 해결책을 사용할 수 있어야 한다. 개발자가 구현 세부 사항을 읽어야 하면 바람직하지 못한 추상화 계층.

[ 책에서 기억하고 싶은 내용을 써보세요 ]

코드의 계약

어떻게 하면 코드를 사용하는 사람이 코드의 계약을 파악학 따라갈 수 있을 지에 대해 생각해야 한다.

계약 용어

선결 조건 (무언가 입력하거나 설정하도록 하기)

사후 조건 (호출 결과 일어날 일 혹은 반환될 값)

불변 사항

계약의 정의

조건을 명백하게 하는 것이 세부 조항을 사용하는 것 보다 훨씬 낫다. → 타입스크립트!
사람들은 세부 조항을 읽지 않는 경우가 많으며, 대충 흝어 본다는 것을 명심

명확한 부분 : 함수와 클래스 이름, 인자 유형, 반환 유형, 검사 예외

세부 조항 : 주석문과 문서, 비검사 예외