책 을 읽음으로서 , 고액의 컨설팅을 받고 있다라는 느낌을 받을 수 있는 책 입니다.
개발 실무에서 발생하는 굵직하지만, 모든 개발팀의 과제를 현실 예시와 함께 해결책을 모색해 나가고, 소트웍스에서 구축한 체계에 대해 조언해 줍니다.
물론, 급변하는 개발 세계이기 때문에 해결책이 맞느냐에 대해 논란의 여지가 있을 수도 있음을 저자들은 인정을 하고, 그런 논쟁 속에서 더욱 나은 해결책을 찾을 수 있었고, 그것이 소트웍스의 일하는 방식이라고 말하고 잇습니다.
1장에서 14장까지 그동안의 마틴 파울러의 스타일 처럼 간결하면서도 실무적인 내용을 에세이 형식으로 그려내고 있습니다.
![]() |
소트웍스 앤솔러지 : 소프트웨어 기술과 혁신에 관한 에세이 - ![]() 마틴 파울러 외 지음, 강규영 외 옮김/위키북스 |
목차 및 챕터 설명
1 들어가는 말
2 비즈니스 소프트웨어의 '마지막 한 단계' 해결하기
2.1 '마지막 한 단계' 문제의 원인
2.2 문제 이해하기
2.3 '마지막 한 단계' 문제 해결하기
2.4 사람
2.5 자동화
2.6 비기능적 요구사항을 위한 자동화된 테스트 설계하기
2.7 실제 업무 환경에 대한 의존성 제거하기
2.8 버전 없는 소프트웨어
마지막 한단계 문제는 개발과 테스트를 완료 후 실 비지니스에 반영하기 또는 반영되었는데 그 효과가 없는 문제에 관한 것입니다. 저자는 개발하기 까지 어려운 관문을 지나왔음에도 마지막 한단계가 해결하기 쉽지 않은 문제라는 것을 인식하고 , 해결 방법을 모색하는 내용입니다.
3 악당 소굴과 20개의 루비 DSL
3.1 악당 소굴 예제
3.2 전역 함수를 사용하는 방법
3.3 객체를 사용하는 방법
3.4 클로저를 사용하는 방법
3.5 평가 맥락Evaluation Context
3.6 리터럴 컬렉션
3.7 동적 수신Dynamic Reception
3.8 마무리
우리가 007과 같은 영화를 보면 영웅과 대치하는 악당은 시대를 뛰어넘은 기술과 각종 첨단 장비로 악행을 저지르는데 , 우리의 영웅은 악당 소굴에 침투하여 각종 장비를 망가트립니다. 악당들은 돈도 많을 뿐더러 매번 장비가 망가지니 매우 큰 시장이 될 것이라고 가정하고, 악당소굴에서 필요한 소프트웨어를 개발 하는 것을 가정하여 에세이를 이끌어 갑니다. 구조적인 프로그래밍 과 객체지향적인 프로그램과 언어의 특성, 한마디로 '프로그래밍언어론'을 에세이 형식을 빌어서 친숙하게 써내려 갑니다. Ruby를 이용하여 Domain Specific Language의 구현사례로 설명합니다.
4 프로그래밍 언어의 울창한 숲
4.1 서론
4.2 표본 언어
4.3 다양한 변이들
4.4 언어의 생명수
4.5 흥미롭기는 하지만 왜 이런 것을 알아야 하나?
다양한 개발언어들(C , C++, 포트란, 자바, C#, LISP, etc)을 언어의 범주 (정적/동적 언어, 명령형/절차형/함수형)등의 개념과 차이점을 나누는데 , 식물의 범주를 나누는 방식을 은유하여 기술 합니다.
5 다언어 프로그래밍
5.1 다언어 프로그래밍
5.2 그루비Groovy 방식으로 파일 읽기
5.3 JRuby와 isBlank
5.4 자스켈Jaskell과 함수형 언어
5.5 자바 테스트하기
5.6 다언어 프로그래밍의 미래
자바 또는 C#등은 Virtual Machine으로 인하여 동일한 플렛폼에 다양한 언어로 프로그래밍을 할 수 있는데 도대체 어떤 경우에 다언어로 프로그래밍 하는지, 언어의 우위가 있는지에 대한 에세이 입니다.
6 객체 미용 체조
6.1 오늘날 더 나은 소프트웨어를 향한 9단계
6.2 훈련
6.3 결론
객체 지향언어로 개발을 하더라도 , 절차적인 습성이 베어서 그 장점을 이루지 못하는 경우가 실세계에는 많습니다. 좀더 객체지향적으로 프로그램할 수 있도록 개발 전에 '객체미용체조'를 함으로써 장점을 살리자는 에세이 입니다.
7 반복 관리자란 무엇인가?
7.1 반복 관리자란 무엇인가?
7.2 무엇이 좋은 반복 관리자를 만드는가?
7.3 반복 관리자 역할이 아닌 것
7.4 반복 관리자와 팀
7.5 반복 관리자와 고객
7.6 반복 관리자와 반복
7.7 반복 관리자와 프로젝트
7.8 결론
개발 조직에서 PM과 실무 개발자 사이에 반복관리자를 두어서 , 프로젝트를 부드럽게 완성 시키는 것에 대해서 역설 하는 내용으로 , 아마도 소트웍스의 컨설턴트가 계약된 IT회사의 반복 관리자의 역활을 하겠죠, 역활과 영역에 관한 에세이 입니다.
8 프로젝트의 활력 징후
8.1 프로젝트 활력징후
8.2 프로젝트의 활력징후 vs 프로젝트의 건강
8.3 프로젝트 활력 징후 vs 정보방열기
8.4 프로젝트 활력 징후 : 범위 소모
8.5 프로젝트 활력
8.6 프로젝트 활력징후 : 예산 소모
8.7 프로젝트 활력징후 : 현재 구현 상태
8.8 프로젝트 활력 징후 : 팀 인지
지난한 개발 일정에 의해 지친 프로젝트 팀이 활력을 가지려면 어떤 일을 해야 하는지에 대한 소트웍스의 관점에 대해 적은 에세이 입니다.
9 소비자 주도 계약: 서비스 진화 패턴
9.1 서비스의 진화: 예제
9.2 스키마 버전 관리
9.3 문제적 변경
9.4 소비자 주도 계약
서비스의 최종 소비자인 소비자의 요구사항 주도로 개발 하는 것 (보통 SOA에서 Contract First와 일맥 상통합니다.)을 다룬 에세이 입니다.
10 도메인 어노테이션
10.1 어노테이션을 만난 도메인 주도 설계
10.2 사례 연구 : 르로이의 화물차
10.3 정리
실 개발 세계에서 , 대부분의 개발이 Domain specific 한 영역에 관심을 둔다는 것을 인지하고, 도메인에 대한 어노테이션이 왜 필요하게 되었는가, 필요하다면 어떻게 구현해야 하나에 관한 에세이 입니다.
11 Ant 빌드 파일 리팩터링하기
11.1 개론
11.2 Ant 리팩터링 일람표
11.3 요약
11.4 참고 문헌
11.5 리소스
12 한방에 소프트웨어 출시하기
12.1 지속적인 빌드
12.2 지속적인 빌드를 넘어서
12.3 지속적인 통합의 전체 생명주기
12.4 체크인 관문
12.5 인수 테스트 관문
12.6 배포 준비하기
12.7 후속 테스트 단계들
12.8 프로세스 자동화하기
12.9 결론
개발팀의 심장 박동이라고 할 수 있는 지속적인 빌드(Continous Build)와 지속적인 통합(Continous Integrate)를 이루어서 소프트웨어를 한방에 출시 할 수 있는 방법을 모색하는 에세이, 개발자들이 개발하고 나서 배포전에 겪는 배포의 두려움(배포 했을 때 문제가 발생 할 지도 모른 다는 불안감)을 지속적인 빌드와 지속적인 통합으로 극복해 나가는 에세이
13 엔터프라이즈 웹 애플리케이션 테스트: 애자일 대 폭포수
13.1 개론
13.2 테스팅 생명 주기
13.3 테스팅의 종류
13.4 테스트 환경
13.5 이슈 관리
13.6 도구들
13.7 보고와 측정
13.8 테스팅 역할들
13.9 참고자료
웹어플리케이션을 테스팅 하는 방법으로 애자일 과 폭포수의 유사점과 차이점, 테스팅 방법에 관한 에세이
14 실용적인 성능 테스팅
14.1 성능 테스팅이란 무엇인가?
14.2 요구사항 수집
14.3 테스트 수행하기
14.4 의사소통
14.5 프로세스
14.6 요약
'교양서' 카테고리의 다른 글
| Clean Code - A Handbook of Agile Software Craftsmanship (3) | 2009/04/03 |
|---|---|
| 구텐베르크 은하계(부제-활자인간의 형성) - 웹2.0 과 웹3.0의 미래 (3) | 2009/03/29 |
| 소트웍스 앤솔러지 (The ThoughtWorks Anthology) - 소프트웨어 기술과 혁신에 관한 에세이 (1) | 2009/03/13 |
| 개발자 기획자가 꼭 읽어야 할 책 - 미디어의 이해 (0) | 2009/03/10 |
| 엔터프라이즈 애플리케이션 아키텍처 패턴 (0) | 2008/12/03 |
| 켄트 벡의 구현 패턴 (Implementation Patterns) (0) | 2008/11/30 |








