책 리뷰 : 읽기 좋은 코드가 좋은 코드다 (임백준 역, 한빛미디어)

---

읽기 좋은 코드가 좋은 코드다

저자

더스틴 보즈웰, 트레버 파우커 지음

출판사

한빛미디어 | 2012-04-10 출간

카테고리

컴퓨터/IT

책소개

* 더 나은 코드를 작성하는 간단하고 실전적인 테크닉!이 책은 ...

---

독서와 수십 억광년의 거리를 두다 언제부턴가 개발자를 위한 책을 읽기 시작 하면서

조금씩 책을 읽게 되었다. 그리고 지금은 리뷰까지 쓴다. 헛소리겠지만 나이 들었나 보다ㅋ

아무튼 간만에 재미있게 읽은 책이었다. 처음엔 단순히 임백준 님이 번역했다는 이유로

책을 선정했는데 선택하길 잘 한 것 같다. 굿초이스였다!

중학교때인가 독후감을 써내야 했었다. 당시의 난 책 읽는 것을 무지 싫어했지만

쓰긴 써야되니 임백준 님의 '뉴욕의 프로그래머'라는 책을 읽었다고 뻥을 치고 독후감을 썼다.

그러다 대학생이 되고 어느 날, 언니가 빌려온 책 중에 '뉴욕의 프로그래머'가 있는 걸 보고

중학교 때 생각이 나면서 호기심에 읽기 시작했고 임백준 님을 존경하게 되었다. 지금도 존경한다.

존경하는 분이 번역하신 책인 만큼 재미있겠거니 하고 '읽기 좋은 코드가 좋은 코드다' 라는 책을 읽게 되었다.

저자이신 더스틴 보즈웰, 트레버 파우커 두 분 모두 구글에서 근무한 경력이 있으신 분들이다. 짱이다.

지은이의 말이 시작하기 전에 다음 그림을 보고 공감해버리고 말았다. 

으, 생각만 하면 창피하다.

내가 지금도 이런다면 문제가 심각하겠지만 불과 2~3년 전만 해도

저랬던 건 확실하게 기억이 난다. 내가 짠 코드를 한 1년 뒤에 언니가 그 코드가 필요하다고 해서

파일을 넘겼는데 언니가 했던 말, '이 코드는 뭐하는 코드야? 이건 뭐고 저건 뭐하는 변수야?' 등등....

나 혼자 짠 코드라 주석따위 거의 없었고 변수 이름도 보면

내가 다시 봐도 기억도 안나고 뭐하는 변수인지 잘 파악도 안되는 그런 코드였다.

딱 위에 있는 그림과 같은 상황이었다. 제기랄.

리뷰에 앞서 참고로 이 책은 꽤 자잘하게 많은 예제 코드들이 있어

내 이해를 더 도울 수 있었고 코드 랭귀지도 C++, JAVA, Python, JavaScript, PHP 등 다양한 언어들로

예시를 들어서 개인적으로 다양한 언어를 경험해본 나로서는 꽤 흥미로웠다.

그리고 이 책은 4 가지 파트로 구성되어있다.

1부. 표면적 수준에서의 개선 (이름 짓기, 주석, 미학, 코드베이스의 모든 줄에 적용될 수 있는 간단한 조언들)

2부. 루프와 논리를 단순화하기

3부. 코드 재작성하기

4부. 선택된 주제들

각 파트별로 리뷰를 남겨보겠다. 안 그러면 나중에 읽고서도 무슨 내용이 있었는지 기억이 잘 안난다.

중요하거나 기억에 남는 부분을 위주로 작성하겠다.

<< 1부. 표면적 수준에서의 개선 >>

(1) 이름에 정보담기

- 내 생각엔 이 파트의 내용은 정~~~말 깨알같은 도움이 되는 내용이었다. 버릴 게 없다.

특히 상황에 적합한 단어들을 골라 명명하라는 내용은 격하게 공감한다.

다음은 책에서 소개된 내용들이다.

get	fetch, download
send	deliver, dispatch, announce, distribute, route
find	search, extract, locate, recover
start	launch, create, begin, open
make	create, set up, build, generate, compose, add, new
filter	select, exclude

왼쪽은 보통 일반적으로 많이 쓰는 단어들이다. 하지만 추상적으로 쓰일 때가 꽤 많다.

이를 대체하기 위해서는 아까도 말했듯이 오른쪽 단어들과 같이 상황에 적합한 단어들을 골라야 한다는

내용이 기억에 남는다. 

나야 아마추어 수준이거나 그 이하의(ㅠㅠ) 개발자 지망생이긴 하지만...

어쨌든 개발하면서 왼쪽의 단어들을 많이 사용하는데 확실히 지금보니 추상적으로 썼을 때가

많았던 것 같다. 어휘력이 딸리다보니ㅡ_ㅡ.........

주석으로 blah blah 하느니 선언한 변수에 구체적이고 충분한 정보를 담는 이름을 명명하는 게 

훨씬 효율적이라는 것을 다시 한번 돌아볼 수 있었다.

그 외 기타 주의사항

- 단위 : time 보다는 time_ms, size 보다는 size_mb, angle 보다는 degrees_cw 등등

(2) 오해할 수 없는 이름들

- 경계를 다루는 한계값 관련

[1, 5] 가 1, 2, 3, 4, 5 를 포함하고 [5, 10) 가 5, 6, 7, 8, 9 를 포함하는 표기가 있듯이

영어도 이러한 표기 단어들이 있다.

경계를 포함하는 한계값 : min/max, first/last

경계를 포함하고 배제하는 범위 : begin/end (end가 애매하긴 하지만 관행인 것 같다)

(3) 미학

- 내가 개인적으로 추구하는 미학이랑 공감할 수 있는 부분이 많은 것 같아서 천만다행이다.

(4) 주석에 담아야 하는 대상

- '코드에서 빠르게 유추할 수 있는 내용은 주석으로 달지 말라' -> 이 이야기 보고 조금 뜨끔했다.

내 예전 코드를 까보면 내가 안 좋은 짓이란 짓은 꽤 많이 했었던 것 같다.(특히 쓸데없는 거) 끄엑ㅠㅠ

- 다음은 프로그래머 사이에서 널리 사용되는 표시라고 한다.

TODO:	아직 하지 않은 일, 해야할 일   (중요한 건 TODO:, 덜 중요한 건 todo: 이렇게 구분도 가능)
FIXME:	오작동을 일으킨다고 알려진 코드
HACK:	아름답지 않은 해결책
XXX:	위험! 여기 큰 문제가 있다

솔직히 TODO 빼고는 다 처음 본다..ㅋㅋㅋㅋㅋㅋㅋ

어쨌든 깨알같은(명확하고 간결한) 주석은 부지런히 달자. 

난 너무 주석을 안 다는 버릇이 있어서 고쳐야 된다.

다 피가 되고 살이 된다.

<< 2부. 루프와 논리를 단순화하기 >>

(1) 읽기 쉽게 흐름제어 만들기

- 함수 중간에서 반환해 중첩 제거하기

- 루프 내부에 있는 중첩 제거하기

아래 코드는 책에 있는 예제이다. 처음 코드를 두번째 코드로 고치자.

for ( int i=0; i<results.size(); i++ )

{

if ( results[i] != NULL )

{

non_null_count++;

if ( results[i]->name != "" )

{

cout << "considering candidate..." << endl;

}

}

}

for ( int i=0; i<results.size(); i++ )

{

if ( results[i] == NULL ) { continue; }

non_null_count++;

if ( results[i]->name != "" ) { continue; }

cout << "considering candidate..." << endl;

}

이 내용을 보면 '당연히 아래 코드처럼 짜야되는 거 아니야?' 라고 생각할지 모른다.

확실히 누가 봐도 아래 코드가 더 간결하고 아름답다. 혹은 'for each' 을 써서 다듬거나.

나는 이 책을 보면서 과거에 내가 짰던 코드들에 대해 많이 되돌아 보고 반성할 수 있었다.

왜 내가 첫번째 코드처럼 지저분하게 중첩을 사용했는지는 잘 모르겠다. 당시 좀 멍청했었나 보다.

코딩을 하다보면 가끔 이런 지저분한 중첩으로 논리를 복잡하게 할 때가 있는데 반성해야겠다.

정신놓고 코딩하면 첫번째 코드로 짤 수 있는 여지는 충분하다고 본다 ㅠ_ㅠ

(2) 거대한 표현을 잘게 쪼개기

- 이 장의 제목 그대로이다. 영리한 코드가 아닌 누구나 쉽게 이해할 수 있는 심플한 코드를 만들자.

자기 혼자 머리가 좋다고 논리를 복잡하게 꼬아놓은 그건 정말 ㅄ............. 잘난 척하지말자.

- Tip : Python, JavaScript, Ruby 같은 언어는 'OR' 연산자가 인수 중 하나를 반환한다.

(해당 값은 Boolean 으로 변환되지 않는다)

ex ) x = a || b || c 라는 코드는 a, b, c 라는 세 값 중에서 첫번째 '참' 값을 반환한다.

- C++ 에서 매크로를 사용할 수 있는데 보통 매크로의 사용을 자제하는 것이 좋다고 한다.

하지만 책의 예제와 같이 때에 따라선 매크로가 간단한 사용과 코드 가독성을 도움을 주기도 하니 기억해두자.

(3) 변수와 가독성

- 이 장에서는 내가 이 책에서 읽은 내용 중 가장 충격적(?)인 내용이 담겨져있다.

- 다음은 JavaScript 에서 Form 을 제출할 때의 함수이다.

대부분 아래와 같은 방식으로 코딩할 것이라고 생각했다...

submitted = false;    // 주의 : 전역 변수

var submit_form = function (form_name) {

if (submitted) {

return;    // 중복 제출 방지

}

...

submitted = true;

};

그런데 잘 알다시피 전역 변수는 사용하지 않는 편이 좋다.

특히 JavaScript 에서는 변수를 정의할 때 'var' 를 생략하면 해당 변수는 모든 JavaScript 파일과 <script> 블록에 접근할 수가 있다. 그러다보니 자기도 모르게 무의식적으로 이 변수와 같은 이름의 변수를 사용하면

이상한 버그를 만들어낸다. 나중에 작성한 코드에서 여전히 그 변수를 볼 수 있기 때문이다.

내 기억에 의하면 난 이 경험을 해본 적이 있다. 최악이었다.

var submit_form = (function () 

{

var submitted = false;    // 주의 : 아래에 있는 함수만 접근 가능

return function (form_name) {

if (submitted) {

return;    // 중복 제출 방지

}

...

submitted = true;

};

}());

어쨌든 아래 코드는 이해하기 힘들지만 JavaScript 에서 Private 변수를 만드는 테크닉이라고 한다.

정말 듣도 보도 못한 테크닉이고 이게 돌아가는 코드인지 조차 의심이 되는 이상한 코드였다 ! !

그래서 충격이었다. 이게 고급 개발자의 테크닉이란 말인가 ㅎㄷㄷ.... OTL......

익명함수가 있다는 걸 알고는 있었지만.... 이건... 크헙... 말도 안 나온다..

이런 식으로 익명 함수를 사용해 Private 한 범위를 만든다니............. 진짜 충격.......ㅠㅠ

이거 진짜 어떻게 돌아가는 건지.... submitted 변수가 계속 저장이 되나 저게????

그리고 어떻게 사용하는 건지 모르겠다.... form_name 은 어떻게 넣어 주는거지???

흐앙 ㅠㅠ........................ 패닉이다.

책에는 (이러한 테크닉에 대해 더 알고 싶으면 더글라스 크락포드의 자바스크립트 핵심 가이드(한빛,2008)를

보라) 라고만 적혀있다......... 나중에 저 책을 사서 보든가 해야겠다 흑흑..

<< 3부. 코드 재작성하기 >>

(1) 상관없는 하위문제 추출하기

- 코딩을 하다보면 프로젝트랑은 직접적 연관은 없고, 자주 사용되는 도구 같이 유틸리티스러운(?) 부분을 짜게 된다.

그런 부분은 따로 디렉토리를 만들어서 모아두면 유용하게 쓰일 수 있다는 건 알고 있다.

하지만 실제로 난 코딩하면서 그래본 적이 없다 ㅡㅡ................. 이론만 알지 실천을 안하나보다. 제길.

어쨌든 일반적인 목적의 코드를 프로젝트의 특정 코드에서 분리하는 버릇을 좀 갖자 ! !

(2) 한번에 하나씩

- 책에 있는 예제가 깨알같다. 보면서 와닿는 것이 많고 깔끔한 코드가 정말 사랑스럽다.

- 한번에 여러 개를 못하고 하나에만 집중하는 타입인 나지만 이런 실수도 가끔 하는 것 같다. 

One Time One Job 하자!

(3) 생각을 코드로 만들자

- 앞에 코드 중첩을 피하는 방법이 다시 나오기는 하지만 그래도 다른 예제로 다시 상기시킬 수 있으니 좋았다.

- 저자님들의 말씀에 따르면 

" 간결한 코드를 작성하는 기술 중 하나는 라이브러리가 제공하는 기능을 잘 활용하는 것이다. "

이런 구절이 있는데 이걸 보고 감동 먹었다...........ㅠ_ㅠ.......

사실 나는 라이브러리를 나름 잘 갖다쓰는(?) 인간인데 

가끔 몇몇 분들께서 라이브러리를 활용해 구현했다고 하면 

그 순간, 그 사람의 능력을 폄하하고 개무시하는 분들이 계신다ㅡㅡ.

물론 혼자 완전 근본의 근본부터 다 짜면 좋겠지.... 인정한다. 

하지만 굳이 있는, 좋은 라이브러리를 무시하면서까지 과연 내가 그걸 일일이 다 짜야할 필요가 있을까. 

내 궁극적인 목적은 그게 아닌데도?? 제한된 시간은 어쩔건데??

라고 혼자 궁시렁 거리고는 한다 ㅠ_ㅠ....

그런 분들을 꽤 봤기 때문에 나는 - 내가 인정받지 못하는 게 두려우니까 -

되도록이면 라이브러리를 사용했다는 얘기를 많이 숨기는 편이다. 

난 적절한 라이브러리를 찾아서 입맛에 맞게 잘 사용하는 것도 능력이고 노력하는 거라고 생각하건만.

(ㅋ 물론 '남이 하면 불륜이고 내가 하면 로맨스'라는 생각일지도 모르겠다)

아무튼 저자님의 저 말씀을 읽고는 왠지 용기를 불끈! 얻었다. 

감사합니다. 사랑합니다. 저 힘낼게요.

- 고무 오리 기법 : 실제로 어떤 대학의 컴퓨터 연구실은 프로그램을 디버깅할 때 누군가에게 도움을 요청하기에 앞서

그 문제를 방 한 켠에 놓아둔 곰 인형에게 말로 설명하라는 정책을 가지고 있다고 한다. 놀랍게도 이렇게 문제를

큰 목소리로 말하는 행위가 학생 스스로 해결책을 찾게 도움을 주는 것으로 드러났다.

아마 누구나 저런 경험 있지 않을까 싶다. 타인에게 도움을 청하려고 이런 문제가 있다고 말하다가 갑자기

혼자 해결하고는 싱겁게 대화가 끝나버리는 상황ㅋ

어쨌거나 어떤 프로그램 or 생각을 말로 설명하는 행위는 문제의 틀을 제대로 잡는 데 도움을 준다고 한다.

(4) 코드 분량 줄이기

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

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

(C++ 표준 템플릿 라이브러리 STL, 자바 API, 파이썬 내장 모듈 등)

이 말에 공감하지만.... 매일 읽게 되지는 않는다는 슬픈 현실ㅠ_ㅠ.... 귀차니즘이 죄다.

하지만 저 귀차니즘이 도움이 됐다고 해야될까, 나는 한때 구현하는 게 귀찮아서

자바 API 를 정말 이 잡듯이 뒤지면서 코딩을 했던 적이 있다.

뭐... 좋게 보면 활용 능력이 좋은거고(?) 나쁘게 보면 능력이 없다고 볼 수 있다.

무능력 하다는 소리는 듣기 싫으니 부지런해져야겠다. 아직 경험이 많이 부족하니까 ㅠ_ㅠ 휴 -

<< 4부. 선택된 주제들 >>

(1) 테스트와 가독성

사실 테스트 코드를 따로 작성해 본 경험은 없지만...

이 장에서는 멍청하게 테스트 하는 방법을 똑똑하게 테스트 하는 방법으로 도달하기까지의 과정이

예제를 통해 잘 정리되서 나와있다. 역시 깨알같다. 굳굳.

가독성을 위한 책이다 보니 심플한 게 킹왕짱이다ㅋ

(2) 분/시간 카운터를 설계하고 구현하기

- 앞에서 보았던 내용들이 총집합 되는 예제가 나온다.

코드를 처음부터 잘 짜는 것 보다는 오히려 아름답지 않더라도 우선 작성을 하고 

문제점이 뭔지 파악하면서 계속 개선해나가는 방향으로 설명을 한다.

사실 마지막 장의 내용이 잘 이해가 안 간다. 앞에 봤던 코드들에 비해서 코드 양이 많아서

이리저리 정신없이 책을 뒤적이며 코드 이해하다가 조금 짜증이 났다.

그리고 내용도 좀 수준이 있는 것 같다. 설계와 성능에 대해 논하면서 코드를 개선해 나가는데

중상급 개발자 정도는 되야 이 정도 아이디어가 나오지 않을까 하는 생각이 들었다.

배경지식이 좀 필요하다보니... 나같은 허접이 이런 아이디어를 낸다는 건 조금 무리인듯ㅠ_ㅠ

모든 장을 훑다보니 리뷰가 길어졌다.

이 책은 한번 읽었지만 나중에 다시 한번 읽어볼 가치가 있는 것 같다.

내가 이 책을 읽고 과연 이렇게 실행에 옮겼는지 반성하게 되는 의미에서 좋은 책이라고 생각한다.

수학이나 개발 관련 서적이 좋은 게...

원서가 영어라도 수학 기호나 프로그래밍 언어는 누구나 공통으로 알고 있으니

그것을 통해서 이해가 잘 된다는 점이다ㅋ.ㅋ

아무튼 이 책은 실질적으로 도움이 되는 팁이나 조언들이 깨알같이 수록되어 있어 소장가치가 있는 것 같다.

나같은 초급 개발자도 충분히 읽었기 때문에 개발자라면 누구나 읽을 수 있고 ~

책도 300 페이지가 안 되는 책이라 접근성(?)이 뛰어나다고 할 수 있다 ㅋㅋㅋ

읽기 잘 했다는 생각이 드는 책이라 언니에게도 추천해줬다 ㅋ.ㅋ

다음엔 임백준 님이 번역하신 또다른 책을 읽어볼 계획이다!