[리뷰#2] 좋은 코드, 나쁜 코드

http://www.yes24.com/Product/Goods/109366833

구글 엔지니어가 말하는 좋은 코드 작성법

좋은 코드를 작성하기 위한 이론과 실전을 소개한다. 단순히 해야 할 일과 하지 말아야 할 일을 나열하기보다, 여섯 가지 원칙을 바탕으로 각 개념과 기술의 장단점, 그리고 이면의 핵심 논리를 설명한다. 책에서 설명하는 즉시 사용 가능한 수십 가지의 기술을 익힌다면, 숙련된 프로그래머의 사고법과 코드 작성의 노하우를 이해할 수 있다. 효과적인 테스트 방법도 설명하므로 더 나은 코드를 작성하는 데 도움을 줄 것이다.

 

좋은 코드 작성법에 대한 것을 소개합니다. 총 3부로 이루어져 있으며, 각각은 다음과 같습니다. 

 

1부: 소프트웨어 엔지니어로서 코드를 작성하는 우리의 접근 방식을 형성하는 일반적이고 이론적인 몇 가지 고려사항의 기초

2부: 코드 품질의 처음 다섯 개 핵심 구성에 대해 구체적인 기술과 예

3부: 효과적인 단위 테스트 코드 작성을 위한 주요 원칙과 실제적 지침 

 

책을 읽으면서 기억에 남는 부분들을 정리해 보았습니다. 요긴하게 쓸 수 있겠습니다.

1부. 이론

- 좋은 코드란 어떤 코드일까요? 

신뢰할 수 있고, 유지보수가 쉬우며 버그가 거의 없는 코드입니다.

요구사항	완전하게 충족
요구사항 변화	사소한 추가 작업 필요
오류 발생 시	시스템이 복구되거나 부분적으로 작동
처음 접하는 상황	예상되지 않은 상황도 처리
시스템 공격	시스템은 안전한 상태이고 손상되지 않음

 

- 코드 품질

1. 읽기 쉬어야 함

2. 예측 가능해야 함

3. 오용하기 어려워야 함

4. 모듈화 

5. 재사용 가능

6. 테스트가 용이한 코드

2부. 실전

5.1.1 서술적이지 않은 이름은 코드를 읽기 어렵게 만든다.

class T {
	Set<String> pns = new Set();
    Int s = 0;
    ...
    
    Boolean f(String n) {
    	return pns.contains(n);
    }
    
    Int getS() {
    	return s;
    }
}

5.1.2 주석문으로 서술적인 이름을 대체할 수 없다.

- 코드가 훨씬 더 복잡해 보인다.

- 코드뿐만 아니라 주석도 유지보수해야 한다.

- 코드를 이해하기 위해 파일을 계속해서 위아래로 스크롤해야 한다.

// 팀을 나타낸다.
class T {
	Set<String> pns = new Set();	// 팀에 속한 선수의 이름
    Int s = 0;	// 팀의 점수
    ...
    
    /**
    * @param 	n 플레이어의 이름
   	* @return 	true 플레이어가 팀에 속해있는 경우
    */
    Boolean f(String n) {
    	return pns.contains(n);
    }
    
    /**
    * @return 팀의 점수
    */
    Int getS() {
    	return s;
    }
}

5.1.3 해결책: 서술적인 이름 짓기

class Team {
	Set<String> playerNames = new Set();
    Int score = 0;
    
    Boolean containsPlayer(String playerName) {
    	return playerNames.contains(playerName);
    }
    
    Int getScore() {
    	return score;
    }
}

 

 

5.8.1 익명 함수는 간단한 로직에 좋다. 

List<Feedback> getUsefulFeedback(List<Feedback> allFeedback) {
	return allFeedback.filter(feedback -> 
            	!feedback.getComment().isEmpty()); //코멘트가 존재하는지 확인
}

5.8.2 익명 함수는 가독성이 떨어질 수 있다.

 List<UInt16> getValidIds(List<UInt16> ids) {
 	return ids
    		.filter(id -> id != 0)
            .filter(id -> countSetBits(id & 0x7FFF) % 2 ==
            	((id & 0x8000) >> 15));	// 패리티 비트를 확인
 }

5.8.3 해결책: 대신 명명 함수를 사용하라

 List<UInt16> getValidIds(List<UInt16> ids) {
 	return ids
    		.filter(id -> id != 0)
            .filter(isParityBitCorrect);
 }
 
 private Boolean isParityBitCorrect(UInt16 id) {
 	...
 }

 

3부. 단위테스트

11.2.1 프라이빗 함수를 테스트하는 것은 바람직하지 않을 때가 있다. 

- 프라이빗 함수 테스트는 실제로 신경 쓰는 행동을 테스트하는 것이 아니다. 

- 테스트가 구현 세부 사항에 독립적이지 못하다.

 

11.2.2 해결책: 퍼블릭 API를 통해 테스트하라 

- 비교적 간단한 클래스의 경우 퍼블릭 API를 통해서 테스트하기 쉽다.

- 그러나 복잡한 클래스의 경우 퍼블릭 API를 통해서 테스트 하는 것이 까다로울 수 있다.

 

11.2.3 해결책: 코드를 더 작은 단위로 분할하라

- 퍼블릭 API를 통해 해결하기에는 너무 큰 클래스의 경우, 더 작은 클래스로의 분할을 생각해보아야 한다.