Books 2013.06.18 12:48


읽기 좋은 코드가 좋은 코드다 - 더스틴 보즈웰, 트레버 파우커


예전에 이 책을 읽고 중요하다고 메모해 놓았던 부분들을 몇 가지 적어봅니다. 물론 책에는 더 좋은 내용들도 많지만, 평소에 제가 알고 있었던 내용들이 많았기 때문에 모두 적지는 않았습니다. 책의 내용이 궁금하신 분들은 직접 구매해서 읽어보시길 추천합니다.


코드의 흐름을 파악하기 힘들게 만드는 요소들

프로그래밍 구조

상위수준의 프로그램 흐름이 혼란스러워지는 방식 

스레딩

어느 코드가 언제 실행되는지 불분명하다

시그널/인터럽트 핸들러

어떤 코드가 어떤 시점에 실행될지 모른다

예외

예외처리가 여러 함수 호출을 거치면서 실행될 수 있다

함수 포인터 & 익명 함수

실행할 함수가  런타임에 결정되기 때문에 컴파일 과정에서는 어떤 코드가 실행될지 알기 어렵다

가상 메소드

object.virtualMethod()는 알려지지 않은 하위 클래스의 코드를 호출할지도 모른다

위 예시 중 어떤 것은 매우 유용하다. 코드를 더 읽기 편하고 덜 중복되게 한다. 하지만 프로그래머는 나중에 코드를 읽는 사람이 얼마나 어렵게 느낄지 생각하지 않은 채 이러한 구조들을 과도하게 사용하기도 한다. 그리고 이러한 구조는 버그 추적을 매우 어렵게 한다.

결국 핵심은 코드를 작성할 때 이러한 구조가 차지하는 비율이 너무 높지 않아야 한다는 데 있다. 만약 과용하면 코드의 흐름을 파악하는 일이 매우 어려워진다.


Boolean 변수의 이름에서는 의미를 부정하는 용어를 피하는 것이 좋다

boolean disable_ssl = false;

위와 같은 이름 대신 다음과 같은 이름을 사용하면 더 간결하고 읽기 좋다.

boolean use_ssl = true;


설명 변수

if line.split(':')[0].strip() == "root":
...

커다란 표현을 쪼개는 가장 쉬운 방법은 작은 하위표현을 담을 "추가 변수"를 만드는 것이다. 추가 변수는 하위표현의 의미를 설명하므로 "설명 변수"라고도 한다.

username = line.split(':')[0].strip()
if username == "root":
...


요약 변수

if (request.user.id == document.owner_id) {
    // 사용자가 이 문서를 수정할 수 있다
}
...
if (request.user.id != document.owner_id) {
    // 문서는 읽기전용이다
}

request.user.id == document.owner_id라는 표현이 커다랗게 보이지는 않지만, 이는 변수 다섯 개를 담고 있다. 따라서 이 표현을 읽으려면 추가적인 시간이 필요하다.

다음 코드의 핵심 개념은 "사용자가 이 문서를 소유하는가?"이다. 이러한 개념은 요약 변수를 더하면 더 명확하게 표현할 수 있다.

final boolean user_owns_document = (request.user.id == document.owner_id);

if (user_owns_document) {
    // 사용자가 이 문서를 수정할 수 있다
}
...
if (!user_owns_document) {
    // 문서는 읽기전용이다
}

대단한 개선처럼 보이지 않을지 몰라도 if (user_owns_document)라는 구문은 더 읽기 쉽다. 또한 user_owns_document라는 표현을 맨 위에 두어 코드를 읽는 사람에게 "이것이 바로 이 함수에서 생각해야 하는 주된 개념이로군"이라는 생각이 들게 한다.


변수의 범위를 좁혀라

변수가 적용되는 범위를 최대한 좁게 만들어라

많은 프로그래밍 언어는 모듈, 클래스, 함수, 블록 범위 같은 다양한 범위/접근 수준을 제공한다. 더 제한적인 접근을 이용하면 변수가 더 적은 줄 내에서만 '보이므로' 일반적으로 더 좋다.

왜 그럴까?

바로, 코드를 읽는 사람이 한꺼번에 생각해야 하는 변수 수를 줄여주기 때문이다. 모든 변수의 범위를 두 배로 축소시키면, 한 번에 읽어야 하는 변수의 수는 평균적으로 반으로 줄어든다.

많은 메소드를 static으로 만들어서 클래스 멤버 접근을 제한해라. 가급적 static 메소드는 코드를 읽는 사람에게 '이 코드는 저 변수들로부터 독립적'이라는 사실을 알려주는 매우 좋은 방법이다.

커다란 클래스를 여러 작은 클래스로 나누는 방법도 있다. 이 방법은 작은 클래스들이 서로 독립적일 때 유용하다. 만약 클래스를 두 개의 작은 클래스로 나누었는데 서로의 멤버를 참조한다면, 실제로 성취한 일은 아무 것도 없게 된다.


쇼트 서킷 논리 (Short-Circuit Logic) 오용 말기

'영리하게' 작성된 코드에 유의하라. 나중에 다른 사람이 읽으면 그런 코드가 종종 혼란을 초래한다.

대부분의 프로그래밍 언어에서 불리언 연산은 쇼트 서킷 평가를 수행한다. 예를 들어 if (a || b)에서 a가 참이면 b는 평가하지 않는다. 이는 매우 편리하지만 때로는 매우 복잡한 연산을 수행할 때 오용될 수도 있다.

assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());

이 코드는 한 줄에 불과하지만 대부분의 프로그래머는 의미를 이해하기 위해서 손을 멈추고 생각해야 한다.

bucket = FindBucket(key);
if (bucket != NULL) assert(!bucket->IsOccupied());

이 코드는 동일한 일을 수행한다. 코드가 두 줄로 늘어났지만 훨씬 이해하기 쉬워졌다.

그럼 첫 번째 코드가 굳이 한 줄짜리 거대한 표현으로 작성된 이유는 무엇이었을까?

코드를 작성하던 당시에는 그렇게 하는 게 매우 영리하다고 생각했기 때문이다. 짧은 코드에 논리를 집어넣는 행위에는 어떤 즐거움이 있기 때문이다. 우리는 모두 일을 하면서 어떤 즐거움을 얻기를 원한다. 문제는 바로 그런 코드가 나중에 코드를 읽는 사람에게는 정신적인 장애물이 된다는 데 있다.


first/last와 begin/end

경계를 포함하는 범위에는 first와 last를 사용하라. 즉, range(first=2, last=4)라면 2, 3, 4를 모두 포함하는 것이다.

경계를 포함하고/배제하는 범위에는 begin과 end를 사용하라. 즉, range(begin=2, end=4)라면 2, 3을 포함하는 것이다.

10월 16일에 일어난 일을 모두 출력하고 싶을 때

PrintEventsInRange("OCT 16 12:00am", "OCT 17 12:00am")

라고 쓰는 것이 아래보다 더 편리하다.

PrintEventsInRange("OCT 16 12:00am", "OCT 16 11:59:59.9999pm")


자기 주변에 있는 라이브러리에 친숙해져라

프로그래머는 이미 존재하는 라이브러리로 자신의 문제를 풀 수 있는 상황이 많다는 걸 모르고 있다. 아니면 라이브러리가 할 수 있는 일을 잊어버린다. 라이브러리가 할 수 있는 일을 알고 활용하는 것은 대단히 중요하다.

매일 15분씩 자신의 표준 라이브러리에 있는 모든 함수/모듈/형들의 이름을 읽어라

여기에는 C++의 STL, Java API, 내장된 파이썬 모듈 등이 모두 포함된다. 라이브러리 전체를 암기하라는 게 아니다. 그냥 그 안에 무엇이 있는지 감을 잡아놓고, 나중에 새로운 코드를 작성할 때 "잠깐만, 이건 전에 API에서 보았던 것과 뭔가 비슷한데..." 하고 생각할 수 있기를 바라는 것이다. 이러한 습관을 들이려고 노력하면 생각보다 금세 좋은 결과를 얻을 수 있다. 코드를 직접 작성하는 대신 우선적으로 이미 존재하는 라이브러리를 사용하는 습관을 갖게 되기 때문이다.


테스트에 친숙한 개발

테스트하기 어려운 코드의 특징과 이것이 설계와 관련된 문제에 미치는 영향

특징 

테스트 문제 

설계 문제 

전역변수를 사용한다 

테스트할 때마다 모든 전역 변수를 초기화해야 한다. 그렇지 않으면 테스트가 서로의 결과에 영향을 줄 수 있다.

어느 함수가 어떤 부수적인 효과를 가지는지 판별하기 어렵다. 각각의 함수를 별도로 고려할 수 없다. 모든 게 제대로 작동하는지 알려면 프로그램 전체를 생각해야 한다. 

코드가 많은 외부 컴포넌트를 사용한다 

처음에 설정할 일이 너무 많아서 테스트를 작성하기 힘들다. 따라서 테스트를 작성하는 일이 즐겁지 않아 테스트 작성을 회피한다.

이러한 외부 시스템 중에서 어느 하나가 제대로 작동하지 않으면 프로그램이 실패한다. 프로그램에 가한 수정이 어떤 효과를 낳을지 알기 어렵다. 클래스들을 리팩토링하기 어렵다. 시스템이 더 많은 실패 모드와 복구 경로를 가지게 된다. 

코드가 비결정적인(nondeterministic) 행동을 가진다 

테스트가 변덕스럽고 안정적이지 못하다. 가끔 실패하는 테스트가 그냥 무시된다. 

프로그램이 경합 조건이나 재생하기 어려운 버그를 가지고 있을 확률이 높다. 프로그램의 논리를 따라가기가 어렵다. 현장에서 발생한 버그를 추적해서 수정하기가 매우 어렵다.


테스트하기 좋은 코드의 특징

 특징

테스트 장점 

설계 장

클래스들이 내부 상태를 거의 가지고 있지 않다

메소드를 테스트하기 전에 설정할 일이 거의 없고 감추어져 있는 상태가 별로 없기 때문에 테스트 작성이 수월하다.

소수의 내부 상태를 가지는 클래스는 이해하기 더 간단하고 쉽다.

클래스/함수가 한 번에 하나의 일만 수행한다

더 적은 테스트 코드가 요구된다.

더 작고 간단한 컴포넌트는 더 잘 모듈화되어있고, 시스템이 서로 더 멀리 떨어져 있다

클래스가 다른 클래스에 의존하지 않고, 서로 상당히 떨어져 있다

각 클래스가 독립적으로 테스트된다 (여러 클래스를 동시에 테스트할 때에 비해서 훨씬 쉽다) 

시스템이 병렬적으로 개발될 수 있다. 클래스가 쉽게 수정될 수 있고, 혹은 시스템의 나머지 부분에 영향을 주지 않으면서 제거될 수도 있다.

함수들이 간단하고 잘 정의된 인터페이스를 가지고 있다 

테스트 대상이 잘 정의되어 있다. 간단한 인터페이스는 테스트를 위해서 더 적은 일을 요구한다. 

프로그래머가 인터페이스를 쉽게 배울 수 있어 해당 인터페이스는 재사용될 가능성이 더 높다. 


지나친 테스트

도가 지나친 수준으로 테스트에 관심을 갖는 경우도 있다.

테스트를 기능하게 하려고 실제 코드의 가독성을 희생시킨다. 실제 코드 테스트를 가능하게 하는 것은 반드시 윈-윈 상황이 되어야 한다. 하지만 테스트를 가능하게 하려고 실제 코드에 지저분한 코드를 집어넣어야 한다면, 뭔가 잘못된 것이다.

100% 코드 테스트에 집착하는 일. 코드의 90%를 테스트하는 노력이 종종 나머지 10%를 테스트하는 비용보다 적은 노력이 들기도 한다. 그 10%는 어쩌면 버그로 인한 비용이 별로 높지 않기 때문에 굳이 테스트할 필요가 없는 사용자 인터페이스나 이상한 에러 케이스를 포함하고 있을지도 모른다.

사실, 코드를 100% 테스트하는 일은 일어나지 않는다. 테스트되지 않은 버그가 있을 수도 있고 테스트되지 않은 기능이 있을 수도 있으며, 요구사항이 달라졌다는 사실을 모르고 있을 수도 있기 때문이다.

버그가 야기하는 비용이 어느 정도인지에 따라서, 테스트 코드를 작성하는 시간이 의미를 갖는 부분이 있고 그렇지 않은 부분도 있기 마련이다. 만약 웹사이트의 프로토타입을 만든다면, 테스트 코드 작성 건은 전혀 의미가 없다. 한편 우주선이나 의료장비를 통제하는 프로그램을 작성한다면 아마 테스트 코드에 주된 관심을 쏟아야 할 것이다.

테스트 코드로 실제 제품 개발이 차질을 빚게 되는 일. 우리는 단지 프로젝트의 일부분에 불과한 테스트가 프로젝트 전체를 지배하는 경우를 본 적이 있다. 테스트가 숭배되어야 하는 신의 자리를 차지하고, 프로그래머들은 자신의 시간이 다른 일에 쓰이는 것이 더 낫다는 사실을 망각한 채 자신을 위한 의식과 동작에 몰두한다. 


신고
Trackback 0 Comment 0