[개발관련도서] 조엘 온 소프트웨어(2/3)

2부 개발자 다루기

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

대체로 직원을 고용하는 방식

1. 이력서 - 꼼꼼하지 못한 이력서는 꼼꼼하지 못한 업무처리로 이어진다라고 생각
2. 전화 인터뷰 - 프로그래밍 문제 하나로 30분 정도 이야기를 나누는데, 같은 내용을 반복해서 설명하거나 독창적인 생각이 없는 경우 탈락시킴
3. 대면 인터뷰 - "기본적인 자질을 갖췄는가", "(재미 삼아) 토이 프로젝트를 하는가" 등의 질문을 통해 똑똑한 사람을 가려냄

이런 사람을 뽑아라

1. 똑똑하다 -> 같은 설명을 여러 번 반복할 필요가 없다면 좋은 신호
2. 업무를 성실하게 완수한다.

요즘은 어떤 기술이든 이삼 년이면 낡어버린다. 지금 당장 JDBC와 MySQL 데이터베이스를 연동할 줄 아는 사람보다는 새 기술을 배울만한 자질이 있는 사람을 고용하는 편이 낫다.

면접관이 해야 할 질문

1. 첫 인사 - 지원자를 편하게 해 주려는 목적
2. 최근 프로젝트 경력에 대한 질문
   • 살펴야할 자질
     1. 열정이 보이는가? - 인터뷰 내내 무덤덤하고 열정이 없는 지원자는 별로. 지원자가 자신이 관심 있어하는 무엇인가에 대해 이야기하는 동안 자신이 인터뷰 중이라는 사실을 잊는다면, 무엇엔가 열정적이라는 좋은 증거
     2. 훌륭한 지원자는 상대 수준에 맞춰 설명할 수 있어야 한다 - 다른 사람에게 자기 아이디어를 납득시키기 위해서 어떤 태도를 취해야 할지 깨달아야 함
     3. 팀 프로젝트였다면 리더십을 발휘했을 것 같습니까? - 업무수행 경력은 지원자가 업무를 제대로 완수할 수 있는지 판단할 수 있는 유일한 근거. 리더십을 가지고 완수한 프로젝트에 대해 물어보라
3. 답변 불가능한 문제
   • 서울에는 주유소가 몇 개나 있을까요?
   • 똑똑한 지원자는 단편적인 지식을 묻는 질문이 아니라는 것을 안다. 답변이 틀려도 좋다. 그러나 질문에 열성적으로 반응해야 한다.
4. 프로그래밍 문제
   1. 원래 저장위치에서 문자열을 역순으로 변환하기
      • 예외 없이 모든 지원자가 버퍼를 할당해서 그 버퍼에다 문자열을 역순으로 옮겼다. 문제는 누가 버퍼를 할당하고 해제하느냐이다. 또한 strlen을 몇 번이나 호출하는가? O(n)이면 충분함에도 불구하고, 루프 안에서 strlen을 계속 호출하는 바람에 O(n^2)인 strrev 함수도 본 적 있다.
   2. 연결 리스트를 역순으로 만들기
      • 조그만 그림을 그린 후 포인터를 표시하고 따라가야 한다. 그려보지 않고서는 이를 구현하는 것은 쉽지 않다. 별볼일 없는 프로그래머는 바로 구현으로 돌입한다.
   3. 한 바이트에서 1인 비트 세기
      • C비트 연산을 아는지 확인하려는 의도가 아님. 일단 한 바이트에서 비트를 세는 서브루틴을 짜게 한 다음에, 서브루틴 성능을 더 높이하고 해라.
      • 우수한 지원자와는 각 방법이 가지는 공간/속력 장단점을 논할 수 있다. 또한 뛰어난 지원자는 처음에만 비트를 센 후 참조 표에 저장하는 캐시 사용을 제안할 것이다.
      • 결국 이 문제의 목적은, 코드를 다듬고, 최적화하고, 또 개선할 방법을 찾아내는 능력이 있는지 보는 것이다.
   4. 이진 검색
   5. 문자열에서 '연속적으로 문자가 반복되는 길이 run-length'가 가장 긴 부분문자열 찾기
   6. atoi
   7. itoa(스택이나 strrev를 써야 하기 때문에 좋은 문제임)
5. 만족합니까?
   • "코드에 만족합니까?"라는 질문 혹은 "버그가 어디 있죠?"와 같은 질문을 한다.
     • 프로그래머라면 누구나 실수를 하지만, 실수를 찾아낼 수 있어야 한다.
6. 질문 있습니까?
   • 우수한 지원자는 직장을 선택할 수 있다. 인터뷰는 상대방도 여기가 일할 만한 곳인지 파악하는 시간이다.

---

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

프로그래머를 관리할 때 고려해야 할 것

• 과업 전환 시간이 엄청 오래 걸린다.
  • 최고 출력으로 코딩을 하는 프로그래머는 수천가지 사항을 한꺼번에 머릿속에 유지한다. 만일 다른 작업이 생겨서, 지금까지 하던 코딩 작업을 멈추고 아예 다른 작업에 착수한다고 해보자. 3주 동안 다른 일을 하고 돌아와 원래 하던 일을 하려면 상상 이상의 시간이 소모된다.
• 결론 == 관리자는 개발자가 한 번에 두 가지 일을 진행하게 해서는 안된다!

---

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

• 프로젝트 설계가 잘못되었다고 해서 해당 프로젝트를 갈아엎고 새로 다시 짜는 것은 위험하다.
  • 코드를 버리고 새로 시작하면, 기존의 프로젝트 속한 노하우와 버그 수정 내역도 모두 버려야 한다. 여러 해에 걸친 프로그래밍 작업이 물거품이 된다. 뿐만 아니라, 시장 지배력도 잃게 된다. 경쟁사에 2~3년이라는 선물을 주는 셈이다.

프로그래머가 작성한 코드를 완전히 엉망진창이라고 말하는 3가지 이유

1. 아키텍처 문제 - 코드가 올바르게 나누어지지 않은 경우
   • 주의 깊게 코드를 옮기고, 리팩터링 하고, 인터페이스를 변경하는 등의 방식으로 하나씩 해결할 수 있다. 점진적으로 주의 깊게 수정하면 가능하다.
2. 프로그래머가 코드가 비효율적이라고 생각하는 경우
   • 특정 부분이 느리다면, 해당 부분만 최적화 작업을 하거나 다시 작성하면 그만이다.
3. 코드가 보기 흉한 경우
   • 변수 혹은 메서드 이름이 이상할 경우 매크로를 활용하여 쉽게 고칠 수 있다.

• 작업을 새로 시작하면 처음보다 훨씬 더 나은 성과를 거두리라는 믿음을 거둬라!

---

25장 - 드러난 빙산의 비밀

빙산에 비밀에 대한 원리

• 대다수 소프트웨어는 (90%는 물속에 잠겨있는) 빙산과 동일하다. 멋진 사용자 인터페이스는 실제 프로그래밍 작업의 10%를 차지할 뿐이고, 나머지 90%의 작업은 보이지 않는 물밑에 가라앉아 있다. 그러나 프로그래머가 아닌 사람은 이런 사실을 이해하지 못한다.
• 빙산에 비밀에 대한 원리를 살펴보자

1. 첫 번째 핵심원리
   • 프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘 못 만들어진 화면을 보여주면, 사람들은 전체 프로그램의 90%가 잘못됐다고 생각한다.
   • 예를 들어, 프로젝트의 코드가 거의 100% 가까이 완료된 상태이고, 그래픽 디자이너가 색깔을 선택하고 탭을 그리는 등의 작업만이 남은 상태라고 하자. 그래서 디자인이 올 때까지, 임시로 일반 폰트와 흑백 화면을 사용한 멋지지 않은 화면(데모)을 고객에게 보여주면 그래픽적인 외형에 대해 잔소리 듣느라 시간을 다 써버릴 것이다.
2. 두 번째 핵심원리
   • 프로그래머가 아닌 사람에게 아름다운 사용자 인터페이스로 100% 무장한 화면을 보여주면, 프로그램이 거의 다 끝났다고 생각할 것이다.
   • 사용자 인터페이스를 가짜로 먼저 구현하고 나서 고객에게 이를 보여주면, 고객은 작업을 거의 다 끝났다고 생각할 것이다. 그러나 물밑작업을 하느라 6개월 혹은 1년의 시간을 더 보내면, 고객은 무슨 일이 일어나는지를 모르고 프로그래머가 아무 일도 안 하고 빈둥거린다고 생각할 것이다.
3. 세 번째 핵심원리
   • "멋지고 산뜻하게 다듬었으나 분량이 네 페이지인 웹 사이트를 운영하는 닷컴은, 3700여 년에 이르는 자료로 무미건조하게 꾸며놓았지만 실용적인 사이트보다 훨씬 더 높은 평가를 받을 것이다."
4. 네 번째 핵심원리
   • 정치적인 이유로 여러 비기술 관리자나 고객에게 프로젝트를 '승인' 받아야 할 경우, 그래픽 디자인 버전을 몇 개 더 만들어서 제공해라.
5. 다섯 번째 핵심원리
   • 전시할 때는 화면이 유일한 고려사항이다. 100% 아름답게 만들기 바란다.

• 시연을 할 경우, 끝내지 않은 부분은 끝내지 않은 듯이 보이는 GUI를 만들어라.
• 일정에 대한 사람들의 인식을 제대로 통제하라 == 프로젝트가 제대로 진행되고 있는지에 대한 궁금증을 풀어주도록 하라
  • 엑셀 형식으로 세부 일정을 만들어라.
  • 매주 32%에서 35% 완성도로 전진했으며, 12월 25일 출시일에 맞게 제 궤도에서 순항 중임을 알리는 자축성 메일을 보내라.

---

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

더 나은 추상화 기법으로 더 고차원적인 프로그래밍 도구를 만들수록 능숙한 프로그래머 되는 것이 점점 더 어려워진다.

• 허술한 추상화의 법칙은 누군가 효율성을 높여준다는 새 코드 생성도구를 내놓으면, "수작업으로 어떻게 사용하는지 배운 다음에 이 도구를 사용해서 시간을 절약하세요!"라고 충고하는 사람은 어렵지 않게 접할 수 있다는 사실을 통해 쉽게 깨달을 수 있다.
• 모든 추상화와 마찬가지로 무언가를 추상화하는 듯이 보이는 코드 생성 도구는 구멍이 있으며, 이런 구멍을 제대로 메워주는 유일한 해결책은 추상화 동작원리와 추상화 대상을 배우는 방법뿐이다. 따라서 추상화는 그저 일하는 시간을 절약해주지만, 배우는 시간을 절약해주지는 못한다.