책 리뷰 : 실용주의 프로그래머

---

실용주의 프로그래머

저자

앤드류 헌트, 데이비드 토머스 지음

출판사

인사이트 | 2014-03-28 출간

카테고리

컴퓨터/IT

책소개

The Pragmatic Programmer 숙련공에서 마스터로...

---

코딩 호러 시리즈를 읽으면서 매우 자주 소개된 책이 2권있다.

하나는 조엘 시리즈, 다른 하나는 이 책이다.

이미 아주 예전에 출간되었으나 최근에 디자인이 인사이트 특유의 심플한 디자인으로

탈바꿈되서 새로 나왔다. 목차를 보니 크게 다른 점은 없었다. (페이지 수는 이게 조금더 많다)

다른 분들이 쓰신 책 서평을 보니 거의 다 칭찬일색인데...

에..뭐랄까... 내가 코딩 호러 시리즈에서 이 책에 대한 내용을 심하게

네타 당했는지 읽는 내내 '많이 봤던 내용들이네...?' 하면서 지루하더라.

그래서 진짜 겨우 읽었다. 머릿속에 잘 들어오지가 않아서 여러모로 아쉽다.

물론 아주 유명한 책인 만큼 공감할 수 있는 부분, 새롭게 깨달음을 얻는 부분들도 있었으나

저자님께서 Perl 을 무지 좋아하시는 것 같았다ㅋㅋㅋㅋㅋ

나는 Perl 을 잘 모르기 때문에 저자님께서 씡나게 Perl 얘기를 하면 지루....

'보이지 않는 이 거리감 어쩔거야 ㅋㅋㅋ' 라는 생각이 조금 들었다.

제길. 이거 먼저 읽고 코딩호러 시리즈를 읽었어야 하는데 ㅋㅋㅋㅋㅋㅋㅋ

리뷰를 써야되나 말아야되나 솔직히 지금 포스팅하고 있는 시점에서도 고민된다 ㅋㅋ

진짜 어디서 본 내용들 많이 나오더라.

깨진 유리창 이야기 부터 고무 오리 기법, select 는 망가졌어 등등

중복되는 내용은 대충 훌훌 읽었....ㅋ

막상 이렇게 시작부터 책을 까도 막상 리뷰 쓰다보면 엄청 써대니 잡소리는 여기까지 하겠다.

1. 실용주의 철학

'돌멩이 수프와 삶은 개구리' 부분은 재밌게 읽었다.

스토리는 조금 억지스럽지 않았나 싶기도 했지만 그로부터 얻는 교훈에서는 느낀 바가 없진 않다.

'지식 포트폴리오'

- 지식 포트폴리오를 만들라고 하는데 매우 공감한다. 

그렇기 때문에 나는 이 블로그를 개설했었다.

주로 프로그래밍 관련 포스팅만 해서 다각화가 조금 부족한 면이 있지만

확실히 나는 개발 관련 포스팅을 해놓고 필요할 때 다시 보는 경우가 굉장히 많다.

이렇게 반복학습을 하면서 더욱 그 내용을 상기시키게 되서 더욱 지식 자산을 견고히 쌓게 된다.

블로그 개설을 강요하는 건 아니지만 ㅡ_ㅡ; (하지만 제프 앳우드님은 블로그를 하라고 하셨지)

아무튼 이 책에는 지식 포트폴리오를 관리하는 가이드 라인이 소개 되어 있다.

1) 매년 새로운 언어를 최소 하나는 배워라.

2) 기술 서적을 분기마다 한 권씩 읽어라.

3) 비 기술 서적도 읽어라.

4) 수업을 들어라.

5) 지역 사용자 모임에 참여하라.

6) 다른 환경에서 실험해보라.

7) 요즘 흐름을 놓치지 마라.

8) 인터넷을 이용하라.

사실 회사 일에 치여 살다보면 지금 하고 있는 일과 관련없는 공부를 하기가 힘들다는 건 현실이다.

지친 심신을 위한 휴식도 중요하지만 휴식이 지나치지 않은가에 대해 경계할 필요가 있는 것 같다.

물론 나에게 해당되는 얘기다 ㅋ 너무 쉬기만 하면 머리가 급속도로 포맷이 되니까 ㅡ_ㅡ

아, 그리고 이 장에서 Guru 가 뭔지 대강 알게되었다.

2. 실용주의 접근법

'중복의 해악'

- DRY : Do NOT repeat yourself

책 읽다보면 DRY 가 정말 많이 나온다. 그만큼 중복을 피하라는 것을 강조한다.

'예광탄'

- 목표물을 찾기 위해 예광탄을 써라.

프로토타이핑 VS. 예광탄 코드 

* 프로토타이핑 : 최종 시스템의 어떤 특정한 측면을 탐사해보는 것이 목표다.

진짜 프로토타입 방식을 따른다면, 어떤 개념을 구현해 보려고 시도할 때 대충 끼워 맞춘 것들을

모두 버린 후, 실험 과정에서 얻은 교훈을 바탕으로 다시 코드를 만들게 된다.

* 예광탄 코드 : 문제에 대한 대응 방법이다.

'애플리케이션이 전체적으로 어떻게 연결되는지 알고 싶고,

사용자들에게 실제로 이 애플리케이션이 어떻게 상호작용하는지 보이고 싶고,

개발자들에게는 코드를 붙일 아키텍처적 골격을 제시하고 싶다.' 라고 생각하는 경우, 

대강 구현한 알고리즘과 단순하지만 동작은 하는 사용자 인터페이스로 구성된 예광탄을 만들 것이다.

프로토타입은 나중에 버릴 수 있는 코드를 만드는 것이고,

예광탄 코드는 기능은 별로 없지만 완결된 코드이며 최종 시스템 골격의 일부를 보인다.

3. 기본적인 도구

'일반 텍스트의 힘'

- 지식을 일반 텍스트로 저장하라.

* 단점 

1) 압축된 이진 포맷을 사용하는 것보다 더 많은 공간을 차지할 수 있고

2) 일반 텍스트 파일을 해석하고 처리하는데 더 많은 계산이 필요할 수 있다.

* 장점

1) 구식이 되는 것에 대한 보험

2) 호환성

3) 더 쉬운 테스트

장점이 단점을 다 덮고도 남는다고 강조하신다ㅎ

지식을 저장하는 최고의 포맷은 Plain Text 라고 하시면서.

4. 실용주의 편집증

'단정적 프로그래밍'

- 연습문제가 재미있길래 가져와봤다.

Q. 간단한 현실 점검. 다음 '불가능한' 것들 중 무엇이 실제로 일어날 수 있는가?

1. 한 달이 28일 보다 적은 것

2. stat(".", &sb) == -1 (즉, 현재 디렉터리에 접근할 수 없다)

3. C++ 에서 a = 2; b = 3; if ( a+b != 5 ) exit(1);

4. 내각의 합이 180도가 아닌 삼각형

5. 60초가 아닌 1분

6. 자바에서 (a+1) <= a

해답

1. 1752년의 10월은 19일 밖에 없다. 그레고리 교황의 달력 개혁의 일부로

달력 간의 날짜를 맞추기 위해서 이런 일이 생겼다고 한다.

2. 다른 프로세스가 디렉토리를 없앴거나 디렉토리를 읽을 퍼미션이 없을 수 있다. 또는 &sb가 잘못 되거나.

3. 함정. (a 와 b 의 자료형을 명시하지 않았기 때문에)

연산자 오버로딩 때문일수도 있고, 또는 a 와 b 가 동일한 변수의 참조 변수일 수도 있다.

4. 비유클리드 기하학에서 삼각형의 내각의 합은 180도 안 될 수도 있다.

구 표면에 그려진 삼각형을 생각해보자.

5. 윤분(leap minute)은 61초나 62초일 수도 있다.

6. 오버플로 때문에 a+1 값이 음수가 될 수도 있다.

'리소스 사용의 균형'

- 기억에 남는 연습문제가 있었다.

Q. 일부 C 개발자와 C++ 개발자들은 어떤 포인터가 가리키는 메모리의 할당을 해제한 다음에는

반드시 그 포인터가 NULL 을 가리키게 하곤 한다. 왜 이것이 좋은 생각일까?

해답

대부분의 C나 C++ 구현에서는 어떤 포인터가 정말 유효한 메모리를 가리키는지 확인할 방법이 없다.

어떤 메모리 영역의 할당을 해제한 다음에 프로그램의 나중 부분에서 그것을 참조하는 잘못은

자주 일어난다. 그때쯤이면, 가리키는 메모리는 다른 목적을 위해 재할당되어 있을 수도 있다.

프로그래머는 포인터를 NULL 로 맞추어 놓음으로써 이런 잘못된 참조를 하지 않을 수 있기를 기대한다.

대부분의 경우 NULL 포인터를 참조하는 것은 런타임 에러를 발생하기 때문이다.

(비공개 포스팅에도 한번 언급했지만 NULL 포인터는 

일반적으로 '0' 이라는 값을 갖으며 유효한 참조나 메모리 주소를 가르키지 않는다)

5. 구부러지거나 부러지거나

'메타프로그래밍'

- 코드에는 추상화를, 메타데이터에는 세부 내용을.

메타데이터는 애플리케이션을 기술하는 모든 데이터로 보통 컴파일타임이 아닌 런타임에 접근, 사용된다.

메타데이터를 이용하여 반환 매개 변수, 사용자 선호사항, 설치 디렉터리와 같은

애플리케이션 설정 옵션을 기술하라. ex) 윈도우에서 .ini 확장자 파일

6. 코딩하는 동안 해야할 일들

'우연에 맡기는 프로그래밍'

- 우연에 맡기는 프로그래밍을 하지 말라.

휴... 왠지 이 파트를 읽으면서 나도 모르게 반성하게 되었다.

애초에 시작부터 우연에 맡기는 프로그래밍을 하는 것도 큰 잘못이고 어리석은 짓이나..

내 경우에는 조금 다르다.

코딩을 하다가 내가 생각했던 방식대로 계속 잘 안 되면 다른 방법을 찾게 된다.

다른 방법 역시 뭔가 계속 안 되면 나는 멘붕에 빠지기 시작하면서 짜증 지수가 최고조로 급상승.

결국 폭발하면 반드시 되게끔 만들어보이겠다는 오기가 생기기 시작해

온갖 수단과 방법을 가리지 않고(?) 마구잡이로 덤벼든다. 

생각해보면 이 과정은 우연에 맡기는 프로그래밍과 크게 다를 바 없다.

안 되니까 될 때까지 미친 애마냥 이거저거 막 찔러보는......

이래서 냉정과 침착 (=멘탈甲) 이 필요하다.

'리팩터링'

- 언제 리팩터링을 해야할까?

1) 중복(DRY)    2) 직교성이 좋지 않은 설계    3) 유효기간이 끝난 지식    4) 성능

연습문제가 3문제 있는데 모두 풀어볼 만한 흥미로운 문제였다.

풀면서 느낀 건 디자인 패턴 공부를 해놓은게 확실히 도움이 된다.

'읽기 좋은 코드가 좋은 코드다' 라는 책도 풀다가 중간에 생각날 정도로 도움이 됐다.

7. 프로젝트 전에

'요구사항의 구렁텅이'

- 요구사항을 수집하지 말고 채굴하라.

ㅋㅋㅋㅋ... 이 파트 읽으면서 설마 객체지향 수업시간에 징하게 배웠던

Use-Case 가 나올 줄이야 ㅋㅋㅋㅋㅋ 심지어 UML 도 나와서 좀 웃겼다.

'와, 이게 실제로 쓰이긴 쓰이나 보구나....' 싶었다.

개인적으로 Use-Case 작성하는 것에 대해 >매우< 스트레스 받는다ㅋㅋㅋ

그리고 요구사항을 수집하지 말고 채굴하라고 하는데... 맞는 얘기다.

실제로 내가 인턴했을 때 전달 받은 요구사항에 대한 문서들을 모아 잘 정리해서 

내 나름대로 코딩을 하고 있었다. (문서 중간에 조금 의심스러운 부분이 있었음에도 불구하고)

그런데 중간에 요구사항이 변경되는 바람에... 내가 우려했었던 그 부분에 대한 코드를 통째로 날렸다 ^^ㅋ

그러니 수집하지 말자. 채굴하자. 정말 쌀알만한 한 점의 의심스러운 부분이라도 캐내자.

8. 실용주의 프로젝트

'결국은 모두 글쓰기'

- 아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다.

진짜... 저 말에 매우매우매우 10000% 동의한다.

특히 나는 일주일도 안 되서 내가 전에 무엇을 했었는지 기억을 잘 못한다. ㅠ_ㅠ

그래서 혹시라도 까먹을까봐 불안해서 핸드폰이나 주변에 잘 보는 곳에 기록을 남긴다.

이는 개발할 때도 마찬가지다. 예를 들어 소스 코드 주석.

책에서 JavaDoc 도구가 제안하는 주석의 수준을 하나의 예를 들어 보여주는데 훌륭했다.

그리고 적절한 주석이 제자리에 있으면 JavaDoc 이나 DOC++ 같은 도구가 API 수준의 문서를

자동으로 추출, 포맷까지 해준다고 한다. 한번 해볼 가치가 있다고 느꼈다.

나의 경험을 비추어 봤을 때... 

인턴을 하면서 내가 분명히 무슨 이유가 있어서 어떤 코드를 작성을 했는데

대리님께서 그 코드를 보고 이거 누가했냐면서 왜 이렇게 해놓았냐고 약간 짜증이 섞인 말로 물어보셨다.

그래서 내가 한 거라고는 밝혔는데 문제는 왜 그랬었는지 내가 기억을 못 했다 ! ! ! ! (real 상황이었음)

지금 생각만해도 정말 절망스러웠다....ㅋㅋㅋㅋㅋ...

거의 한소리 듣기 일보 직전에 내 사수님께서 그 이유를 기억하셔서 잘 설명해주셨고,

이유가 잘 먹혀서(?) 결국 그 코드는 보존하게 되었다. 

Aㅏ, 정말.... 주석....

잘 달아놓자 ㅠ_ㅠ.............!

그리고 공부한 내용은 잘 정리해서 기록에 남기자. 나중에 진짜 다시 찾아보게 된다.

'오만과 편견'

- 자신의 작품에 서명하라.

마지막 파트라서 그런가, 꽤 중요한 내용이라고 생각된다.

'내가 이걸 만들었고, 내 작품의 품질을 보증합니다' 라는 뜻의 서명.

품질의 보증수표 ㅋㅋㅋㅋ 마치 화가들이 자신의 작품에 서명하듯이.

그러고보니 인턴할 때 누군가의 코드를 보고 있었는데

가끔가다 주석에 닉네임 같은 것이 적혀있었다. 

그걸보고 '누군지 몰라도 꽤 자신이 있나보다..' 라는 생각을 하게 되었다.

사실 자신이 있는 것도 있는 거지만 그만큼 자기 코드에 대해 책임을 지겠다는 뜻인데.

나는 아직 초보 개발자여서 내 코드에 대한 자신이 없기때문에 사실 지금은 서명하는 게 조금 두렵다.

더 솔직히 까발리자면(?) 누군가에게 지적받는 게 두려운 것 같다.

초보 개발자이든 뭐든 간에 맡은 일을 하다가 지적받을 수도 있는거고,

'받아들일 건 받아들이자' 면서 머리 속으로도 쿨하게 넘기려고 하는데도

막상 지적받으면 스스로가 창피하고 뭔가 굴욕적? 이다 ㅋㅋㅋㅋ 이러면 안되는데.

좀 더 덤덤하게 철판을 깔고 더 배운다는 자세로 내 흔적을 남겨야 할텐데. ㅋㅋㅋ

아니면 지적도 못 하게 완벽하게 코드를 짜든가. (실질적으로 이건 불가능)

쩝. 아무튼 책임 회피를 하는 것 만큼 최악인 것도 없으니

내 개인의 창피함 보다는 책임감을 좀 더 중요시 여기려고 노력해야겠다.

역시 리뷰 쓰다보니 앞에 지루하다고 투덜댈 때는 언제고 마구 쓰게 된다ㅋ

가끔 기록 강박증이 있는 건가 스스로 의구심이 들 때가 있지만 아직 그 단계까지는 아닌듯.

나는 좀 글을 써야된다. 평소에 너무 안 쓰니까 어휘력도 딸리고 표현력도 딸리고 ㅋㅋㅋㅋㅋ orz

다음엔 조엘 시리즈 ㄱㄱ ~