개발자 필독서로 검색했을 때 가장 먼저 눈에 띄었던 책이다.
읽고나서 든 생각은 과연 개발자 필독서로 평가를 받을만 하다는 것.
사실 개발 지식이 거의 전무한 상태라 1장, 2장의 프로그래머들은 다 알만한 이야기지만 문외한들에겐 외계어인 내용들을 읽으면서 ‘아 역시 나한테는 무리인가?’ 하고 생각을 했지만, 그 이후로는 문외한이 보기에도 괜찮았다. 중간중간 이해못하는것들은 걍 패스
나중에 다시 보기 위해서 조금 정리
3장
조엘 테스트
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업환경에서 일하고 있습니까?
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?
11점은 우수한 성적이지만, 10점 이하는 심각한 문제가 있다고 한다.
우리 회사는 2점 덜덜덜(1번과 5번)
7번 관련 : ‘명세 없이는 코드도 없다’
8번 관련 : 지식노동은 몰입이 필요한데, 몰입까지 걸리는 시간은 평균 15분 정도. 그러나 대게는 몰입이 깨지기 쉬운 환경에 놓여있다.
프로그래머를 1분이라도 방해하면, 실제로 15분에 이르는 생산성을 날려먹는 것이다.
영희는 일하던 중 갑자기 strcpy 함수의 유니코드 버전 이름이 생각나지 않았다. 30초만 찾으면 알아낼 수 있었겠지만 철수에게 물어보면 15초면 답을 구할 수 있을거라는 걸 잘 알고 있고 마침 그런 철수가 바로 옆에 앉아있으니, 영희는 어렵지 않게 철수에게 물어본다. 철수는 업무흐름이 끊기고 방해를 받아 생산성 측면에서 15분을 잃어버린다. 물론 영희는 15초를 번다.
위에 인용된 사례는 명백하게 내가 맨날 저지르던 일이라 엄청 인상적이었다. 그래서 이 글을 읽은 이후 몰입 중인 동료를 방해하지 않으려고 자제하려고 노력 중이다. (그럼에도 불구하고 아직도 동료를 인터럽트하고 있음 ㅠㅠ)
10번 관련 : 프로그래머 2~3인 마다 전문 테스터가 1명씩 붙어있지 않다면, 시간당 3만원짜리 테스터가 수행할 작업을 시간당 10만원짜리 프로그래머가 수행하도록 돈을 낭비하고 있는것이다.
6장 손쉬운 기능명세 작성법 2강 명세가 뭡니까?
명세는 1명이 전담해서 작성해야만 한다.
큰 제품일 경우, 여러 부문으로 쪼갠 다음에 각각을 개인에게 할당해서 독자적으로 명세하게 한다.
회피목표: 팀 단위로 제품을 만들 때, 각자 좋아하는 상큼한 기능을 넣으려는 경향이 있다. 그러나 이 모든 기능을 허용한다면, 시간과 돈이 무지 투여된다. 따라서 불필요한 기능을 버려야하는데, 이때 가장 좋은 방법은 명세에 ‘회피목표’ 항목을 추가하는 것이다. “이건 절대 안 할 겁니다!” 논쟁을 일으킬 순 있으나 최대한 빨리 도마에 올린다는 측면에서 중요하다.
7장 손쉬운 기능명세 작성법 3강 하지만 어떻게?
MS에는 ‘프로그램 관리자’가 있다.
프로그램 관리자가 요구사항을 수집하고, 코드의 예상 동작을 이해해서 명세서를 작성한다.
프로그램 관리자는 사용자 인터페이스를 연구하고, 고객을 만나고, 명세서를 쓰는게 일이다.
프로그램 관리자당 5명 정도의 프로그래머를 붙인다.
프로그램 관리자는 큰그림을 염두에 두고 프로그래머는 정확하게 올바른 코드 조각에 집중해야한다.
코드 개발자를 프로그램 관리자로 승급시키지 말라. 일 잘하는 프로그래머의 능력을 보상해주겠다고 컴퓨터언어가 아니라 사람 말로 통해야 하는 직책으로 무턱대고 승진시켜주는 것은 전형적인 피터의 원리를 따르는 예이다.
마케팅 부서 사람을 프로그램 관리자로 승급시키지 말라
프로그래머가 프로그램 관리자에게 보고하는 체제가 되어서는 안된다.
8.손쉬운 기능명세 작성법 4강 팁.
규칙1. 재밋게 쓰자
규칙2. 사람이 이해하기 쉽도록 쓰자
사용자 x가 ANSI 문자열로 나타내는 해당 사용자를 대표하는 RFC-822 순응 이메일 주소로 사상하기 위해 정의한 AddressOf(x)를 가정하자. 사용자 A와 B가 있을 때, A가 사용자 B에게 이메일을 보내기를 원한다고 가정하자. 사용자 A는 다른 곳에 선언돼있는 기술 일부(전부는 아니다)을 활용해서 새로운 메시지를 시작하고, To:편집창에 AddressOf(B)를 입력한다.이와 같은 명세는 다음과 같이 표현 할 수도 있다.뚱뚱양은 점심을 먹으러 가려고, 새로운 이메일 창을 열고 “To:” 상자에 커밋 주소를 입력한다.기술노트: 주소는 반드시 표준 인터넷 주소(RFC-822 순응)를 따라야 한다.
프로그래머는 ‘올바른’ 명세를 ‘기술적으로’ 올바르게 써야 한다고 생각하며, 그 결과 함정에 빠진다.
규칙3. 최대한 단순하게 작성하자
사람들은 쓰다use가 프로답지 못하다고 생각하는지 활용하다 utilize와 같은 단어를 선호한다.
글자로 도배하는 방식은 피하자
규칙4. 여러 차례에 걸쳐 검토하고 다시 읽자
규칙5. 표준양식은 해롭다고 간주한다.
10장 일일빌드는 당신의 친구 입니다.
팀이 모두 같은 시간대에 일한다면, 점심 시간에 빌드를 하는 게 딱 좋습니다. 이런 방법으로 모든 사람이 점심 먹기 전에 최신 코드를 올바르게 체크인합니다. 식사 시간 동안에 빌드가 돌아가고, 식사를 끝내고 돌아왔을 때 빌드가 깨져 있다면 모든 사람이 이를 수정할 수 있습니다. 빌드를 빨리 만들수록 빌드가 깨지지 않았을까 하는 걱정 없이 최신 버전을 체크아웃할 수 있습니다.
11장 고리타분한 버그 수정
버그 수정은, 수정한 버그 가치가 수정 비용을 넘어설 때만 그 의미가 있습니다.
1. 찾아낸 버그를 모두 확인하십시오
2. 경제적인 피드백을 확인하십시오
3. 버그를 모두 수정하는 작업이 어떤 값어치가 잇는지 계산기를 두드려 보십시오
13장 종이 프로토타이핑
종이 프로토타이핑에 대한 좀 더 자세한 설명이 필요하시다면 카롤린 스니더가 집필한 책을 읽으시기 바랍니다.(Carolyn Snyder, Paper Prototyping; ‘The Fast and Easy Way to Design and Refine user Interfaces'(Morgan Kaufmann, 2003)
20장 인터뷰를 위한 게릴라 가이드
인터뷰 후 지원자에 대한 결단은 칼같아야한다. 합격 아니면 불합격. “합격이지만, 우리 팀은 말고”는 절대 안된다.
모든 망설임은 불합격으로 간주해야 안전하다.
“글쎄 잘 모르겠는데”라고도 절대 말하지 말라. 잘 모르겠으면 불합격이다.
“음..합격은 시키겠지만, 좀 걱정스러운 구석이 있는데…”라는 생각도 절대 안된다.
기준에 미달하는 지원자를 채용하는 실수보다는 훌륭한 지원자를 놓치는 실수를 저지르는 편이 차라리 낫다.
…아 이 챕터를 읽으면서 정말 과거에 얼마나 바보같이 사람을 뽑았는지 매우!!! 반성했다.
21장 성과급은 오히려 해가 된다.
어떤 평가든 사기에 미치는 영향은 매한가지이다. 부정적인 평가는 사기를 확 떨어뜨리는 반면, 긍정적인 평가는 사기나 생산성에 아무런 영향을 미치지 못한다. 높은 평가점수를 받은 사람은 이미 일을 잘 하고 있는 사람이다. 그런 사람에게 좋은 점수를 준다면, 자신이 높은 점수를 받으려고 열심히 일했던 건지 헷갈리게 만들 뿐이다. 품질에 자긍심을 갖고 열심히 하는 전문가가 아니라 보상을 바라고 움직이는 파블로프 개처럼 느끼게 된다.
대부분은(사실여부를 막론하고) 자신이 일을 잘 하고 있다고 생각한다. 따라서 잘한다는 평가는 당연히 들어야할 소리라서, 대부분은 평가 결과에 실망하게 된다.
업무성과 평가, 성과급, 멍청하기 그지없는 이달의 직원 프로그램 등 어떤 종류도 피하기를 권한다.
23장 개발자는 멀티태스킹 기계가 아닙니다
개발자가 결코 한번에 일을 두 가지 이상 진행하게 방치해서는 안된다.
24장 결코 하지 말아야 하는 일 제1부
프로그래머가 항상 코드를 버리고 새로 시작하기를 원하는 이유가 있다. 예전 코드가 엉망진창이라는 생각 때문이다.
새로운 코드가 예전 코드보다 좋다는 생각은 매우 불합리하다. 예전 코드는 한번 사용해봤던 것이고, 테스트도 마친것이다. 버그도 많이 찾아내 수정도 한것이다.
코드가 엉망진창인것 처럼 보이는 이유는 버그 수정의 결과이다.
코드를 버리고 새로 시작하면, 여기에 속한 노하우도 모두 버려야 한다.
출시가능한 코드를 확보하고 있어야 한다.
25장 드러난 빙산의 비밀
인터페이스 작업은 실제로는 1% 미만을 차지할 따름이다.
프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘못 만들어진 화면을 보여주면, 사람들은 전체 프로그램의 90%가 잘못됐다고 생각한다.
프로그래머가 아닌 사람에게 아름다운 사용자 인터페이스로 100% 무장한 화면을 보여주면, 프로그램이 거의 다 끝났다고 생각할 것이다.
전시할 때는 화면이 유일한 고려 사항이다. 100% 아름답게 만들기 바란다.
28장 측정
누군가 지식 노동자의 효율을 측정하려 들면 모든 질서가 급격히 붕괴돼버리는, 로버트 D.오스틴이 측정 역기능 measurement dysfunction 이라 일컬은 현상에 직면하게 된다. 관리자는 측정시스템을 구현하기를 좋아하며, 이런 측정시스템에 기반해서 효율에 대해 보상하려고 한다. 하지만 100% 통제가 이뤄지지 않으면, 직원은 작업에 대한 실제 가치나 품질과는 전혀 무관하게 ‘측정 대상 행위’에만 몰두해 보상을 챙긴다.
34장 세상에 쉬운 일은 없습니다.
구현에 앞서 설계를 해야 한다.
35 NIH 신드롬을 옹호하며
NIH = Not Invented Here 자신이 직접 개발하지 않은 기술에 대해 베타적인 성향을 보이는 행태
무슨 일이 있어도, 핵심 비즈니스 기능은 아웃소싱하지 말고 직접 수행하라.
37 전략메모 II : 닭이 먼저냐, 달걀이 먼저냐
플랫폼과 소프트웨어는 닭 닭걀 문제가 항시 존재
PC-DOS가 성공한 것은 MS가 마케팅 능력을 앞세워 운영체제 시장을 휩쓸었기 때문이 아니다. 그 당시 MS는 아주 작은 회사였다.
PC-DOS가 성공할 수 있었던 이유는 처음부터 소프트웨어가 있었기 때문이다. PC가 나오기 전 유일한 운영체제 였던 CP/M 소프트웨어를 거의 그대로 돌릴 수 있었기 때문이다.
닭이냐 달걀이냐 문제를 해결하는 방법은 어떻게 하건 역 호환성을 지원하는 것이다.
38장 전략메모 III : 나 다시 돌아갈래
사용자가 제품을 바꾸게 하는 유일한 전략은 걸림돌 제거이다.
41장
백업하자