Empty

---

조엘 온 소프트웨어

저자

조엘 스폴스키 지음

출판사

에이콘출판 | 2005-04-15 출간

카테고리

컴퓨터/IT

책소개

2005년 15회 JOLT상 수상작! 아마존 선정 컴퓨터 인터넷...

---

Aㅏ......

드디어 다 읽은 이 책 ㅠ_ㅠ...

날 너무 힘들게 했다 orz 

고작 책 하나 읽는데 무려 4주 이상 걸린 듯 싶다.

읽고 싶은 책으로 시작해서 읽어야만 하는 책으로 끝나버렸다. 

- 억지로 꾸역꾸역 읽은 듯한 느낌이라 - 지금 리뷰를 쓰는 이 시점에도 

뭔가 찜찜하고 반성해야만 할 것 같은 기분이다.

그래서 보통 같으면 목차를 하나씩 훑으면서 자세히 리뷰를 썼지만

이번에는 기억에 남는 일부 장에 대해서만 리뷰하겠다. 

(이 책은 제대로 못 읽었다는 느낌이 강해서 차후 다시 읽을 책 리스트에 올랐다 OTL)

→ 근데 막상 책을 다시 훑으면서 쓰다보면, 나름 자세히 쓰게 되더라.

< 1부 > 비트와 바이트 : 프로그래밍 실전

1장. 언어 선택

- 순수 C :  빠른 속력이 필요할 때

- MFC, C++ : 배포판 크기를 윈도우용으로 최소화 해야 한다면 정적 링크 언어를 선택

- JAVA : 맥, 윈도우, 리눅스에서 돌아갈 GUI 가 필요할 때 (GUI 가 완벽하지는 못하겠지만 실행은 되니까)

- Visual Basic : 작업 시간이 충분하지는 않지만 멋지게 보이는 GUI 를 만들어야 할 때

(하지만 배포판 크기가 커지는 데다가 윈도우에 묶여야만 한다는 단점이 있음)

- Perl : 속력에 무관하며 어떤 유닉스 기계에도 돌아가는 명령행 도구가 필요할 때

- JavaScript : 웹 브라우저 내부에서 동작해야 한다면 피할 수 없는 녀석

- SQL 내장 프로시저 부문 : 몇몇 회사에서 제공하는 독점적인 SQL 파생 버전을 이용해야만 함

=> 05년도 책이라 이보다 더 나은, 상황에 따라 더 적절한 언어들이 생겼을 수도 있겠지만

그래도 참고할 만한 내용이라 남겨본다. 요새 VB 를 쓰는 곳이 있나 싶기도 하고...

'VB 대신에 WPF 를 쓰지 않나?' 라는 생각이 든다. 잘은 모르겠다.

2장. 기본으로 돌아가기

- 소프트웨어 개발에 있어 최하위단 에서 벌어지는 단순한 동작 원리에 대해 논한다.

이 장의 내용은 책에서 완전 초반에 다루는 내용인데다 내가 이 책을 읽는데 4주가 걸렸음에도

블로그에 꼭 남기고 싶다는 생각을 한번도 잊은 적이 없다.

- C언어에서 문자열이 동작하는 방법에 대해...

void strcat(char* dest, char* src)
{
    while(*dest) dest++;        // NULL 문자열을 찾아간다
    while(*dest++ = *src++);    // dest 뒤에 src 글자를 하나씩 붙여나간다
}

눈치챘겠지만 이 코드에는 문제가 있다.

어떤 문자열에 여러 개의 문자열을 이어 붙이기 위해 이 함수를 여러 번 호출한다면...

NULL 을 찾기위해 1번째 while 루프를 미친듯이 돌려야 한다. (러시안 페인트공 알고리즘)

이를 해결하는 건 간단하다.

char* strcat(char* dest, char* src)
{
    while(*dest) dest++;        // NULL 문자열을 찾아간다
    while(*dest++ = *src++);    // dest 뒤에 src 글자를 하나씩 붙여나간다
    return --dest;    // 마지막 문자열의 위치를 반환, 이유는 첫번째 while 문 참고
}

이렇게 하면 O(n²) 의 복잡도를 O(n) 으로 줄일 수 있다.

너무 당연한 거 아니냐고 생각할 수도 있지만 글쎄...

그래도 중요하다고는 생각하니 남기고 싶었다. 기본이니까.

- malloc 은 어떻게 동작할까?

malloc 의 본질은 사용 가능한 메모리 블록을 Linked List 로 길게 연결한 Free Chain(자유 체인) 이다.

malloc 은 Linked List를 따라가며, 요청받은 메모리 양보다 큰 블록을 찾는다.

이렇게 찾은 블록을 2개로 쪼개서 하나는 호출한 사용자에게 반환하며, 

쪼개고 난 다음에 남아있는 블록은 다시 Linked List에 넣어둔다.

free를 호출할 때, free 는 해제한 메모리를 Free Chain에 추가한다.

결국 Free Chain 은 자그마한 조각으로 잘게 쪼개지므로, 

큰 메모리를 할당 받기 원할 때 원하는 크기를 충족하는 조각이 없을 수도 있다.

이럴 경우 malloc이 Time out을 선언한 다음에 Free Chain 주위를 샅샅이 훑어 조각을 정렬하고,

인접한 작은 자유 블록을 더 큰 블록으로 결합한다.

결국... malloc 의 성능이 결코 아주 빠르다고 볼 수 없다. (malloc은 항상 Free Chain을 돌아다님)

정리하는 과정에서 종종 예측할 수 없을 정도로 너무 느려질 수 있다는 사실을 알게 된다.

덧붙여 말하자면, 이런 현상은 Garbage Collection을 지원하는 시스템과 동일한 성능 특성이며, 

시스템 성능 저하 원인이 Garbage Collection 이라는 주장이 전적으로 옳지만은 않다는 결론에 도달하게 된다. 

- 똑똑한 프로그래머는 항상 2배수로(4, 8, 16...) 메모리 블록을 할당하는 방법으로

잠재적인 혼란을 최소화 한다. 이렇게 말하면 상당히 큰 공간을 낭비하는 듯이 보일 지는 몰라도

항상 50% 이하로 기억공간을 소비한다는 사실을 확인할 수 있다고 한다.

=> 솔직히 이부분은 이해가 잘 안 된다ㅡㅡ........orz

- JAVA 에서 얼핏 알고 있었던 이야기지만...

String 클래스와 String Builder 클래스의 차이점을 따져 2가지 중에서 무엇을 사용할 지

생각해야 할 필요가 있다. 차이점은 스스로 찾아보자. 나도 어쩌다 누군가의 블로그에서

차이점을 알게 됐는데, 꽤 중요한 내용이라고 생각했지만 따로 정리를 안 했다. 차후 포스팅 하겠다.

3장. 조엘 테스트 : 더 나은 코드를 위한 12단계

개당 1점씩, 10점 이하는 심각한 문제가 있다고 한다.

이 테스트에 대해서는 난 노코멘트 하겠다. 잘 모르겠다.

4장. 개발자가 꼭 알아두어야 할 유니코드와 문자 집합에 대한 고찰

ASCII 코드 : 32 ~ 127 사이의 숫자를 이용해 영문 표현이 가능. (32 는 공백(space))

7비트로 글자를 저장할 수 있다.

하지만 대다수의 컴퓨터가 8비트인 바이트 단위를 쓰기 때문에 ASCII 에서는 1비트가 남게된다.

즉, 128~255 사이에 위치한 코드를 마음대로 요리할 수 있다는 이야기이다.

그래서 이 사이에 어떤 값을 넣느냐에 대해서 많은 사람들이 동시에 동상이몽을 하게 된다.

IBM PC가 고안한 OEM 문자집합(유럽형 언어를 위한)를 시작으로 

온갖 OEM 문자 집합 형식이 생겨나면서 각 언어권 별로 용도에 맞게 128 글자를 정의했다.

예를 들어 A 나라에서는 resume 으로 보이는 글자가 B 나라에서는 rλsumλ 이런 식으로

보일 수 있다는 이야기이다.

이런 상황 속에 ANSI 표준 위원회에서는 ANSI 표준을 만들어 이 난투극를 끝냈다.

하지만 여전히 지역에 따라 128 이상 문자를 다루는 여러 방법이 존재했고 

이렇게 각기 다른 시스템을 '코드 페이지'라고 부른다.

그런데 여기서 생각해봐야할 건 아시아권 코드 페이지 이다. 

아시아 문자집합은 8비트로 표현하기에는 부족하다는 점이 사람을 골 때리게 한다.

그래서 DBCS(Doublc Bytes Character Set) 이라 하는 2바이트 문자 집합 시스템으로 해결하게 된다.

몇몇 글자는 1바이트로, 다른 글자는 2바이트에 저장하는 방식인데 짜증나는 부분이

문자열을 따라 쉽게 앞으로 나갈 수는 있어도 뒤로 돌아오기에는 무척 번거롭다는 점이다.

문자열에서 왔다갔다 하기 위해 s++, s-- 만으로는 안 된다는 점인데 그래서 윈도우에서는

AnsiNext, AnsiPrev 같은 함수를 쓰도록 독려했대나 뭐래나.

결국 8비트로는 안 되겠다 싶어 나온 게 사랑스러운 Unicode.

많은 사람들이 유니코드가 16 비트(2바이트)로 표현되기 때문에 

65536 개의 문자만을 사용할 수 있다고 생각한다는데(나도 그랬고), 

사실 이미 코드 숫자가 65536 를 넘었다고 한다.

모든 유니코드 글자는 실제로 2바이트로 압축할 수 조차 없다고 한다. (싱기방기ㅇㅅㅇ)

Unicode 는 실제로 글자를 다루는 일종의 철학이라고 한다. 각 글자에 존재하는 관념적인 철자마다

고유 번호를 붙여놓았고 'U+0645' 식으로 표현한다고 한다. (U+는 유니코드, 숫자는 16진)

저런 식으로 표현한 것을 '코드 포인트' 라고 한다.

여기서 머리 아프게 '인코딩' 이야기가 나온다.

예를 들어서 'Hello' 를 유니코드로 표현해보겠다.

U+0048    U+0065    U+006C    U+006C    U+006F

이 코드 포인트 숫자를 각각 2 바이트로 저장하면, (Big Endian)

00 48     00 65     00 6C     00 6C     00 6F

여기서 다른 표현법이 있다고 하면, (Little Endian)

48 00    65 00    6C 00    6C 00    00 6F

그지같게도(?) 글자 표현법이 Big Endian, Little Endian 으로 나뉘게 되어

유니코드 저장 방식이 2가지로 나뉘어 버리게 된다. 

따라서 이를 구분하기 위해 유니코드 문자열 시작 부분에 

FE FF 를 저장하는 관례가 생기게 된다. (UTF-16/Little Endian 의 경우)

이를 유니코드 바이트 순서 표시라고 부르며, 상위와 하위 바이트 순서를 바꿀 경우 FF FE로 보이게 된다.

아무튼 유니코드 인코딩 초기 방식이 이따구여서(?) 

미국 국적 프로그래머 사이에서 이야기가 상당히 많았던 것 같았다.

일반 영문 텍스트의 경우 U+00FF 상위에 존재하는 코드 포인트를 거의 사용하지 않기 때문이래나 뭐래나.

나는 아시아권이니 저 인간들이 느끼는 감정따위 이해할 수 있을리가.

하지만 이 때 'UTF-8' 이 등장하게 된다.

유니코드 코드 포인트를 따르는 문자열을 저장하기 위한 또 다른 시스템으로,

8 bit 인 1 바이트를 사용해 매직 U+넘버를 기억 공간에 저장한다.

0~127 사이에 존재하는 모든 코드 포인트를 단일 바이트로 저장하고,

128 이상인 코드 포인트만 2, 3 바이트에서 시작해 최대 6바이트까지 확장해서 저장한다.

이런 방식을 적용할 경우 모든 어떤 코드 포인트도 올바르게 저장할 수 있다는 특성을 얻게 된다.

조엘님이 이 장에서 가장 강조하는 것은

"일반 텍스트 라는 개념은 존재하지 않는다."

인코딩 방식을 모르는 문자열은 아무 의미가 없기때문에

메모리, 파일 또는 e-mail 내부에 문자열이 있으면 이 문자열 인코딩이 무엇인지 알아야만 하며, 

그렇지 않으면 그 문자열을 해석할 수 없어 사용자에게 올바르게 보여줄 수 없다는 것이다.

문자 집합에 대한 역사적인 관점으로 쭉 훑어 보았는데~~

평소에 이와 관련된 에피소드가 있다면..

DB에서 데이터 저장하다가 인코딩 때문에 빡쳤던 경험과 기타 웹 개발 경험,

최근에는 바이너리 파일 까보다가 Little Endian 표기법으로 약간의 삽질을 했던 경험 정도?

꽤나 심오한 세계인 것 같기도 하고 아무튼 어렵다 ㅡㅡ;; 

조엘님은 결코 어렵지 않다고 하지만 전 어렵네요 ㅇㅇ..orz

범상용화적인 소프트웨어를 개발하려는 분, 혹은 하시는 분들은 반드시 알아야 할 내용이 아닌가 싶다. 

물론 나도 이해하려고 이 장을 몇 번이나 뒤적거렸다. 언젠간 다시 찾아보게 될 내용이라 생각된다.

조금 찜찜한 게 있다면 내가 이렇게 막 장황하게 적었는데도

잘 이해가 안 되는 것 같다 ㅋㅋㅋㅋ 으앙 모르겠다

15장. 쏘면서 움직여라 

요즘 신입의 자세로 열심히 노력하면서도, ""잘"" 하는 사람으로 거듭나고자 

스스로를 궁지에 모는 행동을 많이 하는 것 같아 내심 스트레스가 많이 쌓여서 우울했었다.

(사실 지금도 약간 그런 상태지만)

그런데 이 장을 읽으면서 조금이나마 위안을 얻을 수 있었다.

첫 줄부터 '저는 가끔 일이 전혀 손에 잡히지 않을 때가 있습니다' 라고 적혀있다.

업무효율이 떨어지는 기간이 하루, 이틀.. 심하게는 몇 주를 허비하게 되는 때도 여러 번 있었다고 한다.

일에 몰입하기는 커녕 흐름을 타지 못 했고, 자신의 존재가 마치 사라져버린 것 같았다고.

그리고 자신이 실제로 하루에 생산성 높게 코딩을 하는 시간이 

고작 2~3시간에 불과하다는 사실이 무척 괴로웠다고 한다. 

즉, 하루동안 일에 몰입하기까지의 장벽은 너무나도 높다는 것이었다.

그 장벽만 넘으면 일에 몰입해 생산성을 높일 수 있는데.

그런데 너무 이런 압박감에 시달릴 필요가 없다는 것을 깨닫게 된 것이

군대에서 '적들을 향해 총을 쏴서 적의 머리를 숙이게 만들고, 그 시점에 적과의 거리를 점차 좁혀간다'라는

엄호 사격 전술을 알게 되었을 때부터 15년이 지난 후였다.

내가 움직이지 않으면 적군은 무슨 일이 벌어졌는지 눈치채게 되고,

내가 쏘지 않으면 적이 사격해 나를 꼼짝 못하게 만들 것이다.

그러니 매일 조금씩 움직여야만 한다고 한다.

코드가 ㅄ같고 아무도 원하지 않는다는 사실이 문제가 되는 것이 아니라는 것이다.

늘 조금씩 움직이면서 코드를 쓰고 버그를 지속적으로 잡아낸다면, 시간은 내 편이 된다는 것이다.

다음은 책에서 그대로 따왔다. 내가 요약해서 적을 수도 있겠지만,

담담하게 풀어 쓴 문체 자체까지 내게는 위안이 되었기 때문에 인용하겠다.

매일 조금씩 앞으로 나아가야 합니다. 이렇게 하다보면 조만간 당신이 이길 것입니다.

어제 하루동안 제가 한 일이라고는 FogBUGZ 에서 컬러 정책을 조금 개선한 사항뿐입니다.

이 정도면 충분합니다. 조금씩 발전해 나가는 겁니다.

날이 갈수록 우리 소프트웨어는 점점 더 좋아지며, 더 많은 고객을 확보할 수 있다는 점을 노릴 뿐입니다.

Oracle 정도로 큰 회사가 되고 난 다음에 거대한 전략을 생각해도 늦지 않습니다.

매일 아침 출근해서 에디터를 여는 것만으로도 충분합니다.

16장. 장인정신 

요약하면, 장인정신이 필요한 경우가 있는 건 이해하지만

모든 소프트웨어 개발에 항상 장인정신을 투자할 필요는 없다고 충고하는 장이다.

나의 경우는 완벽주의자에 가깝기 때문에 이것저것 사소한 것에도 까다롭게 구는 경우가 많다.

하지만 조엘님은 나같은 사람에게 날카롭게 지적하듯이 

'1%의 결함을 고치기 위해 500% 달하는 노력이 필요할 수 있다. 

그럼에도 불구하고 추가 비용을 감당할 정도로 충분한, 고칠 가치가 있는 결함인가?' 라고 해주셨다.

일반 소비자를 위한 상용 소프트웨어, 또는 상품 소프트웨어를 개발하는 방법만이

장인정신에 투자할 수 있는 유일한 길이라고 한다. => 장기간에 걸쳐 경쟁우위를 제공하는 핵심 요인이 될테니까.

(사내용 인사 관리 프로그램 같은 경우, 이런 장인정신을 뒷받침할 수준까지 이르지 못한다)

왠지 예전에 내가 인턴 생활을 할 때 사내용 프로그램 개발에

투철한 장인정신을 발휘했던 내 모습을 떠올리게 된다. 으으.

< 2부 > 개발자 다루기

20장. 인터뷰를 위한 게릴라 가이드

- 조엘님이 말한 채용 프로세스 : 

1) 이력서 : 

i. 실수가 많은 이력서 버린다 (ex. Windows를 Window로 썼다든가) : 꼼꼼한 사람을 뽑기 위해

ii. 과거에 특별히 어려운 선별 과정을 거친 경험이 있는지 (ex. 입학 기준이 높은 대학, 깐깐하게 사람 뽑는 회사)

2) 전화 인터뷰 :

i.  프로그래밍 문제 하나로 한 30분 정도 이야기를 나눔 (ex. XML Parser 를 어떻게 짜실 건가요?)

3) 대면 인터뷰 :

i. 면접관은 적어도 6명은 되야 하고, 최소 5명은 동료 프로그래머로 채운다.

   이 중에서 2명 이상의 면접관이 지원자가 별로라고 하면 고용을 안 하는 게 낫다고 한다.

ii. 지원자를 동시에 인터뷰 하지 않고, 각 인터뷰는 화이트보드가 있는 방에서 1:1 로 진행한다.

- 조엘님이 생각하는 좋은 지원자 : 

i. 똑똑하다.

- 잡다한 지식을 많이 알아야 한다는 것이 아님

(ex. 오라클 8i에서 varchar와 varchar2 의 차이 => 인터넷에서 15초면 찾을 수 있는 내용)

ii. 업무를 성실하게 완수한다.

사람을 파악할 수 있는 방법은 말할 기회를 주는 것이기 때문에

개방형 질문이나 문제를 던져야 한다고 한다. 그러면 어떤 질문을 해야하는지 다음을 살펴보자.

(※ 참고로 조엘님은 면접 전에 지원자에 대한 선입견을 품지 않으려고 극도로 조심한다고 한다. ex. 학벌)

- 해야할 질문 :

1. 첫 인사 

- 지원자를 편하게 해주려는 목적으로, 여기서 첫인사는 지원자가 하는 인사라기 보다는

면접관이 지원자에게 하는 인사이다. (ex, 오는 길이 어땠는지, 면접관 소개, 인터뷰 진행 방식 등)

2. 최근 프로젝트 경력에 대한 질문

- 개방형 질문의 예시 :

ex. 지난 학기에 들은 수업 중 가장 좋아했던 수업은 무엇이죠? 전산 과목이 아니어도 좋습니다.

ex. 전 직장에서 했던 최근 프로젝트는 어떤 프로젝트 였나요?

- 개방형 질문을 던져놓고 초점을 맞춰야 할 자질 3가지 :

i. 열정 : 

똑똑한 사람은 자신이 수행한 프로젝트에 대해서 열정적으로 말하게 됨

(이야기를 하면서 흥분하게 되고 말이 빨라지고 손짓이 따르게 됨),

반면 인터뷰 내내 무덤덤한 사람은 별로.

ii. 상대 수준에 맞게 설명 :

다른 사람에게 자기 아이디어를 납득 시키기 위해서는 어떤 태도를 취해야 되는지 아는 사람인가.

iii. 팀 프로젝트 였다면 리더십을 발휘했을 것 같은지

3. 답변 불가능한 질문

- 한때 구글에서 나왔었다는 면접 문제들...(짜증) :

ex. LA에는 주유소가 몇 개나 있을까요? 워싱턴 기념탑 무게는 몇 톤일까요? 등등

- 문제 해결 능력 + 창의력 이 있는 사람인지 :

지원자가 당황해 하면 힌트를 던져주되, 계속 멍청하게 앉아 있는 경우

이 사람은 구조의 손길만을 기다리는 사람으로 문제 해결 능력이 부족하다고 판단.

4. 프로그래밍 문제

- 종이 주고 손코딩 : 코드가 10줄 넘는 문제는 피하자. 

문제들을 보면 실제 N사가 이걸 보고 베낀 듯한 면접 질문들 몇개 있음...

i. 원래 저장위치에서 문자열을 역순으로 변환하기

: 함수 성능이 어떤지, strlen 함수를 몇 번 호출했는지 판단, O(n) 이면 충분함에도 불구하고 

루프 안에서 strlen 을 계속 호출하는 바람에 O(n²) 인 strrev() 를 본적도 있다고.

ii. Linked List 를 역순으로 만들기

: 똑똑한 지원자라면 바로 코드를 안 짜고 구현 전에 계획을 짤 것이다.

아마 옆 귀퉁이에 네모와 네모를 연결한 화살표를 그리기 시작할 것임.

iii. 한 바이트에서 1인 비트 세기

: C 비트 연산을 아는지 확인하려는 의도가 아님,

똑똑한 지원자는 1번만 만들면 되는 참조표를 이용할 것임(많아야 256 개니까)

또는 처음에만 bit 를 세서 참조표에 저장하는 캐쉬 사용을 제안 등등...

목적은 코드를 다듬고, 최적화하고, 개선할 방법을 찾아내는 능력이 있는지 보기 위함.

iv. 이진 검색

v. 문자열에서 '연속적으로 문자가 반복되는 길이(run-length)'가 가장 긴 부문문자열 찾기

vi. atoi

vii. itoa (스택이나 strrev 를 써야하기 때문에 좋은 문제)

좋은 프로그래머라는 증거 몇 가지 :

i. 간단한 규칙이라도 변수 명명법을 사용.

ii. C에서 상수는 "==" 왼쪽에 두는 버릇.

(ex. if (x == 0) 이 아니라 if (0 == x) 라고 쓴다든가)

iii. while 루프에서 변하지 않는 값이 무엇인지를 본능적으로 안다.

(ex. while (index <= length) 가 아니라 while (index < length)

iv. C++에서는 가상 소멸자를 사용한다.

5. 자신의 코드에 만족하는가?

- 4.에서 작성한 코드에 만족하는지 물어본다

- 손코딩이다 보니 실수는 하기 마련, 하지만 실수를 찾아낼수 있어야 한다는 게 포인트.

ex. 문자열 함수에서 NULL 종결자, 세미콜론, 길이가 0인 문자열이 들어오면 안 돌아가거나, 

malloc이 실패하면 GPF가 발생. (General Protection Fault 의 약자, 

프로세서의 메모리 보호 하드웨어가 잘못된 주소 접근을 잡아낼 경우 발생한다)

6. 질문이 있는가?

- 우수한 지원자는 직장을 선택할 수 있기 때문에 면접관은 일방적으로 인터뷰를 하는 입장만은 

   아니라는 사실을 명심해라. 인터뷰는 상대방도 여기가 일할 만한 곳인지 파악하는 시간이다.

   (가끔 면접관들 중에 상당히 거드름 피우는 ㅄ 같은 놈들도 많다, 회사에 대한 이미지를 다 깎아먹음)

- 일부 면접관은 총명한 질문을 하는지 판단하려고 들지만 조엘님의 경우, 

이 시점에서 어떤 질문을 하든 이미 결정을 내렸기 때문에 개의치 않는다고 한다.

하지만 꽤 흥미롭거나 인상깊은 질문으로 붙었다는 이야기도 많이 들어봤다.

26장. 허술한 추상화의 법칙

모든 쓸 만한 추상화에는 어딘가에 구멍이 존재합니다.

-> 차후 이 책을 다시 읽을 때, 이 부분을 자세히 읽고 분명히 이해해야 할 필요가 있다고 느낌.

지금의 나로서는 사실 이해가 잘 안 되서 ㅠ_ㅠ 중요 문구만 남기겠다.

< 3부 > 조엘 따라하기

31장. 말단이면서도 해내기

- 전략 1 : 혼자라도 하십시오

일일 빌드 서버가 없다면? 만들면 된다. 밤마다 일일 빌드를 돌리고, 다른 팀원에게 이메일을 보내라.

빌드 단계가 너무 복잡하다? makefile 을 써라.

사용편의성 테스트를 아무도 안 한다? 종이나 VB 프로토타입을 사무직 친구에게 보여주면서 직접 테스트 해라.

- 전략 2 : 입소문의 힘을 이용하십시오

전략 1과 비슷한 내용이라 생략.

- 전략 3 : 우수한 인재를 모으십시오

이 내용이 왜 이 장에 포함되어 있는지 잘 모르겠다. 말단이라면서

우수한 인재를 팀으로 끌어들이라면서 채용과 인터뷰 업무에 참여하라고 한다.

말단이 그게 가능한 건가? 아니면 조엘님이 말하는 '말단'이 내가 생각하는 '말단'이랑은 다른 건가?

- 전략 4 : 고문관은 봉쇄해야 합니다

고문관이란 질 낮은 코드로 다른 질 좋은 코드까지 더럽히는 사람을 일컫는 말이다.

이 사람의 코드를 보면 마음 같아서는 전부 버리고 새로 다시 짜고 싶겠지만 참아야 한다!!

그냥 내버려 두고 코드에서 생기는 버그를 계속 보고 한다.

그러면 고문관은 보고할 버그가 없어질 때까지 그 작업에 매달리게 될 것이다.

다시 말해 다른 코드를 해치지 않을 것이다. (진짜 그런지는 솔직히 조금 의문이다)

- 전략 5 : 방해 받지 않는 곳으로!

와.............. 대박 공감이다. 

내가 예민한데다 약간 산만해서 그런지 일할 때 만큼은 조용한 환경에서 일하는 걸 좋아한다.

나 같은 말단이 자리를 지키지 않는다는 건 눈치보이기 쉽상이지만...

노트북 들고 조용한 곳에서 생산성 있게만 작업할 수 있다면 어디든 좋을 것 같다 OTL

- 전략 6 : 꼭 필요한 인물이 되십시오

조엘님의 경우, 옛날에 말단 프로그래머로 어떤 회사에서 일할 때 회사가 조엘 테스트 2점이었다고 한다.

그래서 업무 환경을 고쳐야 되겠다고 작정을 했다고 한다. (헉...)

하지만 같이 일 하는 사람들에게 좋은 인상을 심어주는 일이 무엇보다 중요하다는 점도

알고 있었기에 매일 하루 7시간은 무조건 코드를 짰다고 한다. 

(무수한 체크인 만큼 다른 팀원에게 좋은 인상을 주는 방법은 없기 때문!!

-> 내가 전에 인턴했을 때는 일을 엄청 하면서도 체크인을 잘 안해서 ㅄ 될 뻔한 적도 있음)

하지만 매일 퇴근 전 1시간은 업무 환경 개선에 힘을 쏟았다고 한다.

이 시간 동안 일일 빌드, 버그 DB 설치, 명세서 작성, 업무와 관련된 문서 작성 등등.

그렇게 노력하니까 조금씩 나아졌다고 한다.

실제로 이게 가능한가....? 싶기도 하지만.. 만약에 어떤 말단이 이런 짓(?)을 한다면

이 사람은 꼭 필요한 사람이라고 느낄 거라고 확신한다. 생각이 있는 관리자라면.

조엘님은 책임자가 아니라도 변환를 일으킬 수 있다고 해주시면서

그렇지 못하면 적을 만들게 된다고 한다.

내게 있어서 전략 1, 5, 6 만큼은 뭔가 와닿는 것이 있었다. 특히 1, 6.

그 외 4부, 5부도 있지만 내가 다룰 만한 내용은 없는 것 같으니 생략하겠다.

이번 책은 다른 책에 비해 조금 두꺼웠다. 한 500 페이지 가까이 되니... ㅠ_ㅠ

아직 독서 습관이 안 잡힌 나로서는 솔직히 부담스러웠다. 그래서 읽는 것조차 힘들었고.

당분간 개발자를 위한 서적은 쉴 생각. 너무 개발자 서적만 읽었더니 오히려 스트레스 받는 것 같다.

독서 습관 들이려다 지치고 싶지는 않으니 다른 책들도 읽어 봐야 겠다.

원래 이 책 읽고나서 More Joel on software 도 읽으려고 했는데... 좀 쉬었다가 읽어야겠다.

확실히 배울 점이 많은 책이었다는 건 분명하지만 왠지 지쳐버렸다 ㅠ_ㅠ.. (리뷰를 써서 그런가?)

아무튼 휴식이 필요해

---

실용주의 프로그래머

저자

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

출판사

인사이트 | 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

다음엔 조엘 시리즈 ㄱㄱ ~

---

이펙티브 프로그래밍

저자

제프 앳우드 지음

출판사

위키북스 | 2013-03-29 출간

카테고리

컴퓨터/IT

책소개

코딩 호러 블로그의 운영자이자 스택 오버플로우 공동 창업자가 알...

---

ㅋㅋㅋㅋㅋ 동시다발적으로(?) 책 리뷰를 쓰게됐다.

한가한 백수이다보니ㅡ_ㅡ 책을 읽을 수 있는 시간이 많다.

지난 번에 리뷰한 '코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기'에 이어

이 책을 읽었다. 원래 이게 먼저 나온 책이던가 그런데 뭐 아무렴 어때.

...하지만 조금 겹치는 내용들이 있긴 있었다. 

덕분에 후루루룩!! 하고 읽었다ㅋ 책을 너무 대충읽었나 싶은 생각도 든다.

저자님이 조엘 스폴스키님이랑 같이 stackoverflow 를 공동 창업하시다 보니

두 책 모두 조엘님 이야기가 엄청 나온다 ㅋㅋㅋㅋ 

그래서 다음엔 조엘님이 쓰신 책을 읽어보려고 한다. 

책을 읽으면 읽을수록 읽어야할(?) 책 리스트가 많아진다_-_ 

사실 책을 읽어야만 한다는 압박과 부담이 책읽기를 힘들게 하지만...

왜 나는 스스로에게 부담스러운 압박을 하는지 ㅋㅋㅋㅋㅋㅋㅋ 나 좀 이상한듯.

이래서 조급한 성격이 문제인듯.

또 잡소리가 길어지니 리뷰로 넘어가겠다.

무려 12개의 장으로 나뉘는데 늘 그랬듯이 하나씩 훑어보겠다.

1. 들어가며

- 프로그래머의 8 단계

(1) 죽은 프로그래머 : 최고 단계. 자신이 작성한 코드가 자신이 죽은 뒤에도 사용된다.

ex - 다익스트라, 도널드 커누스, 앨런 케이

(2) 성공적인 프로그래머 : 자신의 코드를 이용해 비지니스 혹은 산업을 창조한 프로그래머.

ex - 빌 게이츠, 존 카맥, DHH

(3) 유명한 프로그래머 : 프로그래머 집단에서 잘 알려진 존재.

(4) 일하는 프로그래머 : 개발자로서 성공적인 경력을 보유해 새로운 직장을 구하는 데 어려움이 없음.

(5) 평균적인 프로그래머 : 자신이 위대한 개발자가 아니라는 건 알지만 충분히 좋은 실력을 갖추고 있음.

(6) 아마추어 프로그래머 : 코딩을 좋아하는 사람들.

(7) 알려지지 않은 프로그래머 : 대부분 대기업에서 근무하며 유능하긴 하지만 별 특징이 없는 사람들.

(8) 나쁜 프로그래머 : 기술이나 능력이 없는 상태에서 프로그래머로 종사하는 사람들.

책에 더 자세히 나와있지만 이정도만 정리하겠다.

나는 지금 어디에 속하고 어떤 프로그래머가 되고 싶은지 생각해 볼 수 있었다.

개인적으로 나는...음.. 5~6 정도에 속하지 않을까 싶다. (아마도)

그리고 죽기 전에는 1~3 중에 하나는 이루고 싶다 ㅋ 

1, 2 둘 중 하나만 이뤄도 3 은 자동적으로 이뤄질 것 같다. 최소 3 만은 욕심내고 싶다ㅋㅋㅋㅋㅋ

- 쓰지 않으면서 쓰기

제프 엣우드님의 글에서 항상 하는 이야기. 글을 써야 한다 ! ! ! !

특히 개발자들의 특징 중 하나가 코드만 작성하다보면 의사 소통 능력이_-_ 음...(...)

이렇게 되는 경우가 많아서 

저자님과 조엘님이 ~ 어떻게 해서든 이 작자들이(?) 짧은 글이든 뭐든 글을 쓰게 만들고자 ~

스택 오버플로우 사이트를 제작하게 되었다고 한다ㅋ

뭐 어쨌든 저는 그 말씀에 공감하며 지금도 글을 쓰고 있습니다ㅎㅎㅎ

2. 엉터리 같은 일을 마무리하는 기술

- 톱날 갈기

어떤 능력을 향상시키는 최선의 방법은 최대한 반복해서 연습하는 것.

기술을 연마하는 것과 기술을 활용하는 방식에 대해 사색하는 것 사이에서 균형을 잡을 필요가 있다.

저자님께서 추천해주신 프로그래밍과 관련된 좋은 링크들을 모아놓은 웹 사이트

(1) 해커 뉴스 : 완전 강추라고 적혀있다. 폴 그레이엄의 정신이 낳은 자식이라고 한다.

( https://news.ycombinator.com/news )

(2) 프로그래밍 레딧 : 어수선하지만 프로그래머들에게 관심을 불러일으킬 만한 사이트가 매우 많다고 한다.

( http://www.reddit.com/r/programming )

둘 다 링크 걸기위해 들어가봤는데... 일단 영어 잘 하시는 분만 들어가시길 권장ㅋ

해커 뉴스는 심플하고 아기자기한 반면에 레딧은 진짜 정신없다 ㅋㅋㅋㅋㅋㅋㅋㅋ

앳우드님께서 추천해주셨지만 난 아직 둘다 볼 만한 레벨은 아닌 것 같다 흑 ㅠ_ㅠ

- 멀티태스킹이라는 미신

간단히 말하자면... 사람이 멀티태스킹 하면 점점 바보된다.

동시에 여러 일을 할 수 있다고 스스로를 과대평가하지만 냉철해져야 할 필요가 있다는 말씀.

3. 좋은 프로그래밍의 원리

- 프로그래밍의 첫 번째 원리 : 그것은 언제나 당신의 잘못이다

나를 포함해서 많은 사람들이 비판이 아닌 '비난'을 잘한다 ㅋㅋㅋㅋ

여기서 '실용주의 프로그래머'라는 책의 'select는 망가지지 않았다'에 대한 이야기를 실었는데

재밌기도 하고 소제목가 말하고 싶은 바를 잘 보여주는 에피소드라고 생각한다.

솔직히 (설령 제대로 확인을 했더라도) 막상 상황에 부딪히면 본능적으로 자기방어 심리에 

내 잘못이 아니라고 자신을 변호하면서 다른 쪽으로 책임을 전가하는 경향이 있다고 생각한다.

이 글을 보면서 그런 마인드를 잘 컨트롤할 수 있을지 조금 걱정이 되지만 

저렇게 하는 쪽이 옳다고 공감하는 만큼 노력 해야되겠다.

- 주석 없이 코딩하기

대체로 다른 사람이 내 코드를 잘 이해할 수 있도록 주석을 잘 달아놓으라는 얘기를 듣지만

왜곡되서 이해할 때도 있다. 그 결과로 의도치않게 왠지 쓸데없는 주석까지 blah blah 달고 있는 나를 보게 된다.

코드만으로도 충분히 이해할 수 있도록 작성하는 게 BEST 지만

어쩔 수 없는 경우에는 정말 똑부러지게 핵심만 찌르는 주석을 신중하게 달아야한다.

전에도 저자님께서 강조하듯이 '최선의 코드는 아무 코드도 없는 것이다'라고 하신 말씀에 귀결된다고 생각한다.

- 성능은 기능이다

빠른 웹 사이트를 만들기 위해 다음과 같은 Tool들을 이용할 수 있다고 한다.

(1)야후! YSlow    (2) 구글 페이지 스피드    (3) 핑돔 툴즈(Pingdom Tools)

그리고 지금은 잘 이해가 되지 않지만 필요한 내용이라고 생각되는 것을 소개해주셨다.

그게 바로 'CDN(Content Delivery Network) : 콘텐츠 전달 네트워크' 이다.

응답 속도 향상을 위해 욕심 부리거나 아키텍처를 새로 설계하는 노력을 기울이는 것 보다는 !

정적인 콘텐츠를 우선적으로 분산시키는 것이 현명하다고 한다. 

이를 위해 CDN를 사용하는 것이 용이하다고 하지만 이를 활용하는 것은 가급적 뒤로 미루라고 하신다.

이것보다는 아래의 방법들을 먼저 실천하자. 참고로 CDN 도 포함되어있다.

야후!가 발표한 웹 사이트를 빠르게 하는 13가지 간단한 방법

( 본문 : https://developer.yahoo.com/performance/rules.html )

( 정리 및 번역 : http://geothink.tistory.com/entry/빠른-웹-사이트를-위한-13가지-기본-룰-1 )

잡설이지만 티스토리도 네이버 블로그처럼 좀 깔끔하게 링크 주소를 갖고 올 수 있도록 해줬으면 좋겠다ㅡ_ㅡ+

그리고 익명의 사용자와 로그인한 사용자, 모두를 위해 디자인하고 최적화하자.

어쩌다 한 번씩 방문하는 익명의 사용자와 매일 방문하는 사용자들가 내려받는 데이터의 양이 다르다고 한다.

(구글 크롬의 네트워크 패널 자료를 보면 로그인한 사용자가 더 많은 데이터를 전달 받는다)

전자는 기본 기능만 탑재한 최소한의 코드로 빠른 속도를 체험할 수 있게, 

후자는 커뮤니티 활성을 위해 노력하시는 분들 이므로 코드를 추가해 더 많은 기능을 사용할 수 있게.

4. 프로그래머를 제대로 채용하는 법

음....... 나는 지금 채용을 당하는 입장으로서 이 장을 읽으면서 기분이 조금 오묘했다. 크흑.

- 프로그래머를 채용하는 법

저자님에 따르면 온라인에서 코딩 검증을 대행하는 서비스가 있다고 한다.

인터뷰 젠 : http://www.interviewzen.com/

코딜리티 : https://codility.com/

... 이런 거 처음본다. 소개해주신 저자님께 감사드린다.

이 외에 전화 인터뷰를 위한 문제들도 소개되어있다.

(1) 바로 코딩하는 질문 : 배열 안에 있는 정수 값 중에서 가장 큰 값을 찾아라

(2) 간단한 설계 질문 : HTML을 모델링하기 위한 표현 방식을 설계해보라.

(3) script 작성과 정규 표현식 : directory 내에서 특정 형식의 전화번호가 저장된 텍스트 파일 목록 만들기.

또는 HTML 페이지에서 전화번호 추출하기.

(4) 자료구조 : 어떤 경우에 배열 대신 해쉬 테이블을 사용할 것인가?

(5) 비트와 바이트 : 프로그래머에게 10월 31일(Oct 31)과 12월 25일(Dec 25)이 같은지 묻는 게 왜 우스운가?

그 외에 다른 질문들도 많이 소개 되어있다. (너무 많으니 여기에 다 적지는 않는다)

제프 앳우드 님이 추천하는 방법 중에 하나는 자기 분야에 대한 PPT를 20분 가량하는 것이라고 한다.

글쎄... 내가 봤을 때 저 방법은 아마 경력직을 대상으로 하는 이야기 아닐까 싶다.

솔직히 신입은 자기 분야라고 말할 수 있는 정도의 수준이 되는 애가 얼마나 될까 싶기 때문이다.

5. 팀이 함께 일하도록 만들기

- 뱀파이어 프로그래머 VS. 베어울프 시스템 관리자

비유가 재밌어서 여기에 남겨본다.

프로그래머는 종종 밤에 깨어있고, 죽음보다 창백한 얼굴을 가지고 있으며,

일반적으로 햇빛에 노출되는 것을 싫어한다. 그리고 자신의 코드가 영원히 죽지 않을 거라고 생각하는 경향이 있다.

마지막에는 동의하기 힘들지만 뭐 뱀파이어 같다는 비유가 재밌다.

반면에 시스템 관리자는 겉으로 보기에 평범하지만 믿을 수 없을 정도로 힘이 세고,

보통 사람들을 쉽게 죽일 만한 일들 앞에서는 멀쩡하다. 그리고 '사건'이 터지는 달밤에

몸에서 기묘한 변화를 겪는다고 한다.

서로 다른 종류의 괴물이지만 VS. 가 아닌 AND 가 되어야한다는 이야기.

- 회의 : 일이 죽으러 가는 장소

이것도 비유가 재밌다 ㅋㅋㅋㅋ

저자 님께서는 회의에 대해 다음과 같은 원칙을 가지고 있다고 한다.

(1) 회의가 한 시간이 넘기면 사형    (2) 모든 회의에는 명확하게 정의된 목표 설정

(3) 회의 참석 전에 회의에서 필요한 일하기    (4) 회의 참석을 선택사항으로 만들기

(5) 회의를 마무리할 때 해야 할 일 정리하기

음... 꽤 공감이 된다.

6. 당신의 박쥐 동굴 : 프로그래머를 위한 효율적인 작업 공간

- 프로그래머 권리 장전

(1) 모든 프로그래머는 2 대의 모니터를 가져야 한다

(2) 모든 프로그래머는 빠른 PC를 가져야 한다

(3) 모든 프로그래머는 마우스와 키보드를 자기가 원하는 것으로 선택할 권리가 있다

(4) 모든 프로그래머는 편안한 의자를 가져야 한다

(5) 모든 프로그래머는 인터넷에 연결할 수 있어야 한다

(6) 모든 프로그래머는 조용한 작업 환경을 가져야 한다

음....... 내가 봤을 때 2 를 제외하고는 왠만하면 보장되는 것 같다. (아니라고 외치는 사람도 있겠지만)

ㅋㅋㅋㅋ 가끔씩 생각나는 건 내가 인턴으로 일하기 시작했을 때 

도난 우려라는 이유로 진짜 후진 노트북를 받아서 일했던 적이 생각난다.

- 기타 좋은 의자 추천과 배경 조명에 관한 글이 궁금하다면 이 책을 읽어보시길.

특히 배경 조명의 중요성을 일깨워주는 글이 신선했다.

(배경 조명은 간접 조명과 조명을 완화하는 방법이 하나로 결합된 방식, 모니터 뒤에 불빛을 둬라!)

7. 사용자를 염두에 두고 설계하기

- 애플리케이션은 결국, 작은 디테일의 모음이다

저자님은 2마리의 고양이를 키우고 계신다. (꺄)

이 글은 고양이 자동 급식기의 구식과 신식을 소개하면서 비교하는 글이 쭉 적혀있다.

그리고 결론은 핵심 기능이 어느 정도 제대로 구현이 되있고, 고객의 피드백을 통해 디테일을 개선하고자 한다면

디테일 구현하려는 첫 시도에서 실패하는 것을 두려워 할 필요가 없다는 것이다.

- UI를 우선시하는 소프트웨어 개발

'종이 위의 프로토타입 : 사용자 인터페이스를 빠르고 쉽게 디자인하기'

(Paper Prototyping : The Fast and Easy way to Design and Refine User Interfaces)

위 책은 종이 위에 프로토타입을 그려보는 방법을 다룬 탁월한 입문서라고 한다.

- 버전 1은 엉망이야, 하지만 어쨌든 출시하라고

난 이 소제목을 보면서 이 무슨 멍멍이 같은 소리인가 하고 반감을 샀지만...

중요한 건 소프트웨어가 얼마나 완벽한 것인가가 아니라, 

소프트웨어를 출시한 다음에 당신이 어떻게 하느냐 라고 한다. 

나의 경우에는 일을 일단 끝맺으면 다시 되돌아보지 않는 경향이 커서 조금 심각한 문제가 아닌가 싶기도 하다.

그래서 일을 끝맺기 바로 직전까지 무척 완성도에 집착하고 매달리게 된다.

아마 내가 팀장이 된다면 팀원들에게 엄청 채찍질 하는 건 않을까 하는, 두려운 상상을 하게 된다.

그러니 귀차니즘을 떨쳐내고 반복적인 개선이 자연스러운 일이라는 것을 받아들이도록 침착해져야 겠다.

8. 보안의 기초 : 사용자의 데이터를 보호하라

- 웹 트래픽 전체를 암호화해야 하는가?

이 글을 읽으면서 HTTP 와 HTTPS 에 대해 고찰해볼 수 있었다.

그래서 간단히 검색해보니 자세한 설명이 나와있는 글을 찾았다. 한글이니 편히 읽을 수 있다.

( http://opentutorials.org/course/228/4894 )

- 사전(Dictionary) 공격 기초, 빠른 해싱, 웹 비밀번호를 둘러싼 불편한 진실

이 책에서 가장 재밌는 부분들이 아닐까 한다.

보안 수업을 흥미롭게 들은 나로서는 정독할 수 있는 글이었고,

읽다보면 당연하고 쉬운 글들이라고 생각할 수 있겠지만 그래도 읽을 가치는 충분하다고 생각한다.

8장의 글 전부가 재밌다. 보안에 관심있는 초보 개발자라면 꼭 읽어보시길.

고커 네트워크 까는 글이 우...웃겼다. 비번 저장, DES 암호화에서 어처구니 빵터짐 ㅋㅋㅋㅋ

9. 코드를 테스트해서 그것이 필요 이상으로 엉망이 되지 않게 만들기

- 단위(Unit) 테스트 VS. 베타(Beta) 테스트

윌 쉬플리라는 베테랑 프로그래머는 단위 테스트를 너무나도 혐오하신다.

사람이 직접 테스트 하는 것을 극단적일 정도로 강조하시는데 음... 저자님의 의견에 따르면

기본적인 단위 테스트가 베타 테스팅을 보완할 수 있다고는 생각하지만 윌님의 의견에 동의한다고 한다.

그 말은 즉.... 단위 테스트가 불필요한 건 아니지만 베타 테스트에 더 무게를 실으신다는 말씀이라 생각한다.

- 크래쉬보다 더 나쁜 것은 무엇인가?

이 글을 보면서 나는 '원래 버그가 발생하고 한참 지난 다음에 애플리케이션이 크래쉬한다' 라는 글을

읽는 순간 숨이 멎는 줄 알았다 ㅋㅋㅋㅋㅋㅋㅋㅋ 진짜 상상도 하기 싫다 ㅋㅋㅋㅋㅋ 끔찍해 으아ㅏㅏㅏㅏ

저런 경우 뭐가 문제인지 찾기도 힘들고 그러다보면 멘붕 상태에 이르기때문에 ㅡ_ㅡ....

진짜 저것만큼 최악인 것도 없다고 생각했다. 하지만 이 글의 결론과는 달랐다.

핵심은 '사용자의 데이터를 절대, 반드시, 무슨 일이 있어도 손실해서는 안 된다. 보호해야만 한다' 였다. 

내가 너무 개발자 입장에서만 생각했다는 게 확 느껴진다 ㅋㅋㅋㅋㅋ 흐엉 반성하자 ㅠ_ㅠ

10. 커뮤니티를 만들고, 관리하고, 커뮤니티로부터 이익 얻기

- 이 장을 읽은 덕분에 'Stack Exchange, Stack Overflow 무슨 차이일까?' 라는 포스팅을 하게 되었다.

- 정지, 금지 혹은 완전금지?

커뮤니티를 보면 꼭 썩은 사과같은 존재가 있기 마련이다. 그러니 이 녀석들을 없애기 위해서는 !

~ 누군가를 몰래 정지시키는 3가지 방식 ~

(1) 완전 금지 : 커뮤니티에 참여할 수 있지만 다른 모두 사람들에게 노출되지 않으므로

아무도 그들에게 응답하지않는다. '트롤에게 먹이를 주지말라' 원칙이 적용된 방식.

(2) 느린 금지 : 웹 사이트 반응 속도를 느리게 함으로서 참여의 감소를 유도함.

(3) 에러 금지 : 방문하는 페이지의 무작위한 장소에 에러가 뜨는 것을 경험한다. 

드루팔 미저리(Drupal Misery) 모듈 같은 곳에 실제로 구현되어 있다고도 한다.

ㅋㅋㅋㅋ 읽어보기만 해도 레알 끔찍한 형벌이라고 느끼는데 나만 그런건가?

11. 마케팅 사기꾼들, 그리고 어떻게 그런 사람이 되지 않을 수 있는가

- 인터넷 광고에서 하지 말아야 할 일

이 글에서는 문명이라는 게임의 브라우저 판인 에보니(Evony) 라는 게임의 인터넷 광고 변천 과정을 볼 수 있다.

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

웃음 밖에 안 나온다. 이런 식의 광고는 실제로도 정말 많이 봤다. 써글. 욕 나올 뻔했다.

저자님이 비꼬는 말이 기억에 남는다 ㅋㅋㅋㅋ

'에보니, 인터넷 광고가 도달할 수 있는 맨 밑바닥이 어떤 것인지 보여준 것에 대해 고마움을 전한다'

12. 우선순위를 제대로 관리하기

- 행복을 구매하기

이 글의 내용은 

마치 내가 최근에 리뷰한 '59초 - 순식간에 원하는 결과를 끌어내는 결정적 행동의 비밀 -' 라는 책의

요약본과도 같은 글이었다.

- 빠르게 살고, 일찍 죽고, 지친 육신을 남기고

닷컴 거품의 과도했던 측면을 잘 포착해서 그려낸 다큐멘터리 영화가 2개 있다고 한다.

(1) Startup.com : 웹 1.0 회사들의 초기 모습을 그려낸 작품

(2) Code rush : 98~99년 사이에 넷스케이프에서 촬영된 작품

넷스케이프... 훌륭한 회사지만 MS의 IE 끼워팔기로 인해 몰락해버린... 

씁쓸하고 동정을 금치 못하는 회사라는 것은 이미 알고 있다.

책에 의하면 그들은 다음과 같이 의미있는 유산을 남겼다고 한다.

# 넷스케이프 네비케이터 를 통해 HTML과 인터넷 자체를 널리 퍼뜨렸다.

# 98.03.31 에 넷스케이프 소스코드를 공개함으로서 상상하기 어려웠던 상업용 오픈소스 운동의 씨앗을 뿌렸다.

# 04년도에 모질라 파이어폭스 1.0 이라는 브라우저를 통해 IE에게 처음으로 실제적인 위협을 가하기도 했다.

회사는 이미 사라지고 없지만 수많은 전설적인 해커들은 그곳에서 시작해 퐌타스틱한 경험을 쌓아갔다.

저자님께서는 이들의 운명과 같은 길을 걷고 싶지 않다면 신중히 생각하라고 조언해주셨다.

그런 회사들의 삶은 빠르게 살고, 일찍 죽고, 그리하여 지친 육신을 남기는 것이었다. 라고 덧붙이셨고.

'왜 그토록 오랜 시간 동안 열심히 일을 하는지'

---

59초(순식간에 원하는 결과를 끌어내는 결정적 행동의 비밀)

저자

리처드 와이즈먼 지음

출판사

웅진지식하우스. | 2009-09-25 출간

카테고리

경제/경영

책소개

원하는 목표를 실현하는 데 필요한 시간 59초! 상대를 내편으로...

---

'코딩호러가 들려주는 진짜 소프트웨어 개발 이야기'  책의 저자님께서

유일하게 추천하는 자기계발 서적이라 읽어 봤다.

교보문고 자료 보니 09년도 출간되서 베스트도서로 추천받은 책이라고 한다.

뭐 어쨌든 요즘 너무 개발자 위주 서적만 보는 것 같아서

방향을 조금 바꿔봤다.

저자인 리처드 와이즈먼은 심리학자이고 책도 여러권 내서 꽤 유명세를 탄 듯한 분이다.

300쪽 조금 넘는 책에 10장으로 구성되어 있다. 

은근 두꺼워서 솔직히 읽기도 전에 조금 부담 ㅡ_ㅡ....

제프 엣우드가 이 도서를 추천한 이유는

자기 잘난 듯이 이래저래 충고하는, 쓰레기같은 자기계발서가 아닌

여러 실험 과정을 통해서 과학적으로 쓰였다는 이유로 추천했다.

그래서인지 줄곧 내용이 실험에 대한 설명과 결과, 그리고 결론.

이렇게 구성되어 있다. 

그런데 여기서 약간 고민을 했었어야 하는게.....

대부분 미국인들을 대상으로 실험을 했을테니 

한국인으로서 조금 결론에 대해서 공감하기 어려웠던 것도 있고, 

아니면 이 책의 원서가 쓰였을 당시에는 신선했을 결론일지도 모르나 

내가 지금 읽을 시점에서는 너무나도 당연한 이야기 아닌가 싶은 내용들이 많았다.

......그래서 좀 이 책은 대충 읽었다. 게다가..

이책말고도 다른 책들도 읽어야 될 게 많은지라 (코딩 호러의 이펙티브 프로그래밍, Head First Design Pattern) 

조금 조급한 마음에 빨리 헤치워버리자라는 마음이 나도 모르게 나왔다 보다.

그래도 리뷰는 남기고 싶으니 간단하게라도 적겠다.

1장. 내편 만들기 : 면접, 협상, 부탁에 관한 상식 밖의 실험

- 이 장에서 가장 기억에 남는 건 뒷담화에 대한 이야기.

보통 나의 경우 사람의 뒷담화를 잘 하는 편인데...

일단 나는 뒷담화가 무조건 나쁘다고 생각하지 않는다.

뒷담화 만큼 사람을 친밀한 관계로 만들어 주는 요소는 많다고 생각하지 않으니까 ㅡ_ㅡ.....

근데 여기서 다른 사람에 대해 하는 이야기는 모두 자신에게 되돌아온다(혹은 전이된다)라는

이야기를 듣고 조금 오싹했다 ㅋㅋㅋㅋㅋㅋㅋㅋ 

보통 부정적인 이야기를 많이 하는 편이라 타인도 헐뜯은 사람 뿐만 아니라

나도 부정적으로 본다는 생각에 께름칙한 마음이 확 피어났다..

이제는 자리에 없는 누군가의 이야기를 할 때... 긍정적인 이야기만 하는 게 좋겠다.

누구나 그렇겠지만 다른 사람이 나를 부정적으로 본다는 것만큼은 피하고 싶으니까.

- 최소한의 호의, 최대의 효과

나는 워낙 힘든 유년시절(?)을 보내왔기 때문에 남에게 베푸는 것에는 짠 편이다.

베풀어 주고 싶어도 베풀 능력이 안 되기에... 짜다.

근데 이게 만성이 되다보니 돈이 있어도 쓰고 싶다는 마음만 있지 

행동으로는 꽤나 절제한다. 좋게보면 절약이겠지만 남에게 베푸는 것에 짜다는 건

절약과는 전혀 다른 얘기라는 걸 인정하기에... 조금 반성하게 됐다.

지금은 누군가에게 물질적으로 베푸는 건 힘들지 몰라도.. 적어도 마음만으로도

충분히 베푸는 게 가능함에도 불구하고 못 본체 하지는 말자는 생각을 하게 됐다.

2장. 목표 달성의 요술램프 : 소원을 말해도 이루어지지 않을 때

- 장밋빛 미래의 함정, 이중 사고 활용하기

이 책의 특징이 잘 나타나는 장.

기존의 우리가 자주 듣고 익숙해져버린 고정 관념? 에 대해서 의심을 품어

실제로 실험에 보고 그건 사실과 다르고, 실제로는 이렇다! 라는 전개.

그저 장밋빛 미래만을 보지 말고!

그 미래가 무엇이고 그것을 달성하기 위해 어떤 세부 목표가 필요한지

구체적으로 정리해서 실현해 나가는 게 짱이다..............

조금더 추가하자면

환상+현실 모두 생각하는 이중 사고 기법을 활용하는 사람이 성공할 확률이 높다고 한다.

목표 달성이 가져다줄 혜택(환상) + 도중에 마주칠지도 모르는 문제에 대한 현실적 평가(현실)

이 균형을 잘 잡는 게 중요하다는 점.

너무나 당연한 이야기다. 하지만 난 알면서도 이를 실천하지 않는다.

왜 그럴까. 뻔뻔하지만 난 그 이유도 안다 ㅋ

귀찮으니까 + 어떤 목표를 설정해야 될지 잘 모르겠다, 확신이 없다 + 어물어물 + 우유부단? + 은근 겁많음

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 진짜 짜증난다 나한테 ㅋㅋ

- 미적거림, 차이가르니크 효과

'시작이 반이다'....................

이 말에 격하게 공감한다. 난 한번 시작하면 끝을 봐야 되는 인간인데

문제는 시작조차 하는 걸 굉장히 부담스러워한다...........ㅠ_ㅠ

3장. 창조성은 어디에서 오는가 : 브레인스토밍의 신화 탈출하기

- 브레인스토밍... 다수의 사람들이 머리를 맞댄다고 해서 그게 무조건 좋을까?

에 대한 의심으로 시작한다 ㅋㅋㅋ 결과는 당연히 아니다.

오히려 사람이 많기에 시간과 행동을 위한 에너지 투자에 대해 동기부여를 반감시키고,

기존의 틀 안에서 사고하는 경향이 더 강해진다고 한다.

하지만 그렇다고 해서 '혼자 조용히 생각하는 게 낫다'라고 말하는 건 아니라는 점.

- 딴 생각이 아이디어를 만든다

해결해야 하는 어떤 문제가 있다면 우선 그 문제에 대해 확실히 인식을 한 다음,

그 생각을 잠시 접고 다른 일에 집중을 한다. 

(예를 들어 십자말 풀이, 스도쿠 풀이 등 짧은 시간에 집중할 수 있는 다른 일)

이렇게 다른 일에 집중하는 동안에 내 무의식은 앞에 인식했던 문제에 대한 해결을 위해 일하게(?) 된다고 한다.

다른 일에 집중하는 시간이 끝나고나서 다시 실제 문제에 대한 해결책을 생각하는 게

좀더 혁신적인 사고를 할 수 있다는 결과였다.

기존의 우리는 오히려 스트레스 받는 문제가 있으면 마음을 편안히 비우고

생각하는 게 좋다고 생각하는 경향이 있다. 

하지만 이것과 다르게 딴 생각...하는 방법도 있다는 이야기.

타인이 딴 생각한다고 화내지말자.

- 창조성을 자극하는 환경 만들기

초록색 환경(식물, 컬러 등), 현대 미술 작품 걸어놓기, 새 얼굴 효과 등

○○○○○    ▲▲▲▲▲

○○○●○    ▲▲▲▲▲

○○○○○    ▲△▲▲▲

4장. 유혹의 기술 : 매력적인 사람들은 무엇이 다를까

- 뭔가... 이 장을 읽으면 진짜 웃기다.

무슨....연애의 비법 전수(?) 이런 듯한 내용이라 ㅋㅋㅋㅋㅋ 

유치한 느낌에 딱히 리뷰남길 것도 없다고 생각된다.

5장. 안티-스트레스 라이프 : 분노와 불안을 잠재우는 특별한 방법

- 불쾌한 경험의 긍정적인 측면 생각하기

...나는 긍정이라는 단어와 좀 거리가 먼 편이지만 가까워지고 싶어 한다.

그래서 책에 적혀있는 내용을 조금 가져오겠다. 긍정이 이런 거구나 라는 느낌을 받기 위해 ㅋ

그 사건을 통해서 나는...

* 그동안 알지 못했던 나의 강한 면을 알게되었다 or 내 삶에 대해 모르고 있던 측면을 알게 되었다.

* 더 현명해지거나 어떤 사람과 관계가 더 좋아졌다.

* 감정을 전달하는 데 더 능숙해졌거나, 자신감이 더 생겼거나, 나쁜 관계를 청산할 수 있었다.

* 동정심과 이해심이 더 많아졌다.

* 해를 가한 사람과 관계가 오히려 더 좋아졌다.

이런 식으로 솔직하게 적어나가면 분노와 불안을 잠재우는 데 효과적이라고 한다.

- 반려동물

실험 결과들을 보아하니 확실히 불안을 없애는 데 효과적인 동물은 '개'다.

(심지어 반려자보다 효과가 있다고 한다ㅡ_ㅡㅋ)

고양이는 나쁜 기분을 완화시키는 데 도움이 되지만 기분을 아주 좋게 해주지는 못한다고 한다.

하지만 고양이를 기르는 입장으로서는 동의 못 한다 ㅋㅋㅋㅋㅋㅋ

난 고양이의 귀욤귀욤귀요미 매력에 빠진 덕분에

고양이랑 같이 편안히 있을 때마다 엔돌핀이 아주 팡팡 돈다. 움쪽쪽.

6장. 화성남자와 금성여자의 지구 생활 : 재앙을 막는 관계 유지의 비결

- 부부 관계에 대한 이야기이니 PASS -

7장. 솔로몬의 선택 : 후회 없는 결정을 위한 교훈

- 일단 발 들여놓기, 무리한 요청 먼저하기, 특이한 부탁으로 상대방 얼떨떨하게 만들기,

덤으로 하나 더 등의 방법이 영업사원들이 많이 사용한다고는 한다고 하지만 ㅋㅋㅋ

실생활에서도 많이 써 먹을 수 있는 방법이긴하다. 

실제로 나는 특이한 부탁으로 혼을 빼놓거나 Deal(?)을 하거나 아니면

최후의 수단으로 배째라는 식으로 떼를 쓴다거나 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

하는 방법을 쓰긴 하지만... 일단 나는 누구에게 부탁하는 걸 안 좋아하기 때문에 ㅡ_ㅡ..ㅋ

- 아까 딴 생각이 아이디어를 만든다고 했는데 어떤 결정을 내릴 때에도

이 방법이 가능하다고 한다. 결정해야 할 문제를 생각한 뒤 다른 일(스도쿠 풀이 등)을 하고 난뒤에

결정을 내린 선택이 나중에 후회하는 경우가 보통 결정을 내리는 과정보다 적다고 한다.

딴 생각의 힘인가. (정확하게는 무의식)

- 후회하면 스트레스만 받으니... 후회를 아예 하지 말거나 후회할 짓을 미리 방지하자.

ㅋㅋㅋㅋ 솔직히 이것도 다 아는 건데 실천이 힘들지 않나?

8장. 똑똑한 아이 만들기 : 내 아이를 위한 교육의 기술

- 아이가 없으니 PASS : 이름잘짓기, 능력보다는 노력에 대한 칭찬, 자제력 길러주기 등 -

9장. 당신은 내 손 안에 있다 : 종잡을 수 없는 상대방을 간파하는 법

- 제일 재밌게 읽었던 장이다.

- OCEAN 성격 진단법

개방성, 신중함, 외향성, 동조성, 신경증

개방성 :

상상력과 창의력이 뛰어나지만 금방 싫증을 느끼기 쉽고 항상 새로운 생각과 경험을 추구하는 경향이 있다.

반대인 사람은 현실적이고 기존의 개념을 실현할 수 있는 상황을 추구하며 과감한 변화보다는 단계적인 변화를

원하고 잘 확립된 관행과 규칙을 따르려는 경향이 있다.

신중함 :

조직적이고 의무에 충실하다. 모든 것이 있어야 할 자리가 정해져 있고, 모든 것이 제자리에 있는,

잘 조직되고 예측 가능한 환경에서 최고의 능력을 발휘한다.

반대인 사람은 느긋하고 인생을 즐기면서 살려고 하지만 자제력이 있어야 하는 상황에서는 다른 사람의 도움이

필요할지도 모른다.

외향성 :

다른 사람과 함께 있을 때 힘이 나고, 밤이 되면 생기가 넘치며, 채찍보다는 당근을 써야 더 열심히 하는 스타일.

반대인 사람은 조용한 환경에서 혼자 일하길 좋아하며, 오전에 집중력이 높고, 당근보다는 채찍을 써야

더 열심히 하는 스타일.

동조성 :

신뢰성이 높고 우호적이며 협조적이지만, 남들이 그런 성격을 이용할 수도 있으니 조심해야 한다.

반대인 사람은 공격적이고 경쟁 의식이 강하며 강인한 사고와 직설적인 화법이 필요한 상황에서 능력을 발휘한다.

신경증 :

불안과 고민에 빠지기 쉬우며, 부정적인 감정을 삭이는 데 시간이 오래 걸리기 때문에 

가능하면 기분 나쁜 상황을 피하려고 한다. 

반대인 사람은 느긋하고 감정에 덜 치우치며, 웬만한 일에는 고민하지 않는다. 

다른 사람들이 스트레스를 심하게 받는 상황에서도 잘 견딘다.

- 2D:4D (집게손가락:약손가락)

두번째 < 네번째 손가락이면, 위 비율이 1보다 작다.

두번째 > 네번째 손가락이면, 위 비율이 1보다 크다.

보통 남자는 1보다 작고 여자는 1에 가깝다.

나는... 양손 다 네번째 손가락이 더 길다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

책에 따르면 그런 여자는 적극적이고 모험을 두려워하지 않는 경향이 있다는 연구가 있다고 한다.

위로가 되는 건 1보다 큰 값을 갖고 있는 사람이

더 무거운 무게를 들어올리고, 더 빨리 달리고, 유명 축구선수들, 우수한 공간 정보 처리, 뛰어난 음악적 재능을

갖고 있는 경우가 많다고 한다. 비과학적인 직관이겠지만... 그래도 연구 결과, 통계적으로 그렇게 나온다는 거.

- 그 밖에

(1) 애완 동물의 성격은 주인의 성격이 투영된 것이라는 사실이 드러났다고 한다.

(2) 차에 범퍼 스티커를 많이 붙힌 사람을 조심해라. 공격적인 운전을 할 가능성이 높다.

(3) 깍지 껴서 오른손 엄지가 위에 있으면 좌뇌가 우세하고 (좋은 언어능력,분석적)

왼손 엄지가 위에 있으면 우뇌가 우세하다. (시각적, 창의력, 직관적)

10장. 행복 연습 : 완전한 삶에 관한 놀라운 진실

- 장기적인 행복감을 위해 '표현적 글쓰기'를 해라.

내용은 감사 표시, 멋진 순간, 환상적인 미래, 사랑하는 사람, 현실 되돌아보기 등등.

이 책도 그렇고 코딩 호러 책도 그렇고 모두 공통적으로 강조한 말은 '글쓰기를 해라'다.

난 글을 써본 적이 많지 않아서 정말 글짓기 젬병 이지만... 

이렇게 쓰다보면 확실히 글쓰기 능력이 향상된다는 것을 느낀다.

그게 연필로 썼던 간에, 블로그로 썼던 간에 생각을 이렇게 정리한다는 건

나한테 긍정적인 효과를 많이 보여준다고 느낀다.

- 돈으로 행복사기

* 물건 대신에 경험을 사라. 예를 들면 외식, 콘서트, 영화, 연극, 여행, 댄스 배우기, 야외 활동 등.

* take 보다는 give.

대충 읽기는 했지만 그래도 읽을 건 다 읽은 듯.

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

난 분명히 위에 적었다시피 간단하게 적을 생각이었는데 

책을 이리저리 뒤적거리다 보니 꽤 남기고 싶은 내용이 많았나 보다ㅋㅋ

그런데 쓰다가 깨달았는데 여기서는 반드시 직접 실험해보거나 다른 사람이 실험했던 내용을

인용한 이야기가 대부분이다. 하지만 잘 읽어보니 표본이 적다고 생각되는 실험들도 간간이 눈에 띈다.

그런 것을 보면 왠지 신뢰성이 떨어지긴 해도ㅋ 목차만 보고 관심이 생기거나 

읽다보니 흥미롭게 느껴지는 글들이 있어서 재밌었다. 잘 읽었다.

자기 계발서라 그런지 스스로 반성하는 시간도 갖게 되었고~

(글 중간에 갑자기 자학하는 글도 쓰는 걸로 보아선 ㅋㅋㅋ)

가끔씩 읽는 것도 나쁘진 않은 것 같다. 당연한 이야기들이 많긴 하지만 

실제로 행하지 않는 내 모습을 되돌아 볼 수 있게 되니까 시간낭비까지는 아닌듯ㅎ

---

코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기

저자

제프 앳우드 지음

출판사

위키북스 | 2013-11-28 출간

카테고리

컴퓨터/IT

책소개

코딩 호러 블로그 운영자이자 스택 오버플로우의 공동 창업자가 들...

---

임백준 님이 번역하신 또 다른 책 ! ㅎㅎㅎㅎ

저자이신 제프 앳우드 님은 프로그래머 사이에 유명한 블로그인 '코딩 호러'를 운영하시는 분이시다. 

그리고 코딩하면서 구글링을 했다면 누구나 알 법한 stackoverflow.com 을 창립해 사이트를 구축하신 분. 

오랫동안 닷넷 프로그래머로 일하셨고 지금은 루비 쪽에 관심이 있으신 것 같다.

'읽기 좋은 코드가 좋은 코드다' 라는 책에선 코드로 설명을 많이 하는 반면

이 책은 정말 - 이야기 - 가 많다.

그래서 조금......... 지루했다. 읽는 것도 꽤 걸렸다. 

물론 다 피가 되고 살이 되는 이야기 겠지만.............. 

지루하기도 하고 지겹기도 해서 어떤 글들은 대충 읽기도 했다.

제프 앳우드 님의 블로그에서 좋은 글들을 선별해 엮은 책이라 확실히 블로그 스러운 느낌의 글들이 많다.

절대로 그 분의 글솜씨를 폄하할 생각은 없지만 (물론 역자님 탓을 하고 싶지도 않다)

약간 앞뒤 말이 안 맞는 부분도 있었고, 문장이 길어서 이해하기 힘든 부분도 있었다.

내용 자체가 어려웠던 부분도 있었다.

짧게 결론을 내리면...............

'읽기 좋은 코드가 좋은 코드가' 라는 책보다 확실히 재미없었다 ㅡ_ㅡ...

나중에 좀 더 레벨업 된 개발자가 됐을 때 다시 읽어 보든가 해야겠다. 

- 내가 이해력이 딸려서 그런 것일 수도 있으니 -

포스팅 시작부터 이렇게 부정적인 얘기만 blah blah 하니까

아무도 안 읽을 것 같다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

하지만 !!! 물론 읽을 만한 글들도 있다. 정말로 지루하기만 했다면 리뷰 글따위 쓸까 보냐.

처음부터 하나씩 훑으면서 자세한 리뷰를 남기겠다.

Part 1. 쓸데없는 일을 줄이는 법

아까 위에서 앞뒤 말이 안 맞는 부분이 있었다고 했는데

바로 이 파트에 그런 글들이 있었다.

'쓸데없는 일 하지 않기' 라는 글에서 할일 목록 따위를 만들어서

스스로를 강박주의자로 만들지 말라는 글이 있었다. 

심지어 굉장히 진지하게 할일 목록을 전부 내다 버리라고 글을 쓰셨다.

정말로 중요한 일이 있다면 우리의 뇌가 그걸 잊어버릴 일은 없다고.

그런데 

'우리 프로젝트는 언제나 90퍼센트 가 완료돼 있을 뿐이다.' 라는 글에서는 조금 다르다.

이 글에서는 목록이 없으면 스케줄도 없다고 하며

프로젝트가 90% 완료에만 머무는 슬럼프를 넘기 위해서는

개발자들에게 자기가 해야 할 일을 모두 자세하게 나열해보도록 권장하는 글이 있었다.

둘다 쓸데없는 일을 줄이는 방법이긴 하지만 전혀 다른 방법이다...

물론 내가 이해 못 한 부분이 있기야 하겠으나 이런 모순된 글을 보면서

앞뒤가 안 맞는 부분이 있다고 생각했다.

'열정이 있는데 재능이 무슨 필요람?'

- 이 컬럼은 앞에 무슨 얘기인지 잘 이해가 안 됐지만 마지막 글귀가 가슴에 와닿았다.

'당신보다 재능이 있는 수천명의 개발자가 있다고 해서 기죽지 말라. 

당신에게 열정이 있는데 재능이 무슨 필요가 있단 말인가?'

솔직히 낭만주의에 젖은 듯한 말 같지만 그래도 공감이 전혀 안되는 건 아니다.

열정이 있고, 열정이 있다는 걸 확실히 표출하는 게 중요하다고 생각한다.

뭐 어찌됐든 이 파트에서 가장 기억에 남는 글은 '보이드의 반복법칙' 이라는 글이다.

상당히 흥미로운 글이었다.

소프트웨어 개발에서 사용되는 반복적인 방법(iterative)과 재귀적인 방법(recursive)의

사이에 존재하는 차이를 설명하기 위해 선택한 비유가 있었다.

그 비유로서 한 공군 대령이 제트 전투기와 관련된 연구 이야기를 하는데 꽤 재밌는 이야기였다.

이 글에서 말하고 싶은 바는 보이드의 반복법칙 그대로였다.

반복의 속도가 반복의 질보다 우선한다.

상당히 인상 깊은 글이었다. 굳.

Part 2. 프로그래밍

'깨진 유리창 이론'

- 깨진 유리창을 고치지 않은 채로 방치하지 말라.

일단 창문이 깨지기 시작하면 깔끔하고 기능적으로 잘 동작하던 시스템이 

순간적으로 엉망이 되어버리는 모습을 보아왔다. 그러니 최대한 빨리 고쳐야 하고

제대로 고칠 시간이 충분하지 않다면 일단 나무 판자라도 대서 때우기라도 하면서

더 이상 훼손되지 않도록 조치를 취해 그 문제를 인식하고 처리중이라는 사실을 드러내라.

위의 글은 실용주의 프로그래머에서 설명된 글 일부를 정리해서 쓴 것이다.

저런 경험이 있는 지는 잘 모르겠지만 왠지 모르게 공감이 가서 여기에 대충 적어봤다.

'궁극의 코드 카타'

- 카타 : 미리 정해진 동작을 반복해서 훈련하는 것을 의미. 무술에서 사용하는 단어.

프로그래밍을 잘 하기 위해선 어떻게 해야 되는지 방법들이 적혀있다.

참고할 수 있을 만한 사이트가 주석으로 달려있다.

http://www.codekata.com/

http://www.codingdogo.org/

'프로그래밍에서는 1이 가장 외로운 숫자다', '당신의 코딩 친구는 누구인가?'

- 음........ 위 글들은 페어 프로그래밍(Pair Programming) 이라는 키워드는 없었지만 

이 키워드를 강조하는 글들이었다. 

나한테 코딩 친구가 있는지 생각해보니까 아직은 없는 것 같다. 흐음.

아직까지 우리나라에서는 페어로 일하는 문화는 거의 없지 않나 싶다.(개발자들 사이에서)

오히려 서로 터치해봤자 트러블이 있을 수 있으니 각자 독립적으로 일하는 분위기랄까.

"쿨하지 못해 미안해. 그러니 각자 할 일 하자." 이런 느낌? 유감스럽다.

'소프트웨어 도제살이'

- 소프트웨어 개발에서 견습생/고참/장인 이라는 관계를 키워나가야 될 필요성을 말하는 글.

확실히 그런 건 있는 것 같다. 

'내가 하면 오늘 안으로 다 할 것을, 일부러 후배에게 일임하면서 경험을 쌓도록 도와주는 것'

쉬운 일은 아니다. 왜냐면 멘토 입장에서 후배하는 거 보면 복장이 터질 정도로 답답할 수 있으니까.

그럼에도 불구하고 훌륭한 후배들을 양산해 내기 위해 노력하시는 개발자 분들을 보면

정말 존경스럽다. 나도 그런 분들을 닮고 싶다.

Part 3. 웹 디자인

솔직히 개발자를 위한 책에서 이 파트가 다뤄졌다는 점이 신기하다.

게다가 글도 꽤 많은 양을 차지하고 있는 파트다. 우왕 의외다.

'앱이 웹사이트를 죽일 것인가?'

- 이 글에서의 결론을 정리하자면

웹사이트가 앱에게 죽지 않으려면 멍청한 웹사이트가 되어선 안 된다.

- 앱이 웹사이트 보다 나은 이유

(1) 더 빠를 수 있다.

(2) 단순한 Native UI Control 을 사용한다.

(3) 앱은 스크롤 공간을 더 효율적으로 사용한다.

(4) 온오프라인 상관없이 잘 동작한다.

- 웹사이트가 앱보다 나은 이유

(1) 브라우저만 있으면 어떤 장치에서도 사용할 수 있다.

(2) 설치할 필요가 없다.

(3) 업데이트 될 필요가 없다.

(4) 웹사이트는 보편적인 UI 경험을 제공할 수 있다.

'값싸고 손쉬운 사용성'

- 소프트웨어 프로젝트의 사용성과 관련해서 입문자를 위한 쉬운 책

'스티브 크룩의 사용성 평가, 이렇게 하라!'

'사용성 VS. 학습용이성'

- 조엘 스폴스키의 책 '프로그래머를 위한 사용자 인터페이스 디자인' 中

학습 용이성에 관심을 가져야 하는 경우 : 관광지 여행객과 같이 아주 가끔 방문하는 사용자

사용성에 관심을 가져야 하는 경우 : 전문적인 작가를 위한 워드프로세서

'구글의 가장 큰 UI 실수'

- 구글 메인의 I'm Feeling Lucky 버튼에 대해 엄청 까는 글인데 재밌다. ㅋㅋㅋ

Part 4. 테스트

- 유닛테스트(Unit Test) 를 한번 해보고 싶다는 생각은 하지만 아직도 실천되지 않는....ㅠ_ㅠ

- '예외 로그는 고객의 피드백이 가질 수 있는 최고의 형태다' 라고 하셨는데 맞는 얘기다. 공감 빵빵.

Part 5. 당신의 사용자를 알라

- 꽤 많은 양의 글을 담고 있지만 기억에 남는 글은 별로 없었다.

'묻지 말고 관찰하라'

- 이 글을 보면 초창기 구글.co.kr 의 화면 이미지가 있는데 정말 화가 난다. 지저분해서 ㅡ_ㅡ

지금은 모르겠는데 당시 한국 사람들은 고급 제품으로부터 복잡성을 기대한다는 이야기를 보고 놀랐다.

말도 안돼. 나도 한국 사람이지만 이해가 안 된다. 리얼리? ㅋㅋㅋ

- 그 밖에는 아마존의 상품 추천 기술 도입에 대한 실험 정신을 볼 수 있는 에피소드가 재밌었다.

Part 6. 우리가 관심을 둬야 할 것들

'인터넷... 그리고 그 밖의 모든 것들을 보존하기'

- 제이슨 스콧 : 2011년 인터넷 아카이브에서 공식적인 사료보관인으로 임명받음.

- 인터넷 아카이브가 하는 일 : 인터넷에서 단 한 번이라도 존재한 적이 있는 웹페이지를

당시의 모습 그대로 영구히 저장한다.

- 왜 ? : 인터넷에 올라오는 정보들은 너무나 빠르게 변하기 때문에 순식간에 모두 상실되는 것은

정상적인 현상이지만 그 결과로 우리의 문명은 기억상실증에 걸린 듯 하다. 

과거의 하이퍼링크에 대한 소스가 필요한 평범한 시민들에게 있어 꼭 필요한 일이다.

'유튜브 VS. 정당한 사용'

- 저자가 블로그에 어떤 영화의 일부 장면을 인용하고자 유튜브 동영상을 올리다가

유튜브에게 저지 당한.... (정확하게는 컨텐츠 제작자) 사연이 있는 글인데, 재밌다.

흥미롭기까지 할 정도인 유튜브의 기술..............ㅋㅋㅋㅋㅋㅋㅋ 진짜 대단하다. 짱이다.

- TED 강연 : How youtube thinks about copyright

http://www.ted.com/talks/margaret_stewart_how_youtube_thinks_about_copyright

꼭 봐야지 라고 생각하는 것들 중 하나가 되어버렸다. 대ㅋ박ㅋ

Part 7. 게이밍

- 아타리와 비쥬얼 베이직부터 시작해 게임 분석에 관한 이야기, 

게임 플레이어에서 게임 개발자로까지의 이야기가 있지만............ 

왠지 세대차이도 조금 느껴지고 당연한 이야기인 것 같아서 조금 실망.

Part 8. 읽어볼 만한 내용

'프로그래머는 책을 읽지 않지만 당신은 읽어야 한다'

- 저자가 추천해주신 책 목록

1. Code Complete 2

2. Don't Make Me Think (상식이 통하는 웹사이트가 성공한다)

3. Peopleware

4. Pragmatic Programmer (실용주의 프로그래머)

5. Facts and Fallacies of Software Engineering (소프트웨어 공학의 사실과 오해)

'아무도 당신을 돕지 않을 것이다. 그리고 그 점이 바로 멋진 부분이다'

- 시중에 나온 자기계발서의 95%는 완전히 쓰레기다............. 라고 하셨다.

ㅋㅋㅋㅋㅋㅋㅋ 왠지 책을 많이 안 읽어서 다행이다 라고 한심한 생각을 하게 된다 ㅋㅋㅋㅋㅋㅋ

- 유일하게 추천하는 자기계발서 '59초: 순식간에 원하는 결과를 끌어내는 결정적 행동의 비밀'

영문책이라 한글판으로 있는 지는 모르겠다. 원제는 '59 Seconds: Think a little, Change a lot'.

추천하는 이유는 과학적 연구결과를 찾아 인용하면서 설득하기 때문이라고 한다. 믿을만 하다는 것이다.

음........... 앞에 부정적인 말들을 많이 한 것 치고는 정리해보니

그래도 잘 읽은 책인 것 같다 ㅋㅋㅋ 나도 참 줏대없는 인간인듯ㅋ

원래 이 책이 나오기 전에 

'코딩 호러의 이펙티브 프로그래밍' 이라는 책이 먼저 나왔는데 그거 먼저 읽을 것 그랬다.

역자의 말에 의하면 그 책보다는 이 책이 좀 더 개발자에게 재밌을 거라고ㅋ

ㅇㅏ ~~~~~

다음엔 뭘 읽어볼까.

---

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

저자

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

출판사

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

카테고리

컴퓨터/IT

책소개

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3부. 코드 재작성하기

4부. 선택된 주제들

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

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

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

(1) 이름에 정보담기

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

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

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

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

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

내용이 기억에 남는다. 

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

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

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

주석으로 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 빼고는 다 처음 본다..ㅋㅋㅋㅋㅋㅋㅋ

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

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

다 피가 되고 살이 된다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(3) 변수와 가독성

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

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

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

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

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

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

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

어쨌든 아래 코드는 이해하기 힘들지만 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 페이지가 안 되는 책이라 접근성(?)이 뛰어나다고 할 수 있다 ㅋㅋㅋ

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

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