지식의힘!! [강컴]

Home >

CODE COMPLETE 2/E

지은이 스티브 맥코넬 | 출판사 정보문화사 | 발행일 2005년 04월 22일

	판매가	36,000원 → 26,280원 27%
	마일리지	1% 260원

	발행일	2005-04-22
	ISBN	8956742561 \| 9788956742564
	기타정보	번역서 \| 1181쪽

	예상출고일	금일 가능 (근무일기준)
	배송비	무료배송

컴퓨터공학

종합지수 100p 1 위

월간지수 100p 1 위

주간지수 100p 1 위

※ 네이버 체크아웃으로 구매시 비회원으로 구매가
됨으로 강컴 마일리지는 적립 되지 않습니다.

	이 책의 원서
		Code Complete (2/E) Microsoft Press \| Steve McConnell

컴퓨터공학 분야 베스트(월)

1.	More Joel on Software 조엘 온 소프트웨어를 넘어서
2.	테스트 주도 개발 : Test-Driven Development[재출간판]
3.	예제로 배우는 프로그래밍 루아

컴퓨터공학 분야 베스트(주)

1.	생각하는 프로그래밍[재출간판]
2.	Refactoring (한글판)
3.	성공과 실패를 결정하는 1%의 통신원리

컴퓨터공학 분야 신간

1.	Motion Analysis and Image Sequence Processing
2.	Xilinx 6.3 Student Edition
3.	VLSI Artificial Neural Networks Engineering

프로그래밍에 대한 최고의 실무적인 지침서로 널리 알려진 스티브 맥코넬의 CODE COMPLETE 제2판. 이번 책은 소프트웨어 개발 단계 중 "구현" 부분에 초점을 맞추고, 소프트웨어 구현에 대한 예술과 과학을 설명하기 위해서 최신의 기법들과 수백 개의 새로운 예제 코드가 포함되어 개정되었다.

맥코넬은 연구와 학계, 그리고 상업적인 기법들에 있는 지식들을 바탕으로, 가장 효율적인 기법과 반드시 알아야 하는 원칙들을 이 실용적인 지침서에서 종합적으로 다루었다.

Part 1 기초 수립

Chapter 1 소프트웨어 구현으로의 초대
1.1 소프트웨어 구현이란 무엇인가?
1.2 소프트웨어 구현이 중요한 이유는 무엇인가?
1.3 이 책을 읽는 방법
요점 정리

Chapter 2 소프트웨어 개발의 이해를 돕기 위한 비유
2.1 비유의 중요성
2.2 소프트웨어 비유의 사용 방법
2.3 일반적인 소프트웨어 비유
소프트웨어 글쓰기 : 코드 작성하기
소프트웨어 농사 : 시스템 키우기
소프트웨어 조개 양식 : 시스템 증대(accretion)
소프트웨어 건축 공사 : 소프트웨어 구축
소프트웨어 기법의 적용 : 지능적인 도구 상자
비유들의 결합
참고 자료
요점 정리

Chapter 3 준비는 철저하게 : 선행 조건
3.1 선행 조건의 중요성
선행 조건이 현대적인 소프트웨어 프로젝트에 적용되는가?
불완전한 준비의 원인
구현 전에 선행 조건을 수행하기 위한 필수적인 논의
3.2 소프트웨어의 종류 결정
선행 조건에서의 반복적인 접근 방법이 갖는 효과
반복적인 방법과 순차적인 방법의 선택
3.3 문제-정의 선행 조건
3.4 요구 사항 선행 조건
왜 공식적인 요구 사항이 필요한가?
견고한 요구 사항에 대한 미신
구현중에 요구 사항 변경 다루기
3.5 아키텍처 선행 조건
전형적인 아키텍처의 구성 요소
3.6 선행 조건에 소요되는 시간
참고 자료
요점 정리

Chapter 4 ? 구현 시 결정해야 할 핵심적인 사항들
4.1 프로그래밍 언어 선택
언어 설명
4.2 프로그래밍 규약
4.3 기술적인 흐름의 파악
언어로의 프로그래밍 예제
4.4 주요 구현 방법론의 선택
요점 정리

Part 2 고급 코드 생성하기

Chapter 5 ? 구현 설계
5.1 설계의 문제점
설계는 불명확한 문제이다
결과는 정돈되었을 지라도, 설계는 엉성한 프로세스이다
설계는 트레이드오프와 우선순위에 관한 것이다
설계에는 제약이 따른다
설계는 다양성을 지닌다
설계는 발견적 학습 과정이다
설계는 창발적이다
5.2 설계의 핵심 개념
소프트웨어의 기본적인 기술적 의무 : 복잡성 관리
바람직한 설계의 특징
설계 수준
5.3 빌딩 블록의 설계 : 발견적 학습
실세계의 객체를 찾아라
일관성 있는 추상화를 구성하라
세부 사항들을 캡슐화하라
상속이 설계를 단순화할 수 있을 때 상속하라
비밀을 숨겨라(정보 은닉)
변경될 것 같은 영역을 규명하라
느슨한 결합을 유지하라
일반적으로 널리 사용되는 설계 패턴을 찾아라
다른 발견적 학습
발견적 접근 방법을 위한 지침
5.4 설계 방법
반복
분할 정복
하향식과 상향식 설계 접근 방법
실험적인 프로토타이핑(prototyping)
협력적인 설계
설계를 얼마나 해야 할까?
설계 작업 기록하기
5.5 유명한 방법론에 대한 의견
참고 자료
요점 정리

Chapter 6 ? 클래스 다루기
6.1 클래스 기초 : 추상 데이터 형(ADT)
ADT가 필요한 예
ADT 사용 시의 혜택
ADT의 더 많은 예
비 객체 지향 프로그래밍 환경에서 여러 개의 데이터 인스턴스를 ADT로 다루기
ADT와 클래스
6.2 좋은 클래스 인터페이스
좋은 추상화
좋은 캡슐화
6.3 설계와 구현 문제
포함(“has a” 관계)
상속(“is a” 관계)
멤버 함수와 데이터
생성자
6.4 클래스를 작성하는 이유
피해야 할 클래스
클래스 작성의 이유에 대한 요약
6.5 언어에 따른 문제
6.6 클래스를 넘어서 : 패키지
참고 자료
요점 정리

Chapter 7 ? 고급 루틴
7.1 루틴을 작성하는 타당한 이유
루틴으로 작성하기에는 너무 단순해 보이는 연산
루틴 작성의 이유에 대한 요약
7.2 루틴 수준에서의 설계
7.3 좋은 루틴 이름
7.4 루틴의 길이에 대한 문제
7.5 루틴의 매개변수를 사용하는 방법
7.6 함수 사용 시 특별히 고려해야 할 사항들
함수를 사용할 할 때와 프로시저를 사용할 때
함수의 리턴 값 설정
7.7 매크로 루틴과 인라인 루틴
매크로 루틴 사용의 한계
인라인 루틴
요점 정리

Chapter 8 ? 방어적인 프로그래밍
8.1 타당하지 않은 입력으로부터 프로그램의 보호
8.2 어설션(Assertion)
자신만의 어설션 메커니즘 구축하기
어설션 사용 지침
8.3 오류 처리 기법
견고성 대 정확성
오류 처리를 위한 고수준 설계
8.4 예외
8.5 오류에 의해서 발생하는 손해를 막기 위한 방책
방책과 어설션 간의 관계
8.6 디버깅 보조 도구
제품의 제약 사항들을 개발 버전에 무의식적으로 적용하지 않는다
디버깅 보조 도구의 초기 사용
공격적인 프로그래밍을 사용하라
디버깅 보조 도구를 제거하기 위한 계획
8.7 제품 코드 안에 남는 방어적인 프로그래밍 코드 정하기
8.8 방어적인 프로그래밍에 대해서 방어적이 되는 것
참고 자료
요점 정리

Chapter 9 ? 의사코드 프로그래밍 프로세스
9.1 클래스와 루틴을 작성하는 단계에 대한 요약
클래스 작성 단계
루틴을 작성하는 단계
9.2 전문가를 위한 의사코드
9.3 PPP를 사용한 루틴 구현
루틴을 설계한다
루틴의 코드를 작성한다
코드를 검사한다
미해결된 부분을 정리한다
필요한 만큼 단계를 반복한다
9.4 PPP의 대안
요점 정리

Part 3 변수

Chapter 10 ? 변수 사용 시 일반적인 문제
10.1 데이터 사용 능력
데이터 사용 능력 테스트
데이터 형에 대한 참고 자료
10.2 변수 선언을 쉽게 만드는 방법
암시적 선언
10.3 변수의 초기화에 대한 지침
10.4 범위
변수에 대한 참조를 지역화하라
변수의 “수명”을 가능한 한 짧게 유지한다
범위를 최소화하기 위한 일반적인 지침
범위의 최소화에 대한 설명
10.5 지속성
10.6 바인딩 시간
10.7 데이터 형과 제어 구조 간의 관계
10.8 변수를 한 목적으로만 사용하는 방법
요점 정리

Chapter 11 ? 변수 이름의 효과
11.1 좋은 이름에 대한 고려사항
명명(naming) 시 가장 중요한 고려사항
문제 지향성(Problem Orientation)
최적의 이름 길이
범위가 변수 명에 미치는 효과
변수 이름에서의 계산값 한정자
변수 이름의 일반적인 반의어들
11.2 데이터의 특정 타입에 대한 명명
루프 인덱스의 명명
상태 변수의 명명
임시 변수의 명명
불린 변수의 명명
열거 형의 명명
상수의 명명
11.3 명명 규약의 효과
왜 규약을 가지는가?
언제 명명 규약이 필요한가?
형식화 정도
11.4 비형식적인 명명 규약
언어에 독립적인 규약을 위한 지침
특정 언어의 규약을 위한 지침
혼합 언어 프로그래밍에서 고려할 사항
명명 규약 샘플
11.5 표준화된 접두사들
사용자 정의 축약형
의미적 접두사
표준화된 접두사의 장점
11.6 읽기 쉬운 짧은 이름
일반적인 축약 지침
음성 축약
축약어에 대한 의견
11.7 피해야 할 이름의 종류
요점 정리

Chapter 12 ? 기본 데이터 형
12.1 일반적인 숫자
12.2 정수
12.3 부동소수점
12.4 문자와 문자열
C 언어에서의 문자열
12.5 불린(Boolean) 변수
12.6 열거 형
만약 언어가 열거 형을 지원하지 않는다면?
12.7 명명된 상수
12.8 배열
12.9 새로운 형 만들기(형 별명)
왜 새로운 형을 생성하는 예제들이 파스칼이나 에이다로 작성되었는가?
새로운 형을 만들기 위한 지침들
요점 정리

Chapter 13 ? 특이한 데이터 형
13.1 구조체
13.2 포인터
포인터를 이해하는 패러다임
포인터 사용 팁
C++ - 포인터 포인터
C - 포인터 포인터
13.3 전역 데이터
전역 데이터를 사용할 때 발생하는 일반적인 문제점
전역 데이터를 사용하는 이유
최후의 수단으로만 전역 데이터를 사용하라
전역 데이터 대신 접근 루틴의 사용
전역 데이터를 사용할 때의 위험 요소를 줄이는 방법
참고 자료
요점 정리

Part 4 명령문

Chapter 14 ? 직선형 코드 구성하기
14.1 순서가 중요한 명령문
14.2 순서가 중요하지 않은 명령문
코드를 하향식으로 읽을 수 있도록 작성하기
연관된 명령문 그룹화하기
요점 정리

Chapter 15 ? 조건문 사용
15.1 if 문
if-then 명령문
연속적인 if-then-else 문
15.2 case 문
가장 효율적인 case 순서의 선택
case 문 사용 팁
요점 정리

Chapter 16 ? 루프 제어
16.1 루프의 종류 선택
while 루프를 사용하는 시기
Loop-With-Exit 루프를 사용하는 시기
for 루프를 사용하는 시기
foreach 루프를 사용해야 할 시기
16.2 루프의 제어
루프 진입하기
루프의 중간 부분 처리하기
루프의 종료
종결점 확인
루프 변수 사용
루프가 얼마나 길어야 할까?
16.3 루프를 쉽게 작성하는 법 - 안에서부터 밖으로
16.4 루프와 배열의 대응
요점 정리

Chapter 17 ? 특이한 제어 구조들
17.1 여러 곳에서 리턴하는 루틴
17.2 재귀적 용법
재귀적 용법의 예
재귀 호출 사용 팁
17.3 goto 문
goto 문의 사용을 반대하는 의견
goto 문의 사용을 찬성하는 의견
가짜 goto에 대한 논쟁
오류 처리와 goto 문
goto 문과 else 절에서 공유하는 코드
goto 문의 사용법 요약
17.4 특이한 제어 구조에 대한 전망
참고 자료
요점 정리

Chapter 18 ? 테이블을 활용하는 방법
18.1 테이블을 활용할 때 일반적으로 고려해야 할 사항들
테이블을 활용한 기법의 두 가지 문제점
18.2 직접 접근 방식
월별 일 수 예제
보험료 예제
유연한 메시지 형식 예제
참조 키 조작하기
18.3 인덱스 접근 방식
18.4 단계적 접근 방식
18.5 테이블 참조 방법의 다른 예제들
요점 정리

Chapter 19 ? 제어와 관련된 일반적인 문제
19.1 불린 표현식
불린 테스트에서 true와 false 사용하기
복잡한 표현식을 단순하게 만들기
불린 표현식을 긍정문으로 작성하기
괄호를 사용하여 이해하기 쉬운 불린 표현식 만들기
불린 표현식 평가 방법의 이해
숫자의 크기 순서대로 수치 표현식 작성하기
0을 비교하는 방법
불린 표현식과 관련된 일반적인 문제들
19.2 복합문(블록)
19.3 널 명령문
19.4 지나치게 깊은 중첩 구조의 처리
깊은 중첩 구조를 줄이는 기법 요약
19.5 프로그래밍의 기초 : 구조적 프로그래밍
구조적 프로그래밍의 세 가지 요소
19.6 제어 구조와 복잡도
복잡도가 얼마나 중요한가?
복잡도를 줄이기 위한 일반적인 방법
복잡도 측정의 활용
다른 종류의 복잡도
요점 정리

Part 5 코드 향상

Chapter 20 ? 소프트웨어의 품질에 대한 조망
20.1 소프트웨어 품질의 특성
20.2 소프트웨어의 품질을 향상시키기 위한 기법들
개발 프로세스
목표의 설정
20.3 품질 향상 기법의 상대적 효율성
발견된 결함의 비율
결함 발견 비용
결함 수정 비용
20.4 품질 보증 활동 시기
20.5 소프트웨어 품질의 일반적인 원칙
참고 자료
요점 정리

Chapter 21 ? 협력적인 구현
21.1 협력적인 개발 방법의 개요
다른 품질 보증 기법을 보완하는 협력적인 구현
협력적인 구현은 협동 문화와 프로그래밍 경험을 제공한다
공동 소유권을 협력적인 구현의 모든 형태에 적용한다
협력을 구현 전 만큼이나 구현 후에도 적용한다
21.2 짝 프로그래밍(Pair Programming)
짝 프로그래밍의 성공 요건
짝 프로그래밍의 혜택
21.3 형식적인 정밀 검사
정밀 검사로부터 어떤 결과를 기대할 수 있는가?
정밀 검사에서의 역할
정밀 검사의 일반적인 절차
정밀 검사에서의 자존심
정밀 검사와 Code Complete
정밀 검사 요약
21.4 다른 종류의 협력적인 개발 방법
워크-쓰루(work-throughs)
코드 읽기
프리젠테이션(Dog-and-Pony Shows)
협력적인 구현 기법의 비교
참고 자료
요점 정리

Chapter 22 ? 개발자 테스트
22.1 소프트웨어 품질에서 개발자 테스트의 역할
구현 과정중의 테스트
22.2 개발자 테스트에 대한 바람직한 접근 방법
테스트를 먼저 할 것인가? 나중에 할 것인가?
개발자 테스트의 한계
22.3 여러 가지 테스트 트릭
불완전한 테스트
구조적인 기초 테스트
데이터 흐름 테스트
등가 분할
오류 추측
경계 분석
나쁜 데이터
좋은 데이터
수동으로 점검하기에 편리한 테스트 케이스를 사용하라
22.4 전형적인 오류
어떤 클래스가 가장 많은 오류를 포함하고 있는가?
오류의 분류
결점이 있는 구현으로부터 발생하는 오류의 비율
얼마나 많은 오류를 발견할 것으로 예상해야 할까?
테스트 자체의 오류
22.5 테스트 지원 도구
개별적인 클래스들을 테스트하기 위한 비계 작성
비교 도구
테스트 데이터 생성기
커버리지 모니터
데이터 레코더/로깅
심볼릭 디버거(Symbolic Debugger)
시스템 교란기
오류 데이터베이스
22.6 테스트를 향상시키는 방법
테스트 계획 세우기
다시 테스트하기(회귀 테스트)
자동화된 테스트
22.7 테스트 기록을 보존하는 방법
개인 테스트 기록
참고 자료
요점 정리

Chapter 23 ? 디버깅
23.1 디버깅 문제의 개요
소프트웨어 품질에서 디버깅의 역할
디버깅 성과의 차이
기회로서의 결함
비효율적인 접근 방법
23.2 결함의 발견
과학적인 디버깅 방법
결함을 찾는 데 도움이 되는 팁
구문 오류
23.3 결함의 수정
23.4 디버깅에서 심리학적으로 고려해야 할 사항들
'심리적인 자세'가 디버깅 실명(보지 못함)에 영향을 주는 방법
'심리적인 거리'가 어떻게 도움을 줄 수 있는가?
23.5 디버깅 도구 - 분명하고 그렇게 분명하지 않은 도구
소스 코드 비교 도구
컴파일러 경고 메시지
확장된 문법과 논리 검사
실행 프로파일러
테스트 프레임워크/비계(scaffolding)
디버거
참고 자료
요점 정리

Chapter 24 ? 리팩토링
24.1 소프트웨어 진화의 종류
소프트웨어 진화에 대한 철학
24.2 리팩토링에 대한 소개
리팩토링을 하는 이유
리팩토링을 하면 안 되는 이유
24.3 구체적인 리팩토링
데이터 수준 리팩토링
명령문 수준 리팩토링
루틴 수준 리팩토링
클래스 구현 리팩토링
클래스 인터페이스 리팩토링
시스템 수준 리팩토링
24.4 안전한 리팩토링
리팩토링에 좋지 않은 시기
24.5 리팩토링 전략
참고 자료
요점 정리

Chapter 25 ? 코드 최적화 전략
25.1 성능의 개요
품질의 특성과 성능
성능과 코드 최적화
25.2 코드 최적화에 대한 소개
파레토 법칙
노부인들의 이야기
최적화의 시기
컴파일러 최적화
25.3 느리고 비대한 부분들
비효율성의 공통적인 원인
공통적인 연산의 상대적인 성능 비용
25.4 측정
측정은 정확해야 한다
25.5 반복
25.6 코드 최적화에 대한 접근 방법의 요약
참고 자료
요점 정리

Chapter 26 ? 코드 최적화 기법
26.1 논리 구조
답을 알고 있을 때에는 테스트를 중단하라
빈도에 따른 테스트 정렬
유사한 논리 구조의 성능을 비교하라
복잡한 표현식을 테이블 참조로 대체하라
소극적 평가(lazy evaluation)를 사용하라
26.2 루프
언스위칭(Unswitching)
재밍(jamming)
언롤링(unrolling)
루프 내부 작업의 최소화
감시 값(sentinel values)
가장 빈번한 루프를 안쪽에 작성한다
강도 감소
26.3 데이터 변환
부동소수점 대신 정수를 사용하라
가능한 한 가장 적은 차수의 배열을 사용하라
배열에 대한 참조를 최소화하라
보조 인덱스를 사용하라
캐싱(caching)을 사용하라
26.4 표현식
대수 항등식을 사용하라
강도 감소를 사용하라
컴파일 시간에 초기화하라
시스템 루틴을 주의하라
상수의 정확한 형을 사용하라
결과를 사전에 계산하라
공통적인 하위 표현식을 제거하라
26.5 루틴
루틴을 인라인(inline)으로 재작성하라
26.6 저급 언어를 이용한 재구성
26.7 변경이 많을수록 상태는 그대로
참고 자료
요점 정리

Part 6 시스템 고려사항

Chapter 27 ? 프로그램의 크기가 구현에 미치는 영향
27.1 의사 소통과 크기
27.2 프로젝트 크기의 범위
27.3 프로젝트의 크기가 오류에 미치는 영향
27.4 프로젝트의 크기가 생산성에 미치는 영향
27.5 프로젝트의 크기가 개발 활동에 미치는 영향
활동 비율과 크기
프로그램, 제품, 시스템, 시스템 제품
방법론과 크기
참고 자료
요점 정리

Chapter 28 ? 구현 관리
28.1 좋은 코드 작성의 장려
표준 설정 시 고려할 사항들
좋은 코드 작성을 장려하기 위한 기법
이 책의 역할
28.2 형상 관리
형상 관리란 무엇인가?
요구 사항과 설계의 변경
소프트웨어 코드 변경
도구 버전
기계 구성
백업 계획
형상 관리에 대한 참고 자료
28.3 구현 일정의 예측
예측 방법
구현 양에 대한 예측
일정에 미치는 영향들
예측 對 제어
일정에 늦었을 때 해야 할 일
소프트웨어 예측에 대한 참고 자료
28.4 측정
소프트웨어 측정에 대한 참고 자료
28.5 프로그래머를 사람으로 대우하기
프로그래머들은 어떻게 시간을 보내는가?
성능과 품질의 다양성
신앙적인 문제
물리적인 환경
인간으로써의 프로그래머에 대한 참고 자료
28.6 관리자 관리
참고 자료
요점 정리

Chapter 29 ? 통합
29.1 통합 접근 방법의 중요성
29.2 통합 횟수 - 단계별 또는 점증적?
단계별 통합
점증적 통합
점증적 통합의 이점
29.3 점증적 통합 전략
하향식 통합
상향식 통합
샌드위치 통합
위험 지향적인 통합
기능 지향적인 통합
T-자형 통합
통합 접근 방법에 대한 요약
29.4 일별 빌드와 스모크 테스트
어떤 종류의 프로젝트에 일별 빌드를 사용할 수 있는가?
지속적인 통합
참고 자료
요점 정리

Chapter 30 ? 프로그래밍 도구들
30.1 설계 도구
30.2 소스 코드 도구
편집
코드 품질 분석
소스 코드 리팩토링
버전 관리
데이터 사전
30.3 실행 코드 도구
코드 생성
디버깅
테스트
코드 최적화
30.4 도구 지향적인 환경
30.5 자신만의 프로그래밍 도구 개발하기
프로젝트에 특화된 도구들
스크립트(Script)
30.6 프로그래밍 도구에 대한 환상
참고 자료
요점 정리

Part 7 소프트웨어 장인정신

Chapter 31 ? 배치와 방식
31.1 배치 기초
극단적인 배치
기본적인 형식화 법칙
프로그램에 대한 사람과 컴퓨터의 해석
좋은 배치는 얼마나 가치가 있는가?
종교로서의 배치
좋은 배치의 목표
31.2 배치 기술
공백
괄호
31.3 배치 방식
순수 블록
순수 블록 흉내 내기
블록 경계를 나타내기 위해서 begin-end 쌍(중괄호) 사용
줄 끝 배치
어떤 방식이 가장 좋은가?
31.4 제어 구조의 배치
제어 구조 블록의 형식화에 대한 세세한 부분들
추가적인 고려사항들
31.5 단일 명령문의 배치
명령문 길이
명료함을 위하여 공백 사용하기
연속적인 줄 형식화하기
한 줄에 한 명령문만 작성한다
데이터 선언 배치하기
31.6 주석의 배치
31.7 루틴의 배치
31.8 클래스의 배치
클래스 인터페이스 배치하기
클래스 구현 배치하기
파일과 프로그램 배치하기
참고 자료
요점 정리

Chapter 32 ? 스스로를 설명하는 코드
32.1 외부 문서
32.2 문서화를 위한 프로그래밍 방식
32.3 주석을 작성할 것인가? 작성하지 않을 것인가?
32.4 효율적인 주석을 위한 핵심 사항
주석의 종류
효율적으로 주석 작성하기
가장 적당한 수의 주석
32.5 주석 작성 기법
한 줄마다 주석 작성하기
코드 단락에 대한 주석 작성하기
데이터 선언에 주석 작성하기
제어 구조에 주석 작성하기
루틴에 주석 달기
클래스와 파일, 그리고 프로그램에 대한 주석
32.6 IEEE 표준
소프트웨어 개발 표준들
소프트웨어 품질 보증 표준들
관리 표준들
표준에 대한 개요
참고 자료
요점 정리

Chapter 33 ? 개인 성격
33.1 개인 성격은 주제를 벗어난 것 아닌가?
33.2 지성과 겸손
33.3 호기심
33.4 지적인 정직함
33.5 의사 소통과 협동
33.6 창의성과 훈련
33.7 게으름
33.8 생각만큼 중요하지 않은 특성
인내력
경험
별난 프로그래밍
33.9 습관
참고 자료
요점 정리

Chapter 34 ? 소프트웨어 장인(匠人)에 대한 주제
34.1 복잡성 정복
34.2 자신에게 맞는 프로세스 선택
34.3 컴퓨터보다 사람을 위한 프로그램을 작성하라
34.4 언어에 얽매이지 말고 언어를 활용하는 프로그램을 작성하라
34.5 규약을 이용하여 주의를 집중하라
34.6 문제 중심의 프로그램
프로그램을 추상화 수준으로 나누기
문제 도메인에서 작업하기 위한 저수준 기술들
34.7 낙석을 주의하라
34.8 반복, 반복, 또 반복
34.9 소프트웨어와 신조를 떼어 놓아라
소프트웨어 계시(Oracles)
절충주의
실험
요점 정리

Chapter 35 ? 더 많은 정보를 얻으려면
35.1 소프트웨어 구현에 관한 정보
35.2 구현 외의 주제
개괄적인 자료들
소프트웨어 공학 관련 서적 개요
다른 추천 도서들
35.3 정기 간행물
구하기 쉬운 프로그래머 잡지
구하기 어려운 프로그래머 저널
전문적인 간행물
35.4 소프트웨어 개발자의 독서 계획
기초 수준
중급자 수준
전문가 수준
35.5 전문가 협회에 가입하기

INDEX

Steve McConnell은 개발 분야에 있어서 가장 뛰어난 저자이자 대변인 중 한 명으로 인정받고 있다. 그는 Construx Software의 수석 소프트웨어 엔지니어이며, Software Development 잡지의 Jolt Award를 수상한 Code Complete과 Rapid Development, 그리고 Software Project Survival Guide와 Professional Software Development의 저자이다.

【 저자·역자 Prolog 】

처음 Code Complete 제2판의 번역을 맡게 되었을 때, 이렇게 유명하고 잘 정리된 책을 어떻게 우리 글로 작성할 것인지에 대해서 굉장히 큰 부담감을 느꼈지만, 책을 정독해 나가면서 우리 글로 바꾸는 것도 의미 있는 작업이겠다는 확신을 가질 수 있었다.

여러분은 이 책이 초보자를 위한 책이라고 생각하는가? 역자는 전혀 그렇게 생각하지 않는다. 물론, 초보자들에게도 유익한 내용들을 많이 다루고 있지만, 이 책을 통해서 얻을 수 있는 것들은 초보자보다는 중급 이상의 프로그래머들일 것이라고 확신하고 있다. 가끔 이 책의 제1판을 보고 너무 쉬운 내용을 다루고 있다거나 기술적인 내용들을 깊이 있게 다루고 있지 않다는 표면적인 이유를 들어 이 책의 수준을 폄하하는 사람들을 보게 된다. 물론, 이 책은 기술 서적이 아니다. 그렇다고 다분히 이론적인 부분만을 강조하고 있는 책도 아니다. 이 책은 실무 프로그래머에게 도움이 될 수 있는 이론적인 내용들을 실무적인 내용에 맞게 맥코넬의 언어로 쓰여진 것이다. 그가 말했듯이, 우리가 실무에서 행하고 있는 여러 가지 습관들에 관한 내용들은 전 세계의 학자들이나 숙련된 프로그래머들에 의해서 정리된 것들이 대부분이다. 우리에게 주어진 선택권은 그러한 자료들을 일일이 찾아보면서 어떤 것들이 자신의 환경에 맞는지 확인해 보는 수고를 하거나, 그러한 자료들을 일목요연하게 정리한 이 책을 보는 방법이 있다. 여러분은 어떤 방법을 선택할 것인가?

이 책을 번역하면서 가장 어려웠던 부분은 (모든 외국 서적들이 그렇듯이) 저자의 문화를 이해하는 것이었다. 사실 번역본이 주어나 동사를 우리 글로 바꾸는 수준이라면 어느 누구도 번역본을 사려고 하지 않을 것이다. 역자의 가장 큰 의무는, 저자의 문화를 우리의 문화로 바꾸어 독자들의 이해를 돕는 것이라고 생각한다. 따라서 번역을 진행하면서 다소 이해하기 어렵다고 생각된 부분들에는 '역자 주'를 제공하여 이해를 도왔으며, 때로는 우리가 쉽게 이해할 수 있는 문장으로 대체하기도 하였다.

역자는 언제나 AS 정책을 가장 중요하게 생각한다. 이 책이 출판되더라도 언제나 AS 정신으로 독자들에게 봉사할 준비가 되어 있다. 따라서 어색한 번역이 있거나 내용에 문제가 있다고 생각되는 부분들이 있다면, 언제든지 역자의 메일로 보내주기 바란다.

역자 서우석