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

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

- 유쾨한 오프라인 블로그-

조엘 스폴스키(joel spolsky) 지음

박재호, 이해영 옮김

 

지식을 쌓기 위한 책이 아날, 생각하는 방향과 시각을 넓힐 수 있는 책이라 여기시기 바랍니다.

-옮긴이의 말 중에서-

 

목차

목차부터 정리하기는 처음이네.. 하여튼 뺄것없는 주옥같은 내용들이 즐비하다.

 

1부

비트와 바이트 : 프로그래밍 실전

1장. 언어선택

2장. 기본으로 돌아가기

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

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

5장. 손쉬운 기능 명세 작성법 1강. 명세서 작업이 귀찮습니까?

6장. 손쉬운 기능명세 작성법 2강. 명세가 뭡니까?

7장. 손쉬운 기능명세 작성법 3강. 하지만 어떻게?

8장. 손쉬운 기능명세 작성법 4강. 팁

9장. 손쉬운 소프트웨어 일정 관리법

10장. 일일 빌드는 당신의 친구입니다.

11장. 고리타분한 버그 수정

12장. 다섯 가지 세계

13장. 종이 프로토타이핑

14장. 화성인 아키텍트를 조심하세요

15장. 쏘면서 움직여라

16장 장인정신

17장. 컴퓨터과학 분야에서 떠도는 세가지 미신

18장. 더불어 살기

19장. 자동으로 충둘 보고서를 수집하세요.

 

2부

개발자 다루기

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

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

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

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

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

25장. 드러난 빙산의 비밀

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

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

28장. 측정

 

3부

조엘 따라하기 : 두서 없는 생각, 하지만 놓쳐서는 안 될 이야기

29장. 릭 채프먼이 아둔함을 찾습니다.

30장. 이 나라에서는 개가 무슨일을 하죠?

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

32장. 이야기 둘

33장. 빅맥 대 제이미는 요리사

34장. 세상에 쉬운일은 없습니다.

35장. NIH신드롬을 옹호하며

36장. 전략 메모 I : 젠 앤 제리 대 아마존

37장. 전략 메모 II : 닭이 먼저냐, 달걀이 먼저냐

38장. 전략 메모 III : 나 다시 돌아갈래!

39장. 전략 메모 IV : 블로트웨어와 80/20 미신

40장. 전략 메모 V : 오픈소스 경제학

41장. 머피의 법칙이 난무했던 한 주

42장. 마이크로소프트 사가 API전쟁에 진 이유

 

4부

.NET에 대한 쓴 소리

43장. 난관에 부딪힌 마이크로소프트 사

44장. 우리의 .NET 전략

45장. 저기 링커 좀 주시면 안될까요?

 

5부

하나 더

조엘에게 물어보기, 가장 재미있었던 질문

 

----

 

1부

비트와 바이트 : 프로그래밍 실전

 

1장. 언어선택

별내용없음. .NET 유감

 

 

2장. 기본으로 돌아가기

저는 사람들이 저지르는 가장 큰 실수 중 몇 가지느는 최저층에서 벌어지는 몇가지 단순한 동작원리를 자세히 알지 못하거나 아예 잘못 알고 있기 때문에 생긴다고 생각합니다.

 

C string에 마지막에 '\0'로 끝나는 이유

유닉스와 C프로그래밍 언어를 고안했을 무렵 사용한 PDP-7 마이크로 프로세서 때문.

PDP-7은 ASCIZ문자열 타입을 지원하는데, ASCIZ에는 끝이 영(Z)인 ASCII라는 의미가 있습니다.

 

틀림없이 선형 효율을 보여야 하는 곳에서 n제곱 효율이 나타난다면 어딘가에 숨어있을 러시아 페이트공을 의심하십시요.

- C에 문자열을 예로 알고리즘 예기를 하고 있다. -

 

조엘이 권장하는 '대학생이 갖쳐야 할 지식' 목록

1. 졸업 전에 작문법을 배운다... - 나도 배우고 싶다.. 책만으로는 동기부여가 잘되질 않는다..-

2. 졸업 전에 C를 배운다.

3. 졸업 전에 미시 경제학을 공부한다. - 뒷부분에 오픈소스 경제학을 읽으면 감동이 클꺼다.T.T-

4. 따분하다고 비 전산 과목을 등한시하지 마라.

5. 프로그래밍 심화과정을 수강하라.

6. 모든 직업이 인도로 넘어간다는 걱정은 그만둬라. - 미국 애들은 이런거 걱정하나부다. -

7. 무엇을 하든 여름 인턴과정을 거쳐라.

 

 

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

SEMA 소프트웨어 팀이 얼마나 잘 수행하고 있는지를 측정하는 매우 불가사의한 시스템

복잡한거 대신 조엘 테스트라고 작성

 

조엘 테스트

1. 소스코드 관리시스템을 사용하고 있습니까?

- 하다못해 cvs라도 사용하자. 현재 ClearCase를 사용하고 있다. 요넘 물건이다. 1점

 

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

- 당연. 1점

 

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

처음부터 깨끗한 상태에서 체크아웃을 수행한 다음에 모든 코드를 다시 컴파일하고 EXE를 만들고 최종 설치 패키지를 생성하고 CD-ROM레이아웃이나 웹사이트 다운로드 버전과 같은 최정 매체를 생성할 수 있는 단일 스크립트가 있을겁니다. 여기서 다양한 버젼과 언어 지원은 물론이고 #ifdef조합을 사용해서 EXE를 만들어 냅니다. - 요런게 일일빌드에 한 프로세스이다.. 읽으면서 잔잔하고 오랬동안 느낌을 주는 예기이다.. -

- 요건 예일수도 있고 아닐수도 있다. 각 개인이 각각 빌드를 수행해서 얻은 재품이 곧 최종 소프트웨어 이기 때문에 맞다고 예기할 수도 있지만 그렇다고 그게 최종이라고 말할 수는 없는 단계이기 때문에 아니라고 말할수도 있다. 0점

 

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

- 예.

 

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

- 예

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

- 아니오. 요거 정말 안된다. 항상 death match project다. 대한민국에서 현실적인 일정을 작성하고

업데이트하는 업체가 얼마나 될까 궁금하다.

 

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

- 아니오. 작성하고 있지만 말 그대로 문서를 위한 명세다.

 

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

- 아니오. 역자 김재호님 말처럼 군대 막사식 환경이다. 일어서면 한눈에 사무실 환경이 파악되는 전형적인 형태이다.

 

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

- 예

 

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

- 예. QE, QA모두 두고 테스트하고 있다.

 

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

-전혀. 내가 경력사원으로 들어갔을때 전혀 상관없는 내용만 물어보더라. 그리고 인사에 권한이 인사과 부장한테 있으니 이런건 거의 불가능하다고 봐야 옳지 않을까? 그래도 요즘은 각 부서에 장이 들어가서 물어본다고 하니 좀 안심은 된다.

 

12. 무작위 사용편의성 테스트를 수행하고 있습니까?

-아니오. 애석하다. 우리 회사역시 경쟁업체에 대해서 신경을 곤두 세우면서도 정작 중요한 고객에 소리에는 그렇게 귀를 기울이고 있지 않는듯 싶다.

 

각 항목을 예/아니오로 답하고 예에 1점 부여

12점 만점에 11점은 우수, 10점 이하는 심각한 문제가 있다.

실제로 대다수 소프트웨어 회사는 2점에서 3점수준, 마소는 12점 만점

- 6점이네.. 좋은편인가.. ㅎㅎ-

 

 

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

예전에 UNICODE책을 처음 접했을때 상당한 충격을 받았다. 내가 대체 뭘 알고 있었던가..

코드, 인코딩이란 세계를 알았을때 정말 한단계 업그레이드 됬단 느낌을 받았다. 꼭 개념을 정립하시길

 

인코딩에 대한 가장 중요한 사실 한가지

웹에서 문자열 인코딩 ㅏㅇ식에 대한 정보를 어떻게 저장할까요?

사람들은 다양한 언오로된 페이지를 올리게 됩니다. 이럴경우 웹서버 자체는 각 파일이 어떤 인코딩을 따르는지 알아챌 방법이 없기에 일관ㄹ적으로 시스템 전체에 할당한 Content-Type헤더를 보낼수가 없습니다.

HTML파일 자체에 특별한 태그를 사용해서 HTML파일의 Content-Type을 넣을수 있다면 정말 편리할 것입니다. 어떻게 HTML파일 내부에서 사용하는 인코딩 규칙을 알기도 전에 HTML파일을 읽어들일수 있단 말입니까! 다행히도 흔히 사용하는 모든 인코딩은 32부터 127까지 문자를 동일하게 알파벳과 숫자로 사용하기에정상적인 글자로 시작하는 HTML앞부분을 활용할 수도 있습니다.

<html>

<head>

<meta http-equiv="Content-Type" content="text/html;charset=utf-8">

 

하지만 이런 메타 태그는 실제로 <head>부분에서 가장 처음에 등장해야만 합니다. 브라우저는 이 태그를 보자마자 다시 해석에 들어감

 

 

5장. 손쉬운 기능 명세 작성법 1강. 명세서 작업이 귀찮습니까?

명세가 필요한 이유

 

1. 어떤 코드를 작성하기 위해 몇주를 날린 프로그래머는 품질이야 어찌 되든 코드에 상당히 집착한다는 사실입니다.

결과적으로 마지막 제품은 초기에 잘못된 설계와 이상적인 설계 사이에서 타협점을 찾으려는 경향이 있습니다. 이런 상황은 "우리는 이미 모든 코드를 완성했으면, 이 코드를 절대 버릴 수 없다는 사실을 감안할때 얻을수 있는 최선의 설계입니다. 이상끝" 으로 용약할 수 있습니다. 물론 이는 "이 기간 동안 얻을수 있는 최선의 설계입니다."만큼 훌륭하지 못하지만 말입니다.

 2. 의사소통 시간의 절약

품질보증팀원 - 어떻게 테스트할지 안다.

마케팅 - 아직 만들지도 않은 제품에 대한 웹사이트에 올릴 모호한 ㅔ어포웨어 백서를 작성하는데 활용

사업개발 팀 - 신제품을 어떻게 사용할지에 대한 계획, 투자자 유치

고객 - 제품에 가치 판단

기술 지필가 - 멋진 메뉴얼 작성

관리자 - 관리 회합 도중에 아는체 하는데 사용 ^^

 

 

6장. 손쉬운 기능명세 작성법 2강. 명세가 뭡니까?

명세에 담아야할 내용

기능명세 (functional specification) 완전히 사용자 관점에서 제품이 어떻게 동작할지를 기술합니다. 어떻게 구현했는지는 신경도 쓰지 않습니다. 기능에 대해 이야기하고, 화면, 메뉴, 대화 상자와 같은 사용자 인터페이스 부품을 명세합니다.

 

 기술 명세(technical specification) 프로그램의 내부구현을 기술합니다. 자료구조와, 관계형 데이터베이스 모델과 프로그래밍 언어, 도구, 알고리즘 선택과 같은 항목을 다룹니다.

 

저자

1명이 해야되

 

시나리오

이 제품을 사용하는 방법에 대한 생생한 시나리오를 염두에 둬야한다.

 

회피목표(non-goal)

팀단위로 제품을 만드는 경우 실제든 상상이든 간에 갖가 좋아하는 상큼한 기능을 넣으려는 경향이 있다.

하면 안될 작업들을 명시

 

개괄

명세를 위한 목차와 유사

 

세부사항

너무나도 자세해 못 견딜 만큼 따분한 세부 사항을 매 화면마다 기술하는 장을 제공하는 겁니다.

 

미해결 문제 open issues

 

방주 side note

명세를 작성하는 동안에 프로그래머, 테스터, 마케팅 팀원, 기술 집필가과 같은 다양한 청중이 있음을 기억해야 합니다.

테스팅 노트, 마케팅노트, 문사화 노트

 

명세는 지석적으로 개정해야 합니다

제품을 개발하고 새로운 결정사항이 내려지면 계속 업데이트를 한다.

명세는 항상 제품이 동작하는 원리를 최대로 반영하는 그림자

명세는 단지 제품이 코드 완료시점(다시말해 모든 기능이 완벽하지만, 여전히 테스팅과 디버깅 작업이 남아있는상황)에서 굳어질 따름이다.

 

 

 

7장. 손쉬운 기능명세 작성법 3강. 하지만 어떻게?

누가 명세를 쓰느냐

 

프로그램 관리자를 어떻게 뽑을까요?

1. 코드 개발자를 프로그램 관리자로 승급사키지 마십시요.

명쾌한 언어 구사능력, 시장을 고려한 외교적 수완, 사용자 공감, 훌륭한 사용자 인터페이스 설계 등 좋은 프로그램 관리자의 필수 요소는 아무리 훌륭한 프로그래머라도 갖추기 어ㅕㄹ운 덕목들입니다.

2. 마케팅 부소 사람을 프로그램 관리자로 승급시키지 마십시오.

어떤 측면에서 프로그램 관리자는 소프트웨어 팀을 단단히 결합시키는 아교가 돼야 하며, 이런 상황에서 카리스마는 절대 필수 조건입니다.

3. 프로그래머가 프로그램 관리자에게 보고하는 체제가 되서는 안되니다.

상급자에게 보고를 해야하는 아급자의이장에서는 이견을 제시하기란 쉽지 않았을 겁입니다.

또 보고를 받기때문에 상급자라고 생각했다면, 어떤 경우에도 사견이나 짧은 생각으로 제 ㅅ방식대로 일을 처리하라고 명령했을지도 모릅니다.

 

 

8장. 손쉬운 기능명세 작성법 4강. 팁

좋은 명세를 쓰기위한 조언

 

모두가 명세를 읽어야 빛을 발합니다.

명세서를 읽도록 사람을 유인하는 방법은 일반적으로 글쓰기 실력과 밀접한 관련이 있습니다.

1. 재미있게 씁니다.

2. 명세를 쓰는 작업과 머리가 돌아가도록 쓰는 작업과 유사하다.

프로그래머는 '올바른' 명세를 '기술적으로'올바르게 써야 한다고 생각하며 그 결과 함정에 빠집니다.

올바른 작성은 물론이거니와 이해하기 쉽도록 작성해야 한다는 점입니다.

3. 최대한 단순하게 작성하라.

쉬운 문장으로 작성하는 방식은 왠지 프로답지 않다는 생각에, 형시걱이면 현학적인 언어를 남발하지는 마세요. 가능한 가장 쉬운 언어를 사용해야 합니다.

그림은 천마디 말보다 낫습니다.

4. 여러 차례에 걸쳐 검토하고 다시 읽어라

5. 표준 양식은 해롭다고 간주한다.

 

 

9장. 손쉬운 소프트웨어 일정 관리법

1. 마이크로소프트 엑셀을 사용합시다.

2. 단순하게 만듭니다.

3. 각 기능은 과업 여러개를 포함해야만 합니다.

4,. 담당 프로그래머만이 제대로 일정을 짤 수 있습니다.

5. 과업을 세부저그로 나누십시오.

경험적으로 규칙에 따르면, 각 과업은 적게는 2시간에서 많게는 16시간이내에 처리할 수 있어야 합니다. 일정 중에40시간(1주일)이 넘어가는 과업이 있으면, 충분히 쪼개지 않았다고 봐야 합니다.

6. 원본과 현재 예측을 동시에 유지하십시오.

원본예측, 현재 예측을 기록

7. 경과열은 매일 갱신하십시오.

8. 일정에 휴가나 휴일 같은 항목을 넣으십시오.

9. 일정에 디버깅 시간을 넣으십시오.

10. 일정에 통합시간을 넣으세요.

11. 일정에 여유 기간을 두십시오.

12. 관리자가 프로그래머에게 일정을 단축하도록 절대 강요하지 못하게 하십시오.

13. 일정은 장난감 블럭과도 같습니다.

장난감 블록이 산더미처럼 있는데 상자 안에 다 넣을 수는 없다면 둘중 하나를 선택해야 합니다.

6개월내에 제품을 출시할 수 있다고 생각했는데 일정이 갑자기 12개월로 늘어나면, 출시를 연기하든지 아니면 몇가지 기능을 삭제해야 합니다.

 

 

10장. 일일 빌드는 당신의 친구입니다.

TBD

 

11장. 고리타분한 버그 수정

버그 수정은 수정한 버그 가치가 수정 비용을 넘어설 때만 그 의미가 있습니다.

 

 

12장. 다섯 가지 세계

소프트웨어 개발 세계는 천차만별이며, 각기 다른 세계를 위해 존재하는 서로 다른 규칙이 있다는 걸 깨닫게 됐습니다.

 

1. 상품 소프트웨어

2. 사내용 소프트웨어

3. 임베디드 소프트웨어

4. 게임 소프트웨어

5. 일회성 소프트웨어

 

 

13장. 종이 프로토타이핑

연필과 실험적으로 만든 사용자 인터페이스를 그릴 종이 뭉치만 있으면 된다.

저렵하다.

 

 

14장. 화성인 아키텍트를 조심하세요

추상화를 추구하기 위해서 너무 높이 올라가면 산소 부족에 시달릴 겁니다.

때로는 똑똑한 사상가라도 어디서 멈출지를 모르기 때문에, 모순이 생기고 전체만을 아우르는, 그저 멋지고 훌륭한, 고차원적인 성운 사진만 찍어 냅니다. 하지만 실제로 이 사진에는 어떤 의미있는 내용도 담겨있지 않습니다. 이런 사람을 화성인 아키텍트라고 부르겠습니다.

 

 

 

15장. 쏘면서 움직여라

매일 조금씩 움직여야함 합니다.

코드가 엉성하고 버그 투성이고 아무도 원하지 않는다는 사실은 문제가 되지 않ㅅ흡니다. 늘 움직이면서 코드를 쓰고 버그를 지속적으로 잡아 낸다면, 시간은 당신 편입니다. 경쟁자가 당신을 향해 사격할 때 조심하십시오. 당신을 일제 사격에 허겁지겁 대응하게 만들어서 당신을 단지 앞으로 나가지 못하게 하려는건 아닐까요?

 마이크로소프트 사에서 나온 자료 접근 전략을 살펴봅시다. ODBC부터 RDO, DAO, ADO, OLEDB, 최근에 나온 ADO.NET까지 모두 새롭습니다. 이런 모든 절략이 기술적으로 ㄲ고 필요합니까?

알고보면 엄호 사격에 불과합니다. 경쟁사는 새 기술을 따라잡고 자사 제품에 이식하기 위해 시간을 쏟아 부을 수 밖에 없습니다. 따라서 새 기능을 추가할 시간이 있을리 만무하지오.

 사람들은 .NET에 대해 너무 염려한 나머지 전체 아키텍처를 .NET으로 다시 작성해야겠다고 결정합니다. 당연히 그렇게 해야 한다고 생각하기 때문입니다. 마이크로소프트 사는 당신을 향해 엄호 사격하면서 슬슬 접근해올 수 있지만, 당신은 옴짝달싹 할 수 없습니다. 아시겠습니까?

이게 바로 게임의 법칙이랍니다.

 

 

16장 장인정신

결함 1%를 고치기 위해 500%에 노력이 더 필요 하지만 그래도 해야 하는 이유는

상품 소프트웨어 회사라면 이 정도 장인정신은 사용자를 무척 기쁘게 만들고 장기간에 걸쳐 경쟁우위를 제공하는 핵심요인이므로, 시간을 투자해서 제대로 진행할 것입니다.

 

 

17장. 컴퓨터과학 분야에서 떠도는 세가지 미신

TBD

 

 

18장. 더불어 살기

유닉스와 윈도우간에 예기

 

19장. 자동으로 충둘 보고서를 수집하세요.

 

1.자료수집

자동으로수집하는 자료

a. 제품의 정확한 버젼

b. 운영체제 버전과 인터넷 익스플로러 버젼

c. 충돌이 발생한 코드 파일명과 행번호

d. 문자열로 표현하는 오류 메세지

e. 오류 종류를 위한 고유한 숫자 코드

f. 어떤 작업을 하고 있었는지에 대한 사용자 설명( 요건 입력받도록한다.)

g. 사용자 이메일 주소.

 

2. 회사로 전화걸기

HTTP를 이용 회사에 내용을 리포팅한다.

 

3. 중복 충돌 식별하기

충돌 자료의 핵심원인을 포함하는 유일한 문자열을 만들어서

내부 빌드에는 짝수 빌드번호, 고객에게 제공할 빌드에는 홀수 빌드 번호를 붙이므로, 이 충돌은 고격이 아니라 개발자에게 발생했음을 한눈에 확인할 수 있습니다.

 

4,. 디버깅

5. 선별

6. 충돌 보고는 당신에게 꼭 필요합니까?

 

7. 충돌 처리하기

  a. 비주얼 베이직

모든 함수에 에러루틴 포함

Private Sub cmd_Click()

On Error GoTo ERROR_cmd_Click

  ,..

  Exit Sub

 

ERROR_cmd_Click:

  HandleError "moduleName", "cmd_Click"

End Sub

 

  b. 윈도우즈 API에서 충돌 처리하기

구조적 예외처리사용

LONG UnhandledExceptionFilter(

  STRUCT _EXCEPTION_POINTERS* ExceptionInfo

) ;

SetUnhandledExceptionFilter함수를 호출하여 설정

 

__try/__catch 사용

C++예외가 아니라 널 포인터를 참조하는 경우와 같이 저 수준 실패에 대응할 수 있는 구조적인 예외를 다룰수 있도록 컴파일러에게 지시

 

ASP응용에서 충돌처리

500-100.asp

Set objASPError = Server.GetLastError

 

 

 

EOF <==이책에 옮긴이인 박재호님에 블로그에 따온 내용이다 :) 항상 문서에 마지막은 "끝"대신 EOF(End Of File)을 사용한다.