조엘 온 소프트웨어(joel on software) 2부

2부

개발자 다루기

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

 

a.이력서를 받는다.

실수가 많은 이력서는 버린다.

b. 입학기준이 높은 대학을 졸업했다는건 좋은 신호, 채용이 까다롭다고 이름난 회사에 다녔다면 주목할만하다.

c. 다음 일단 전화를 해서.  프로그래밍 문제 하나로 한 30분정도 이야기를 나눠봅니다.

d. 인터뷰시 면접관은 6명정도, 꼭 함께할 동료들로 채워야 한다.

e. 6명중 2명이라도 지원자를 별로라고 여긴다면, 그 사람은 고용하지 마십시오.

f. 인터뷰를 마치면 지원자에 대한 결단은 칼같이 내려야 합니다. 이결정에는 답이 두가지 뿐입니다. 합격 아니면 불합격.

"함격이지만, 우리팀은 말고", "우리팀에서 일할 만큼 똑똑하지는 않지만, 바보같은 저쪽 팀에서 일할 정도는 되는군", => 불합격

"글쎄 잘 모르겠는데" => 불합격

모든 망설임은 불함격

 

기준에 미달하는 지원자를 채용하는 실수보다는 훌륭한 지원자를 놓치는 실수를 저지르는 편이 차라리 낫기 때문입니다.

 

좋은 지원자를 판단하는 원리

1. 똑똑하다.

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

 

인터뷰시 똑똑이는 대화가 자연스럽게 흘러갑니다. 지원자가 영리함을 드러낼수 있는 환경을 만들어 주는 일이 중요합니다.

 

면접관중 가장 최악은 "떠버리" 시종일관 떠들다고 상대에게 "예 맞습니다." 라고 말할 시간밖에 안준다.

다음 퀴즈쑈 면접관, 잡다한 지식을 많이 알아야 똑똑하다고 생각하는 사람

 

소프트웨어 팀은 특정 기술이 아니라 자질이 있는 사람을 고용해야 합니다.

 

  해야할 질문

1. 첫인사

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

하나, 열정이 보입니까?

부정적인 열정도 좋은 징조 입니다.

굉장히 긴장한 지원자는 이야기 도중에 이의를 제기하면( 그럴듯한 말을 하고 있을때 "그럴리가 없는데.. "하고 넌지시 말해봅시다), 불과 5분전까지만 해도 바짝 긴장해 있던 사람이 자신의 논지를 적극적으로 옹호하려 들겁니다.

둘. 훌륭한 지원자는 상대 수준에 맞쳐 설명할수 있습니다.

셋. 팀 프로젝트였다면 리더십을 발휘했을 것 같습니까?

3. 답변 불가능한 질문

문제해결능력

4. 프로그래밍 문제

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

2. 연결 리스트를 역순으로 만들기

3 한 바이트에서 1인 비트세기

4. 이진 검색

5. 문자여레서 '연속적으로문자가 반복된느 길이가 가장 긴 부분 문자열 찾기

6. atoi,

7, itoa( stack이나 strrev를 써야 하기 때문에 좋은 문제임)

 

5. 만족합니까?

코드를 만족합니까?

좋습니다. 버그가 어디에있죠?

실수를 찾아 낼수 있는 능력이 있어야 한다.

 

6, 질문 있습니까?

 

 

21장. 성과급은 오히려 해가 된다.

TBD

 

22장. 테스터를 두지 않는(잘못된)이유 5가지

프로그래머 2명당 1명의 테스터가 최소한 필요

프로그래머는 각자 만든 빌드를 자주 던져주면서 테스터와 밀접하게 일해야 한다.

 

1. 버그는 프로그래머가 게을러서 생기니까요.

NO. 버그는 프로그래머 자신의 코드에서 버그를 발견해내지 못하는 바람에 생기는것이다.

대개 버그는 다른사람이 발견해 내기 쉽다.

2. 우리 소프트웨어는 웹에 올려놓아서, 버그는 금방고칠수 있으니까요.

3. 고객이 소프트웨어를 테스트 해줄 테니까요.

4. 우수한 테스터는 테스터로 일하려고 하지 않거든요.

. 테스팅 직을 기술지원 직보다 한 단계 높은 직급으로 정하십시오. 테스팅이 지겹기는 하지만, 성난 사용자를 전화로 상대하기보다는 낫습니다.

. 프로그래밍 강의수강을 지원하는등 자기 경력 개발을 도우십시오.

.최우수 테스터는 쉽게 잃을 수 있다는 사실을 인정하십시오.

. 구태의연하지 않은 테스터를 찾으십시오.

. 임시직을 고용하십시오.

. 프로그래머는 유능한 테스터가 되지 못한다.

5. 테스너를 고용할 돈이 없으니깐요.

 프로그래머 1명을 교체하는 비용으로 테스너 세명 연봉에 구인 비용까지 충당할수 있다.

 

 

23장. 개발자는 멀티태스킹 기계가 아닙니다.

 

직렬 처리

계산 A                     계산 B

1 2 3 4 5 6 7 8 9 10     11 12 13 14 15 16 17 18 19 20

 

멀티테스킹

1 11 2 12 3  13 4 14 5 15 6 16 7 17 8 18 9 19 10 20

 

결과 20초

A : 멀티 태스킹경우 결과값이 19초나 걸린다.

다시말해 계산당 평균처리시간은 멀티태스킹보다 질력처리 방식이 더 좋다.

여기에 멀티테스킹은 과업전환시 시간이 전혀 안든다는 가정에서 행한 수치입니다.

실제 과업전환시 들어가는 시간을 추가하면 훨씬 오래 걸리게 된다.

 

1. 직렬처리 방식은 평균적으로 결과값이 더 빨리 나온다.

2. 과업전환이 오래 걸릴수록, 멀티태스킹을 위해 지불해야 하는 대가도 커진다.

 

프로그래밍은 과업전환에 많은 시간이 든다.

 

 

24장. 결코 하지 말아야 할는 일, 제1부

  코드 쓰는 작업보다 읽는 작업이 더 어렵다.

이런 법칙은 왜 그렇게 코드 재사용이 어려운지를 설명합니다.

코드가 엉망인 이유

. 버그 수정

. 아키텍트 문제 -> 리펙토링을 통해서 해결

. 코드가 비효율적일때 엉망이라고 생각한다.하지만 이문제는 프로젝트에 특정부분만 영향을 미틴다. 그부분만 다시 작업하면 된다.

. 코드는 지긋지긋ㄹ할 정도로 보기 흉할지도 모른다.

매크로를 활용해서 해결하는데 5분도 안걸린다.

 

 

25장. 드러난 빙산의 비밀

.고객은 자신이 원하는 내용이 뭔지를 모릅니다.

 

.고객이 자신이 원하는 내용이 뭔지를 알아내길 기대하지 마십시오.

당신이 해당 분야에서 알고 있는 지식을 바탕으로 독자적으로 설계하십시오. 해당 분야를 이해하는 과정에서 시간이 필요하거나, 해당 분야 전문가의 도움이 필요하다면 얼마든지 받으십시오. 하지만 결국 소프트웨어 설계는 당신 몫입니다.

 

핵심원리1

프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘못 만들어진 화면을 보여주면 사람들은 전체 프로그램의 90%가 잘못됐다고 생각합니다.

핵심윈리2

프로그래머가 아닌 사람에게 아름다운 사용자 인터펭스로 100%무장한 화면을 보여주면, 프로그램이 거의 다 끝났다고 생각할 것입니다.

핵심원리3

핵심원리4

정치적인 이유로 여러 비기술 관리자나 고객에게 프로젝트를 승인 받아야 할 경우, 그래픽 디자인 버전을 몇개 더 만들어 제공하십시오.

핵심원리5

전시할때는 화면이 유일한 고려사항입니다.100%아름답게 만들기 바랍니다.

빙산 관리

CEO

할수만 있다면 끝내지 않은 부분은 끝내지 않은 듯이 보이는 GUI를 만드세요.

일정에 대한 사람들의 인식을 제대로 통제하도록 하십시오.

 

 

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

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

.모든 추상화와 마찬가지로 무언가를 추상화하는 둣이 보이는 코드생성 도구는 구멍이 있으며, 이런 구멍을 제대로 메워주는 유일한 해결책은 추상화 동작 원리와 추상화 대상을 배우는 방법뿐입니다. 따라서 추상화는 그저 일하는 시간을 절약해 주지만, 배우는 시간을 절약해 주지는 못합니다.

. 모순적이지만 이 모든 사실은 우리가 더 나은 추상화 기법으로 더 고차원적인 프로그래밍 도구를 만들수록 능숙한 프로그래머가 되기가 점점더 어려워짐을 의미합니다.

 

 

27장. 프로그래밍 세계의 파머스톤 경.

프로그래밍 작업을 더 쉽게 만들어 준다는 추상화 작업을 마쳤더라도 위해한 프로그래머가 되기 위해 알아야만 하는 지식이 날로 늘어나고 있다는 사실을 보여줍니다.

 

소프트웨어 제작과정에서 의존할 언어 클래스, API, 플랫폼 등에 대한 몇년간의 옹골진 경험이 이쓴 아키텍트를 한 명이라도 확보하지 못했ㅎ다면 새로운 프로젝트를 시작하지 마십시오.

플랫폼 선택이 가능하다면, 가장 자신있는 플랫폼을 선택하십시오.

해당 기술이 최신 유행을 따르지 못하거나 명목상으로는 생산성이 최고로 높지 않더라도 생관없습니다.

또 추상화나 프로그래밍 도구를 설계할 경우라면, 빈틈으로 물이 새지는 않는지 좀더 심사숙고하시기 바랍니다.

 

 

28장. 측정

직원을 완벽하게 통제할수 없을때 측정 역기능이 필연적으로 발생한다는 사실을 이해하시기 바랍니다.

 

EOF