제가 여러번 극찬한 임백준씨의 번역서입니다.


얼마나 좋았으면 직접 번역을 하셨을까 궁금하더군요.


이전에 번역하신 해커와 화가도 두고 두고 읽을만큼 색다른 시각이 좋았던지라, 이 책에 대한 기대도 그만큼 컸다고 볼 수 있습니다.



대략 책 제목에서도 알 수 있듯이, 어떠한 코드가 읽기 좋은 코드인지에 대한 기준을 제시하는 책입니다.



한빛 미디어 사이트 목차에서 발췌하자면, 담고 있는 내용은 아래와 같습니다.


1장. 코드는 이해하기 쉬워야 한다
   01. 무엇이 코드를 '더 좋게' 만드는가?  
   02. 가독성의 기본 정리  
   03. 분량이 적으면 항상 더 좋은가?  
   04. 이해를 위한 시간은 다른 목표와 충돌하는가?  
   05. 어려운 부분  

PART I. 표면적 수준에서의 개선

2장. 이름에 정보 담기
   01. 특정한 단어 고르기  
   02. tmp나 retval 같은 보편적인 이름 피하기  
   03. 추상적인 이름보다 구체적인 이름을 선호하라  
   04. 추가적인 정보를 이름에 추가하기  
   05. 이름은 얼마나 길어야 하는가?  
   06. 이름 포메팅으로 의미를 전달하라  
   요약  

3장. 오해할 수 없는 이름들
   01. 예: Filter()  
   02. 예: Clip(text, length)  
   03. 경계를 포함하는 한계값을 다룰 때는 min과 max를 사용하라  
   04. 경계를 포함하는 범위에는 first와 last를 사용하라  
   05. 경계를 포함하고/배제하는 범위에는 begin과 end를 사용하라  
   06. 불리언 변수에 이름 붙이기  
   07. 사용자의 기대에 부응하기  
   08. 예: 이름을 짓기 위해서 복수의 후보를 평가하기  
   요약  

4장. 미학
   01. 미학이 무슨 상관인가?  
   02. 일관성과 간결성을 위해서 줄 바꿈을 재정렬하기  
   03. 메소드를 활용하여 불규칙성을 정리하라  
   04. 도움이 된다면 코드의 열을 맞춰라  
   05. 의미 있는 순서를 선택하고 일관성 있게 사용하라  
   06. 선언문을 블록으로 구성하라  
   07. 코드를 '문단'으로 쪼개라  
   08. 개인적인 스타일 대 일관성  
   요약  	
	
5장. 주석에 담아야 하는 대상
   01. 설명하지 말아야 하는 것  
   02. 생각을 기록하라  
   03. 코드를 읽는 사람의 입장이 되어라  
   04. 마지막 고찰 - 글 쓰는 두려움을 떨쳐내라  
   요약  
	
6장 명확하고 간결한 주석 달기
   01. 주석을 간결하게 하라  
   02. 모호한 대명사는 피하라  
   03. 엉터리 문장을 다듬어라  
   04. 함수의 동작을 명확하게 설명하라  
   05. 코너케이스를 설명해주는 입/출력 예를 사용하라  
   06. 코드의 의도를 명시하라  
   07. 이름을 가진 함수 파라미터 주석  
   08. 정보 축약형 단어를 사용하라  
   요약  
	
PART II. 루프와 논리를 단순화하기

7장. 읽기 쉽게 흐름제어 만들기
   01. 조건문에서 인수의 순서  
   02. if/else 블록의 순서  
   03. (삼항 연산자로 알려진)?:를 이용하는 조건문 표현  
   04. do/while 루프를 피하라  
   05. 함수 중간에서 반환하기  
   06. 악명 높은 goto  
   07. 중첩을 최소화하기  
   08. 실행 흐름을 따라올 수 있는가?  
   요약  
	
8장. 거대한 표현을 잘게 쪼개기
   01. 설명 변수  
   02. 요약 변수  
   03. 드모르간의 법칙 사용하기  
   04. 쇼트 서킷 논리 오용하기  
   05. 예: 복잡한 논리와 씨름하기  
   06. 거대한 구문 나누기  
   07. 표현을 단순화하는 다른 창의적인 방법들  
   요약  
	
9장. 변수와 가독성
   01. 변수 제거하기  
   02. 변수의 범위를 좁혀라  
   03. 값을 한 번만 할당하는 변수를 선호하라  
   04. 마지막 예  
   요약  
	
PART III. 코드 재작성하기

10장. 상관없는 하위문제 추출하기
   01. 소개를 위한 예: findClosestLocation()  
   02. 순수한 유틸리티 코드  
   03. 일반적인 목적의 코드  
   04. 일반적인 목적을 가진 코드를 많이 만들어라  
   05. 특정한 프로젝트를 위한 기능  
   06. 기존의 인터페이스를 단순화하기  
   07. 자신의 필요에 맞춰서 인터페이스의 형태를 바꾸기  
   08. 지나치게 추출하기  
   요약  
	
11장. 한 번에 하나씩
   01. 작업은 작을 수 있다  
   02. 객체에서 값 추출하기  
   03. 더 큰 예제  
   요약  
	
12장. 생각을 코드로 만들기
   01. 논리를 명확하게 설명하기  
   02. 라이브러리를 알면 도움이 된다  
   03. 논리를 쉬운 말로 표현하는 방법을 더 큰 문제에 적용하기  
   요약  
	
13장. 코드 분량 줄이기
   01. 그 기능을 구현하려고 애쓰지 마라 - 그럴 필요가 없다  
   02. 요구사항에 질문을 던지고 질문을 잘게 나누어 분석하라  
   03. 코드베이스를 작게 유지하기  
   04. 자기 주변에 있는 라이브러리에 친숙해져라  
   05. 예: 코딩 대신 유닉스 도구를 활용하기  
   요약  

PART IV. 선택된 주제들
	
   14장. 테스트와 가독성
   01. 읽거나 유지보수하기 쉽게 테스트를 만들어라  
   02. 이 테스트는 어떤 점이 잘못되었을까?  
   03. 이 테스트를 더 읽기 쉽게 만들기  
   04. 읽기 편한 메시지 만들기  
   05. 좋은 테스트 입력값의 선택  
   06. 테스트 함수에 이름 붙이기  
   07. 이 테스트 코드는 무엇이 잘못되었는가?  
   08. 테스트에 친숙한 개발  
   09. 지나친 테스트  
   요약  
	
15장. '분/시간 카운터'를 설계하고 구현하기
   01. 문제  
   02. 클래스 인터페이스 정의하기  
   03. 시도1: 순진한 해결책  
   04. 시도2: 컨베이어 벨트 설계  
   05. 시도3: 시간-바구니 설계  
   06. 3가지 해결책 비교하기  
   요약  
	
Appendix 추가적인 도서목록
   01. 높은 수준의 코드를 쓰는 방법을 다루는 책들  
   02. 다양한 프로그래밍 주제에 대한 책들  
   03. 역사적 사례를 담고 있는 책들  
   찾아보기



이 중 가장 유용했던 내용이라면 주석에 대한 내용입니다.

Doxygen을 쓰다보니 강제당한 주석이 너무 당연한 내용을 너무 많이 담고 있었습니다.


물론 제가 Doxygen 규격을 따라가다 느낀 장점은, 당연한 내용을 작성하던 중에 다시 한번 생각하게 된다라는 점이었는데요, 그런 점을 제외하고는 사실 커다란 이득을 보기 어려웠던게 사실입니다.


특히나 최초 작성시에는 그렇다쳐도, 추후 유지보수에는 더더욱이 큰 메리트는 없다고 볼 수 있었습니다.


그렇다고 주석이 필요 없는 코드가 좋다고 항변하기엔, 그런 코드만 작성할 수 있는 것도 아니고 말이죠.



생각을 기록하라라는 이야기도 꽤나 크게 와닿았습니다.


또, 결함을 설명하라는 이 책에 대한 만족도를 크게 높여줬다고 볼 수 있었죠.


TODO: 아직 하지 않은일

FIXME: 오작동을 일으킨다고 알려진코드

HACK: 아름답지 않은 해결책

XXX: 위험! 여기에 큰 문제가 있다.

TextMate:ESC (이게 뭔뜻인지 아시는분?)



조금 아쉬웠던 것은, 저도 반대하면서도 장점과 단점을 명확히 제시하고 싶었던 goto에대한 설명이 아주 짧게 쓰여있다는 점이었습니다만...뭐 그분들도 제대로 설명하기 어려웠던 걸려나요?



아참! 제가 요새 절실히 깨닳고 있는, 코드 분량줄이기 챕터도 아주 좋습니다.


일주일에 코드 몇만줄 짜냐느니 등으로 일을 열심히했다는 바로미터로 삼는 한심한 일도 비일비재하지만, 대다수의 능력있는 프로그래머들은 적은양의 코드를 작성하면서 원하는 목표를 달성하는 일이 얼마나 가치있는지 잘 아실테니까요.



책 페이지 수도 많지 않고 (부록 제외 240여 페이지), 내용들도 쉽게 쉽게 읽히는 편인지라, C++ 코딩의 정석 만큼이나 추천드리고 싶은 책입니다.


물론, C++ 코딩의 정석은 실수 사례도 모은 느낌이고, 이 책은 코드 작성 + 코드 읽기 관점이지만 말이지요.


팀 내 가이드로 삼아도 될만큼 좋은 책입니다. 추천!

Posted by 엘키 엘키

댓글을 달아 주세요



사실 나는 영화를 볼때 예고편이나, 영화에 대한 평가를 가급적이면 듣지 않으려고 한다.

첫째는 편견을 갖지 않기 위해서고, 둘째는 기대감을 갖지 않기 위해서다.

그렇지만 예외도 있는데, 내가 좋아하는 감독이나, 배우가 출연할 때에는 기대감을 갖고 보기도 한다. 이래 저래 예고편이나 관련 정보를 얻기도 하고.

책을 고를때에는 그와 반대로 최대한 많은 정보를 얻고 책을 선택한다. 잘못 선택한 책이 미치는 여파는 생각보다 크기 때문이다.

하지만 임백준씨는 나에게 너무 많은 영향을 주셨고, 임백준씨의 책에 너무 감명 받은 것들이 많은지라, 임백준씨의 책이라면 목차를 보지 않고도 바로 구입하곤 한다.

그리하여 목차도 모르고 받아본 이번 책은 프로그래밍과 상상의 연관관계인줄 알았거늘...!!

그간 기고하셨던 컬럼의 모음집이었을 줄이야...!!

잠깐 충격을 받았지만 다시 정신을 차려보니, 내가 읽었던 글은 하나도 없었다. (이런...마소 정기 구독해달라고 회사에 요청이라도 해야 하나?)

가격이 오른 만큼 페이지수도 두터워져서 읽을거리가 많아졌다는 즐거움에 책을 읽기 시작했다.

이 책을 읽기전에 나도 모르게 가졌던 생각은, 미국과 유럽의 개발 환경이 이상적일 것이라는 점이었다.

책의 서문에서도 밝히셨지만, 어느정도야 더 좋은 면도 있겠지만 전반적으로 우리와 크게 다르지 않다는 것을 알게 되었고, 미국에서도 기준에 부합하지 않는 프로그래머를 채용하게되 고생하거나, 유지보수 프로그래머로써 겪는 애환, 잘못된 기술 선택으로 인한 고통등 결국 문제는 사람(실제 같이 일하는 사람이거나, 나보다 전에 이 일을 했던 사람의 결정, 결과물 등... 결국 사람에 관련이 없을 수 없단 의미로)이었다.

내가 이 책을 읽기전에 고민했던 좋은 프로그래머의 자질에 대한 생각을 다시 하게된 챕터도 있었다.
 
내가 경험한 바로는 머리가 좋은 사람은 대부분 자신의 판단과 경험을 지나치게 의존해 같이 일하기 힘든 사람이 되곤 한다.

문제 해결 마인드도 차이가 났는데, 문제를 해결하는 능력자체는 뛰어났지만 문제를 단순화 시키려는 노력이나, 문제를 쉽게 풀려는 노력이 부족한 사람이 많았다.

그런 점들은 프로그램의 엔트로피를 상승 시키는 결과를 낳기 때문에 좋은 프로그래머라 할 수 없다.

내가 느끼기에 좋은 프로그래머란 어려운 문제를 푸는 사람보다, 어려운 문제를 쉽게 푸는 사람이라고 생각한다.

임백준씨는 이런 내 생각에 덧붙여, 꼼꼼한 사람이기도 하더라라는 의견도 제시해주셨다.

나는 일을 빠르게 처리하긴 했지만, 일을 많이 할 뿐 실속이 부족했다. 내 자신이 좋은 프로그래머라는 확신을 못갖는 이유가 바로 이런 부분에서다.

나는 프로그램을 작성하고 유지보수 할 때 큰 흐름을 보려는 노력을 많이했고, 실제로 그렇게 해왔다고 생각하는데, 전체적인 흐름에서 작은 변화가 끼칠 수 있는 파장에 대한 고민을 별로 하지 않는 나쁜 습관이 있다.

그렇다보니 문제가 발생했을 때 원인이 뭐였는지, 왜 그런 문제가 발생했는지는 빨리 깨닳지만 거기 까지였다.

문제가 발생하지 않을 만큼 침착한 검토를 하거나, 다양한 상황의 테스트를 거치지 않고 있었다.

내가 하는 일이 촌각을 다투는 상황일 경우가 빈번하고, 그런 상황일수록 복잡한 테스트를 거치기 힘들다는 점으로 봤을 때, 테스트는 편해야 하고, 어느정도 선까지는 자동화 되어있어야 한다.

또한 유닛 테스트 코드가 많아, 쉽게 모듈 테스트 할 수 있는 상황이 많다면, 코드간의 결합도가 낮다는 이야기고 그렇게 되어 있는 프로그램은 실수할 여지가 적다.

성급해질 수 있는 긴급 상황에서의 실수를 줄이는 것은 심리적인 요인을 다스리는 것도 중요하겠지만, 환경적인 요건도 중요하다.

사람은 누구나 실수할 수 있기 때문에, 실수할 여지를 줄이는 노력을 하는것이 좋은 프로그래머다 라는 생각을 갖게 되가는 요즘, 임백준씨도 비슷한 생각을 하셨다는 점에서 좋은 프로그래머에 대한 기준은 거의 다 비슷하구나 싶었다.

상황 중심 프로그래밍 (관점 지향 프로그래밍이라 주로 불린다는) 에 대한 이야기도 흥미로웠는데, 사실 서버쪽 프로그래밍은 유지보수에 대한 문제가 큰 이슈이기 때문에, 상황별로 쓰레드가 별도로 돌거나, 로직을 별도로 돌리며, 객체별로 결합도를 줄이려는 노력을 하고 있다. (아닌 서버가 있을지도 모르지만...적어도 내가 보거나 개발한 서버들에 한해선) 그래서 어떤 로직에서 얼만큼의 시간을 소요하고, 어떤 기능묶음별로 무언가를 해야 할 때 알 수 있는 방법을 이미 마련해둔 상태이지만, 그렇지 않은 경우라면 느끼는 점이 많을 챕터라는 생각이 들었다.

컬럼 모음집인 만큼 이외에도 프로그래머의 자질, 웹 2.0, 패턴, Pov-Ray와 같은 다양한 흥미로운 주제도 많이 접했다.

페이지를 너무 많이 쓰신상태이셔서인지 챕터 5는 PDF로 제공해주셨는데, 개인적으로 책으로 소장하는걸 더 좋아해서 가격이 조금 더 올라가더라도 책에 포함 되어 있다면 좋았겠단 생각이 들어 조금 아쉬웠다.

임백준씨의 책을 읽을때마다 느끼는 거지만, 글 솜씨도 좋으시고 일을 진정 사랑하는 프로마인드를 통해 나에게 늘 자극을 주시고 경각심을 일으켜 주셨다.

내 실력이 좋은지 나쁜지 여부는 큰 관심이 없었고 인기 있는 게임을 만들고 싶었을 뿐인 나에서 좋은 프로그래머가 되고 싶은, 진짜 '프로'그래머가 되고 싶은 맘을 갖게 해주셨고, 그 길을 몸소 실천하고 계신 임백준씨의 다음책이 벌써부터 기대된다.

PS: 혹시 임백준씨의 블로그나, 홈페이지 알고 계신분 알려주세요~! ^^;


Posted by 엘키 엘키

댓글을 달아 주세요

  1. Favicon of http://chaoskcuf.com BlogIcon chaoskcuf 2008.10.02 10:26  댓글주소  수정/삭제  댓글쓰기

    마소를 보다가 위의 책 소개를 보았는데요.
    저도 오늘 사서 읽어봐야겠네요~
    좋은 정보 감사합니다.

요새야 책으로 정보를 많이 접하고, 가급적이면 검색보다 책을 애용하는 편이지만, 아마추어 시절에는 책보다 다른 방법으로 정보를 얻어왔다.

인터넷과 PC통신 동호회, 홈페이지 등 워낙 좋은 내용이 나와있는 곳이 많았기 때문이다.

여러 곳에서 얻은 정보를 정리해가며 공부하는 경우도 많았고, 책이 워낙 비싸기도 해서 많이 사보기도 뭐했기도 했다.

그러던 내가 2003년 대학에 입학하면서부터, IT 교양서나 '성공과 실패를 결정하는 ~' 시리즈 등을 보기 시작했다.

가벼운 마음으로 본 책들이었지만, 그 중에서도 가장 즐겁게 보았던 것이 바로 '누워서 읽는 알고리즘' 이라는 책이었다.

사실 내 마인드가 워낙 게임 개발에 치중되어있어, '구현만 되면, 코드야 어떻든 상관없다!'는 마인드가 컸다.

아마추어 게임의 특성상 유지보수 할일이 많지도 않고, 하게 되더라도 뭐 잠깐인데 어때? 이런 생각을 갖고 관리함에도 큰 문제를 겪은적 없었고, 속도 역시 크게 중요치 않았다.

'누워서 읽는 알고리즘'은 그런 내 마인드를 바꿔놓기 충분했다. 나를 설레게 했다고 할까?

프로그래밍을 '수단'에서, '그 자체'를 즐길 수 있도록 해주었다. 책을 읽는 내내 프로그래밍이란 과정이 얼마나 즐거운 일인지 알게 되었고, 누워서 읽는 알고리즘의 재미난 퍼즐들을 더 한 프로그래밍에 대한 임백준씨의 마음이 전해져왔다.

딱히 누군가를 존경하고 이런 성격이 아니었던 나로써 믿기진 않지만, 임백준씨와 같이 멋진 (프로그래밍 실력도 좋으시겠지만, 그것 과는 별개라도) 프로그래머가 되고 싶어졌다.

임백준씨의 저서는 모두 읽어봤는데, 역시나 박식하시고, 재밌게 풀어나가는 글솜씨가 멋졌다.

개인적인 바램이지만 임백준씨가 해외에 계셔서 쉽지 않겠지만, 국내 세미나 한번 열어주셨으면 하는 바램이 있다. 실현 가능성이 높진 않겠지만 말이다.

바쁜 일정 속에서도 꾸준히 노력하시며 좋은 책을 내주시는 임백준씨의 새책이 어떨지 벌써부터 기다려진다.

강컴에서 절찬리 예약중~!
http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200808250003 

'BlahBlah' 카테고리의 다른 글

좋은 프로그래머란 무엇일까?  (4) 2008.09.07
단점 고치기에 대한 썰  (0) 2008.09.06
프로그래밍은 상상이다 예약중  (1) 2008.08.26
Software Development MEME  (0) 2008.07.14
MSDN 2008 세미나를 다녀와서  (4) 2008.02.24
나의 게임업계 투신기  (8) 2008.02.14
Posted by 엘키 엘키

댓글을 달아 주세요

  1. Favicon of http://www.xevious7.com BlogIcon xevious7 2008.08.26 21:24  댓글주소  수정/삭제  댓글쓰기

    오.. 저도 프로그래밍은 상상력이다라고 쭉 생각하고 있었는데 같은 생각을 가진분이 있군요
    저도 내용이 궁금하네요 :) 지난 2월에 프로그래밍은 상상력이다 라는 포스트를 비공개로 쓴적이 있었는데
    이 글을 보고 공개했습니다. ㅎㅎ



웃기는 이야기일지 모르지만, 사실 나는 게임이 좋아서 프로그래밍을 시작했다.

게임을 만들고 싶은데, 그래픽(간단한 그림도 많이 못그리는 편이다)에는 너무 소질이 없었고, 기획이란 분야는 너무 막막한 상황이었기에, 선택한것이 프로그래밍이었다.

그러나 그 시작과는 달리, 갈수록 프로그래밍의 매력에 빠져들었고, 프로그램을 만든다는 그 자체를 즐기게 되었다.

나에게 주어진 문제를 해결했을때 오는 짜릿함? 내가 만든것이 컴퓨터안의 가상 세계(이 표현은 틀렸을지도 모른다. 왜냐면 컴퓨터안의 세계는 저자의 말대로 bit로 이루어진 현실에 존재하는 세계이기도 하니까)에서 나의 발상을 코드화해서 그것을 구동하였을때의 즐거움? 이런건 무엇과도 바꿀수없는것이었다.

그러나 그 즐거움을 잊을때가 많았다.
어떠한 프로젝트를 위해선 선행작업들이 많고, 관련 분야에 대한 지식이 부족한 경우에는 그와 병행하느라 더 바빠지기 마련이다.
시간이 갈수록 코드를 읽거나 작성하는것은 심리적으로 쫓기는 상황에서 이루어지는 경우가 많았고, 아무리 좋은 설계를 해도 좋은 코드가 나오는 경우는 적었다.
일을 즐기기는 커녕 일에 쫓기는...그런 상황들이 날 힘들게 하고 있었다.

누워서 읽는 알고리즘을 읽을때도 느낀것이지만, 자신에 일에 프라이드를 가지고 있고, 진정 애정을 가진, 그리고 그 기분을 나에게도 가지게 해준 임백준씨에게 경의를 표한다.


Posted by 엘키 엘키

댓글을 달아 주세요


이전에 임백준씨의 책들을 감명깊게 읽었던지라 이번책도 큰 기대를 품고 읽게 되었습니다.

그의 철학에 녹아있는 이야기들은, 자신에 철학과 글에 대한 믿음이 절로 이해가 되는 책들이라 매우 와닿았었죠.

이번책의 내용은 소프트웨어 방법론에 대한 이야기였는데, UML, 리팩토링, XP, 디자인 패턴등 다양한 방법론에 대한 이야기를 듣고 관련 서적을 접해보았지만, 딱히 와닿지는 않았던게 사실입니다.

설계가 잘 되어진 프로그램이 더 좋게 나올것이라는 생각은 늘 가지고 있었지만, 과연 UML의 다이어 그램을 통해서 프로그램을 좋게 만들수 있을까? XP는? 리팩토링은?? 늘 의구심이 들었습니다. 예외로, 디자인 패턴은 그 활용 가치에 공감했지만 말이죠.

특히나 리팩토링의 경우는 더더욱이 그런 편이었는데, 임백준씨가 책안에 적어놓은 코드안에 철학은 진정한 객체지향으로 향해 가는 코드를 보였고, 의미없는 클래스와 객체의 남발에 대한 일침을 가했다고 봅니다.

책안에 UML에 대한 이야기는 없었지만, 결과적으로 소프트웨어 방법론에 대한 핵심적인 이야기를 들음으로해서, 그것들이 필요하고, 왜 필요한지에 대한 "동기부여"가 됨으로써 그 가치가 더 높았다고 생각합니다.

자칫하면 한동안 (언젠가는 필요로 했을지 모르지만) 장식품 역할을 할뻔한 소프트웨어 방법론 서적들에 필요성을 높여준 이번 책도 역시 임백준씨라는 생각이 드네요.

프로그래머 K씨의 하루의 경우는 시도는 좋았던것 같았지만, 본책의 페이지를 줄이며 등장할것이 아니고, 기본적인 내용이 일정 페이지수를 만족하며, 부가적인 요소로 삽입되었으면...하는 아쉬움이 있었지만 나쁘지 않았다고 생각합니다.

여전히 방법론에 회의적인 분들을 위해 이 책을 추천하며...


Posted by 엘키 엘키

댓글을 달아 주세요



토요일에 읽기 시작해, 일요일에 끝냈으니 매우 금방 읽은 책이다. 그만큼 재미있게 읽었다.

임백준씨의 저서는 모두 다 갖고 있고, 임백준씨의 철학에 깊은 감명을 받은지라 이번 책도 기대를 하지 않을 수 없었다.

이 책에서 가장 인상 깊었던 인물은 로버트였다.

사실 나는 실수를 잘 견디지 못한다. 내가 실수를 하고 나면 모두가 나를 원망하는 것 같고, 내 잘못이 너무 크게 느껴져 괴로움에 몸부림 치곤하니 말이다.

실수를 두려워 하는 사람은 성장할 수 없다는 본문의 내용을 보고 많은 것을 느꼈다.

내 실수를 변호하고, 옹호하려는 것이 아니라, 실수에서 얻는 것이 있다면 그 실수를 두려워 할 필요가 없는 것 아닌가?

그런 생각이 드니 내 마음이 조금은 편해지는것 같았다. 꼼꼼한점이 부족하고, 빠른 결과물을 내려다 실수하는 내 자신이 한심해지기도 했지만, 그런 문제점을 나 자신이 파악하고 있고, 나아지고 있는 중이라는 점으로 위안을 삼았다.

긴박한 상황에서 버그를 잡을 때, 사실 나는 일반적인 상황에서, 로직적인 상황에서의 추리를 하곤하는데, 톰의 일반적이지 않은 상황까지 추리해내는 기지에는 감탄을 금치 못했고, 프라빈과 같은 천재 이야기를 보면서는 프라빈 정도는 아니더라도 천재라 느낄만한 프로그래머를 만나봤던 나로선 모짜르트라는 천재를 보고 괴로워했던 살리에르의 기분을 다시금 떠올리게 되었다.

이브와 같은 마인드는 아니었지만, 이브 처럼 우연에 맡기는 프로그래밍을 하는 실수했던 날, 이만큼 성장하게 도와준 동료들도 고맙고, 지금껏 나를 돌아볼 수 있는, 내 마음을 다 잡을 수 있는 좋은 책이었다고 생각한다.

아직 현업에 뛰어들지 않은 프로그래머 지망생들이 이 책을 본다면, 이브와 같은 한심한 마인드를 가지지 않으면서, 로버트처럼 실수에 지나치게 괴로워 하는 용기없는 사람이 되지 않았으면 좋겠다는 생각이 들었던 책이다.


Posted by 엘키 엘키

댓글을 달아 주세요

이전버튼 1 이전버튼

블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today27
Total1,605,481

달력

 « |  » 2020.8
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

글 보관함