책 리뷰 : 조엘 온 소프트웨어

---

조엘 온 소프트웨어

저자

조엘 스폴스키 지음

출판사

에이콘출판 | 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. 소스코드 관리 시스템을 사용하고 있습니까?

2. 한 번에 빌드를 만들어 낼 수 있습니까?

3. 일일 빌드를 하고 있습니까?

4. 버그 추적시스템을 운영하고 있습니까?

5. 코드를 새로 작성하기 전에 버그를 수정합니까?

6. 일정을 업데이트하고 있습니까?

7. 명세서를 작성하고 있습니까?

8. 조용한 작업 환경에서 일하고 있습니까?

9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?

10. 테스터를 별도로 두고 있습니까?

11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?

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 도 읽으려고 했는데... 좀 쉬었다가 읽어야겠다.

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

아무튼 휴식이 필요해