상세정보

기본적인 소프트웨어 개발 기법과 함께 리팩토링, 테스팅 등 더 효과적인 시스템 관리법을 재미있는 예제를 통해 쉽게 학습할 수 있는 책. 효율적인 프로젝트 진행 관리 방법과 완료된 소프트웨어의 유지 보수를 위한 리팩토링과 버전 관리, 배포 등 다양한 절차를 개발 순서에 맞게 책 전체에 걸쳐 포괄적으로 설명하고 있다.

또한 이론으로는 잘 알고 있지만 실제 프로젝트에서 사용하기 어려웠던 이터레이션, 테스트 주도 개발 등을 현실적인 예시를 통해 쉽고 재미있게 배울 수 있다. 테스트 주도 개발에 대해서도 잘 설명하고 있어 테스트 주도 개발에 대해 알아야 하지만 집중적인 학습이 필요치 않은 개발자들에게 도움을 준다.

이 책이 제시하는 핵심 내용
이 책은 단순히 소프트웨어를 개발하는 방법뿐 아니라, 어떻게 하면 더욱 잘 만들 수 있을 것인가를 논한다.
즉, 기본적인 소프트웨어 개발 기법과 함께 리팩토링, 테스팅 등 더 효과적인 시스템 관리법을 재미있는 예제를 통해 쉽게 학습할 수 있다.

이 책의 특징과 장점
- 단순한 코드의 나열이 아니라 실제적인 프로젝트에 대입한 예제로 학습이 가능하며 버전 컨트롤, 테스트, 이터레이션, 리팩토링 등 프로젝트 진행에 필수적이지만 간과하기 쉬운 내용을 상세하고 체계적으로 다루고 있다.
- 또한 테스트 주도 개발에 대해서도 잘 설명하고 있어 테스트 주도 개발에 대해 알아야 하지만 집중적인 학습이 필요치 않은 개발자들에게 도움이 될 것이다.

어떤 독자를 위한 책인가?
- 1차 타겟 : 프로젝트를 선두에서 지휘하는 프로그래밍 팀의 리더
- 2차 타겟 : 프로젝트의 상부와 하부를 연결하는 중추 역할을 하는 프로그래머

소프트웨어 개발을 위한 다양한 기법을 학습한다.

이 책은 훌륭한 소프트웨어를 개발하기 위한 효율적인 프로젝트 진행 관리 방법과 완료된 소프트웨어의 유지 보수를 위한 리팩토링과 버전 관리, 배포 등 다양한 절차를 개발 순서에 맞게 책 전체에 걸쳐 포괄적으로 설명하고 있다. 또한 이론으로는 잘 알고 있지만 실제 프로젝트에서 사용하기 어려웠던 이터레이션, 테스트 주도 개발 등을 현실적인 예시를 통해 쉽고 재미있게 배울 수 있다.

헤드퍼스트 소프트웨어 개발은 정말 기발한 책입니다. 사려 깊게 디자인된 정보 다이어그램들과 똑부러지는 이미지들은 명확하고 정확한 정보를 여러분 두뇌 속으로 전달해 줄 것입니다.
- 스코드 한셀만, Scott Hanselman's Computer Zen사의 소프트웨어 개발자, 연사, 저자

정보제공 :

목차
소개
 이 책은 어떤 독자를 위한 책일까요? = 30
 아마 지금쯤 여러분 머리속에는 이런 생각이 지나가고 있겠죠? = 31
 초인지: 생각하는 것에 대해 생각하는 것 = 33
 두뇌를 정복하는 방법 = 35
 읽어보세요 = 36
 기술 리뷰 팀 = 38
 감사의 글 = 39
1 훌륭한 소프트웨어 개발하기 
 Tom’s Trails을 온라인으로 = 42	
 대부분의 프로젝트에는 두 가지 중요한 고민이 있습니다 = 43	
 개발에 대한 빅뱅(Big Bang)식 접근 = 44	
 2주 후로 가보면 = 45	
 빅뱅 개발은 대개 큰 혼란(BIG MESS)으로 마무리됩니다 = 46	
 훌륭한 소프트웨어 개발이란... = 49
 이터레이션으로 목표 달성하기 = 50
 각 이터레이션은 작은 프로젝트와 같습니다 = 54	
 각 이터레이션은 품질 좋은 소프트웨어입니다 = 54	
 고객의 마음은 변합니다	= 60
 수정을 어떻게 하느냐는 여러분에게 달려있습니다 = 60	
 여러분은 이미 오랫동안 개발을 진행해 왔습니다 = 61	
 이터레이션은 변화를 자동으로 (그것도 잘) 관리합니다 = 62	
 여러분의 소프트웨어는 출시될 때까지 완료된 게 아닙니다 = 65	
 소프트웨어 개발 도구상자 활용하기 = 66
2 요구사항 수집하기
 오리온 우주투어 차세대 프로젝트 = 70	
 고객에게 더 많은 정보를 달라고 말하세요 = 73	
 고객과의 블루스카이 = 74	
 때로는 블루스카이를 진행할 때 아래처럼 될 수 있습니다 = 76
 사람들이 정말로 원하는 것을 찾아보세요 = 77	
 여러분의 요구사항은 고객지향적이어야 합니다 = 79	
 고객 피드백으로부터 요구사항 확장하기 = 81
 사용자 스토리로 프로젝트에서 무엇을 해야 하는지를 정의하고... 언제 정의해야 하는지를 알 수 있습니다 = 83
 짤막한 대화 = 87
 계획 포커 게임	= 88
 가정은 살아있는 동안 재판을 받습니다 = 91
 오래 걸리는 사용자 스토리 추정은 잘못된 추정입니다 = 94	
 계획 포커의 목적은 의견 수렴에 있습니다 = 97
 이터레이션 주기를 추정하는 것에 대한 요구사항 = 100	
 마지막으로, 전체 프로젝트에 대해 추정할 준비가 되었습니다 = 103
3 프로젝트 계획하기
 고객은 바로 지금 자신들의 소프트웨어를 갖길 원합니다 = 110
 고객과 함께 우선순위 정하기 = 113
 마일스톤 1.0에 뭐가 있는지 알게 되었습니다(잘 알게 되었을 것 같네요) = 114
 기능이 맞지 않으면 우선순위를 재조정합니다 = 115
 사람을 더 투입하면 더 큰 성과가 날까요? = 117
 적정 수준의 마일스톤 1.0을 위해 일하세요 = 118
 이터레이션은 짧고 달콤해야 합니다 = 125	
 계획을 현실과 비교하기	= 127
 속도는 추정값에서 부담되는 부분을 책임집니다 = 129
 프로그래머는 꿈결 같은 시간을 생각합니다 = 130
 개발자는 현실적인 시간을 생각하는 사람입니다 = 131
 언제 이터레이션이 너무 길어지나요? = 132
 이터레이션 들어가기 전에 속도 반영하기 = 133
 평가를 위한 시간 = 137	
 [피곤하게 하는] 고객 다루기 = 138	
 벽에 커다란 현황판을 만드세요 = 140	
 팀의 생기를 없애는 방법 = 143
4 사용자 스토리와 태스크
 iSwoon을 소개합니다 = 150	
 태스크의 합이란 무엇을 의미할까요? = 153	
 남은 작업 구성하기 = 155	
 현황판에 태스크 붙이기	= 156
 태스크상의 일 시작하기	= 158
 태스크는 진행중 영역에 있을 때만 진행되고 있는 겁니다 = 159	
 만약 동시에 두 가지 일을 한다면 어떻게 될까요?	= 160
 첫 번째 스탠드업 미팅... = 163
 태스크 1: Date 클래스 생성하기 = 164
 스탠드 업 미팅: 다섯 번째 날, 첫 주의 마지막... = 170
 스탠드 업 미팅: 두 번째 주, 두 번째 날... = 176
 이번 장의 훼방꾼이 나타났어요 = 180
 계획되지 않은 태스크를 추적해야 합니다 = 181
 계획하지 않은 태스크가 소멸률을 증가시킵니다 = 183
 속도가 도움이 됩니다만... = 184
 할 일이 많이 남았습니다 = 186 
 하지만 우리가 어디에 있는지를 정확히 알고 있습니다 = 187	
 노출된 속도 = 188
5 충분히 구현 가능한 좋은 설계
 iSwoon이 심각한 문제에 빠졌습니다 = 190	
 이 설계는 단일 책임 원리를 따르지 않습니다 = 193	
 설계에서 다중 책임을 갖는 곳 찾기 = 196	
 다중 책임을 단일 책임으로 전환하기 = 199	
 설계는 SRP를 준수해야 합니다. 또 DRY도 준수해야 합니다 = 200	
 리팩토링 후 스탠드업 미팅 = 204	
 계획되지 않은 태스크도 태스크일 뿐입니다 = 206	
 데모 자체도 태스크의 일부입니다 = 207	
 모든 것이 완료되면, 이터레이션은 끝이 납니다 = 210
6 버전 관리
 새로운 계약을 따냈습니다 - 비트박스 프로 = 218
 그리고 계속해서 GUI 작업... = 222
 고객에게 새로운 비트박스 선보이기 = 225
 버전 관리를 시작합시다 = 228
 먼저 여러분의 프로젝트를 설치합니다 = 230
 ...이제 코드를 체크인 또는 체크아웃할 수 있습니다 = 231
 대부분의 버전 관리 도구가 여러분이 직면한 문제를 해결해 줄 것입니다 = 232
 서버는 수정사항을 자동으로 합치려 합니다 = 233 
 버전 관리 소프트웨어가 변경사항을 합칠 수 없으면 충돌이 발생했음을 알립니다 = 234 
 이터레이션이 많아지면 사용자 스토리도 많아집니다 = 238
 우리는 소프트웨어에 대해 하나 이상의 버전을 갖고 있습니다 = 240
 좋은 커밋 메시지는 예전 소프트웨어를 찾기 쉽게 해줍니다 = 242 
 이제 1.0 버전을 체크아웃할 수 있습니다 = 243
 (긴급) 스탠드업 미팅 = 244
 여러분의 버전에 태그를 생성하세요 = 245 
 태그, 브랜치, 트렁크... 아이고! = 247
 1.0 버전 수정하기.. 이번엔 실제 상황입니다 = 248
 이제 두 개의 코드 기반을 갖게 되었습니다 = 249
 언제 브랜치를 사용하면 안될까요? = 252
 브랜치 관리를 잘 하려면 = 252
 버전 관리는 다음과 같은 작업을 수행합니다 = 254 
 버전 관리는 여러분의 코드가 실제로 작동하는지를 보장하지 않습니다 = 255  
 소프트웨어 개발 도구상자 활용하기 = 256
6 1／2 작성한 코드 빌드하기
 개발자는 기억력 좋은 독자가 아닙니다 = 260
 한 번에 프로젝트 빌드하기 = 261
 앤트(Ant): 자바 프로젝트를 위한 빌드 도구 = 262
 프로젝트(proejct), 프로퍼티(property), 타겟(target), 태스크(task) 엘리먼트 = 263
 좋은 빌드 스크립트... = 268
 좋은 빌드 스크립트는 기본 사항 외에 더 많은 것을 수행합니다 = 270
 빌드 스크립트도 코드입니다 = 272
 신입 개발자는 두 가지를 얻었습니다 = 273
 소프트웨어 개발 도구상자 활용하기 = 274
7 테스트와 지속적인 통합
 모든 것은 항상 잘못될 수 있습니다 = 276	
 시스템을 바라보는 시각에는 3가지가 있습니다 = 278	
 블랙박스 테스트는 입출력 값에 집중합니다 = 279	
 그레이박스 테스트는 보다 코드 안쪽을 살펴봅니다 = 280	
 화이트박스 테스트는 구현코드 내부를 확인합니다 = 283
 한 번에 모든 것을 테스트하기 = 288	
 테스트 프레임워크에서 테스트 자동화하기 = 290	
 프레임워크를 사용하여 테스트 실행하기 = 291
 크루즈컨트롤(Cruise Control)의 CI 사이클 = 294	
 테스트는 코드가 정상적으로 작동하는 것을 보장합니다 맞나요? = 296
 모든 코드를 테스트한다는 것은 모든 분기문을 테스트한다는 의미입니다 = 304	
 무엇이 테스트되었는지 알기 위해서 커버리지 리포트를 사용하세요 = 305	
 높은 커버리지률을 갖는 것이 항상 쉬운 것은 아닙니다 = 307	
 소프트웨어 개발 도구상자 활용하기 = 314
8 테스트 주도 개발 
 테스트는 나중에 하는 것이 아니고 처음부터 하는 것입니다 = 316	
 그래서 처음부터 테스트를 수행할 예정입니다 = 317
 테스트 주도 개발(TDD)에 온 것을 환영합니다 = 317	
 여러분의 첫 번째 테스트... = 318	
 ...끔찍하게 실패한다는 것입니다 = 319	
 테스트를 녹색으로 변경하기 = 320	
 적색, 녹색 그리고 리팩토링... = 321	
 TDD에서 테스트는 여러분의 개발을 이끌어 줍니다	= 326
 테스크를 완료했다는 것은 필요한 모든 테스트를 했고 모두 통과했다는 의미입니다 = 328
 테스트를 통과하면 바로 다음으로 넘어가세요! = 329
 간결함이란 의존성을 최대한 제거하는 것입니다 = 333
 항상 테스트 가능한 코드를 작성하세요 = 334	
 테스트 하기 어려우며 설계내용을 살펴보세요 = 335
 전략 패턴을 이용하면 하나의 인터페이스를 다양하게 구현할 수 있습니다 = 336	
 테스트용 코드는 테스트 클래스에서 관리하세요 = 339	
 테스트는 더 나은 코드를 만듭니다 = 340	
 테스트가 많아질수록 코드도 더 늘어납니다 = 342	
 전략 패턴은 결합도를 낮추고, 객체화합니다 = 343	
 다양하지만 유사한 객체가 필요합니다 = 344	
 이미 객체를 생성했다면 어떨까요? = 344	
 목( 객체는 실제 객체를 대체합니다 = 345	
 목 객체는 실제 객체를 대신해서 동작합니다 = 346	
 좋은 소프트웨어는 테스트할 수 있습니다 = 349	
 녹색으로 만들기는 쉬운 일이 아닙니다 = 350	
 테스트 주도 개발자의 하루... = 352	
 소프트웨어 개발 도구상자 활용하기 = 354
9 이터레이션 마무리하기
 이터레이션이 이제 막 완성되려고 합니다... = 358	
 ...그러나 여러분이 할 수 있는 것이 많이 남았습니다 = 359	
 시스템 테스트는 반드시 해야 합니다 = 364
 ...그런데 누가 시스템 테스트를 하죠? = 365
 시스템 테스트는 테스트할 완전한 시스템이 있어야 합니다 = 366
 좋은 시스템 테스트는 두 개의 이터레이션 사이클이 필요합니다 = 367	
 이터레이션이 많을수록 문제도 많습니다 = 368	
 효과적인 시스템 테스트의 특징 Top 10 = 373
 버그의 일생(그리고 죽음) = 374	
 버그를 발견했다면... = 376	
 버그 보고서의 해부 = 377	
 아직 할 수 있는 일이 많이 남아있습니다 = 378
 이터레이션 리뷰를 진행할 시간입니다 = 382
 이터레이션 리뷰에 대한 질문들 = 383
 부가적인 일들을 위한 일반적인 우선순위 목록 = 384
 소프트웨어 개발 도구상자 활용하기 = 386
10 다음 이터레이션
 작동하는 소프트웨어란 무엇인가? = 390	
 다음 이터레이션의 계획이 필요합니다 = 392	
 속도는...프로젝트 현실을 반영합니다 = 399	
 고객에 대한 이야기를 계속해 봅시다 = 400	
 다른 사람의 소프트웨어도 그저 소프트웨어일 뿐입니다 = 402
 고객 승인? 확인해보죠! = 405	
 테스트하기 = 410	
 태권브이, 우리 문제가 생겼어요 = 411
 아무도 믿지 마세요 = 413	
 누가 코드를 작성했는지는 중요하지 않습니다 만약 그것이 여러분의 소프트웨어라면 여러분에게 책임이 있습니다 = 413
 프로세스를 갖추지 못한 경우 = 418	
 프로세스를 갖춘 경우 = 419
11 버그
 먼저 고객에게 이야기해야 합니다 = 426	
 우선순위 1: 코드가 빌드되도록 하라 = 432	
 코드를 고칠 수야 있지만... = 434	
 ...하지만 기능을 수정해야 합니다 = 435	
 어떤 기능이 동작하는지 알아보기 = 436
 이제 여러분은 무엇이 동작안하는지 알고 있습니다 = 439	
 무엇을 하시겠습니까? = 439	
 추정을 위한 스파이크 테스트 = 440	
 스파이크 테스트의 결과가 의미하는 바는 무엇일까요? = 442	
 팀원들이 실제로 느끼는 것이 중요합니다 = 444
 고객에게 버그 수정에 대해 추정한 내용을 전해주세요 = 446	
 잘 되어가는 것처럼 보입니다 = 450	
 ...그리고 여러분은 성공적으로 이터레이션을 마쳤습니다! = 451
 그리고 가장 중요하게도 고객이 행복해 하네요 = 452	
 소프트웨어 개발 도구상자 활용하기 = 454
12 실제 세계
 소프트웨어 개발 프로세스 명확히 하기 = 458
 좋은 프로세스가 좋은 소프트웨어를 만듭니다 = 459	
 형식을 갖춘 복장이 필요합니다 = 464
 더 살펴보아야 할 것들... = 466 
 더 많은 지식＝＝더 좋은 프로세스 = 467	
 소프트웨어 개발 도구상자 활용하기 = 468
부록1: 남은 것들 
 1. UML 클래스 다이어그램 = 474
 2. 시퀀스 다이어그램 = 476
 3. 사용자 스토리와 유스케이스 = 478
 4. 시스템 테스트 vs. 단위 테스트 = 480
 5. 리팩토링 = 418
부록2: 기법과 원칙
 개발 기법 = 484
 개발 원칙 = 486