이미 소장하고 있다면 판매해 보세요.
- 해외배송 가능?
- 문화비소득공제 가능
이 분야의 이벤트
책소개
목차
|
『지속적인 통합』
PART I 지속적 통합의 배경: 원칙과 실천 방법 chapter1 시작하기 변경할 때마다 소프트웨어를 빌드하기 개발자 버전 관리 저장소 지속적인 통합 서버 빌드 스크립트 피드백 메커니즘 통합 빌드 머신 지속적인 통합의 특징 소스 코드 컴파일 데이터베이스 통합 테스트 검사 (Inspection) 배포 문서와 피드백 요약 질문 chapter2 지속적인 통합 도입하기 지속적인 통합과 함께 하는 하루 일과 지속적인 통합에는 어떤 가치가 있을까요? 위험을 줄여줍니다 반복적인 프로세스를 줄여줍니다 배포할 수 있는 소프트웨어를 생성합니다 프로젝트 가시성을 더 높입니다 제품에 대해 보다 큰 자신감을 갖게 됩니다 지속적인 통합을 왜 도입하지 못할까요? '지속적인' 통합을 도입하려면 어떻게 해야 할까요? 언제, 어떻게 프로젝트에 지속적인 통합을 도입해야 할까요? 통합의 진화 지속적인 통합은 다른 개발 실천 방법을 어떻게 보완할까요? 지속적인 통합을 수립하려면 얼마나 걸릴까요? 지속적인 통합과 나 코드를 자주 커밋하세요 깨진 코드를 커밋해선 안 됩니다 빌드가 깨지면 즉시 고치세요 자동화된 개발자 테스트를 작성하세요 테스트와 검사는 모두 통과해야 합니다 개인 빌드를 돌리세요 깨진 코드는 가져오지 마세요 요약 질문 chapter3 지속적인 통합을 이용해 위험 줄이기 위험 요소: 배포 가능한 소프트웨어의 부재 시나리오: "내 컴퓨터에선 되는데요" 시나리오: 데이터베이스와 동기화하기 시나리오: 버튼을 안 눌렀어요 위험 요소: 뒤늦은 결함 발견 시나리오: 회귀 테스트 시나리오: 테스트 적용범위 (Test Coverage, 테스트 커버리지) 위험 요소: 프로젝트 가시성의 부재 시나리오: "제가 남긴 메모 보셨나요?" 시나리오: 소프트웨어를 시각화할 역량의 부재 위험 요소: 저품질의 소프트웨어 시나리오: 코딩 표준 준수 시나리오: 설계 지침 준수 시나리오: 중복 코드 요약 질문 chapter4 변경될 때마다 소프웨어를 빌드하기 빌드를 자동화하기 명령어 하나로 빌드를 수행하기 IDE에서 빌드 스크립트를 분리해내기 소프트웨어 자산을 중앙 집중화하기 일관성 있는 디렉터리 구조를 만들기 빌드를 빨리 실패하게 만들기 어떤 환경에서라도 빌드하기 빌드 유형과 메커니즘 빌드 유형 빌드 메커니즘 빌드 시작시키기 전용 통합 빌드 머신을 사용하기 지속적인 통합 서버를 사용하기 사람이 직접 통합 빌드를 돌리기 빌드 시간을 짧게 만들기 빌드 메트릭 수집하기 빌드 메트릭 분석하기 개선 방안을 고르고 실행하기 빌드를 여러 단계로 나누기 다시 평가하기 이런 게 과연 효과가 있을까요? 요약 질문 PART II 완전한 기능을 갖춘 지속적인 시스템 만들기 chapter5 지속적인 데이터베이스 통합 데이터베이스 통합을 자동화하기 데이터베이스 만들기 데이터베이스 조작하기 빌드 데이터베이스 편성 스크립트 만들기 로컬 데이터베이스 샌드박스를 사용하기 버전 관리 저장소를 사용해서 데이터베이스 자산을 공유하기 지속적인 데이터베이스 통합 개발자에게 데이터베이스를 수정할 권한을 주기 팀이 다 함께 깨진 빌드를 고치는 일에 집중하기 DBA를 개발 팀의 일원으로 만들기 데이터베이스 통합과 통합 버튼 테스트 검사 배포 피드백과 문서화 요약 질문 chapter6 지속적인 테스트 단위 테스트 자동화하기 컴포넌트 테스트 자동화하기 시스템 테스트 자동화하기 기능 테스트 자동화하기 개발자 테스트를 여러 범주로 나누기 시간이 덜 걸리는 테스트부터 실행하기 단위 테스트 컴포넌트 테스트 시스템 테스트 결함 검사용 테스트 작성하기 컴포넌트 테스트를 반복할 수 있게 만들기 테스트 케이스 하나에 어썰트(assert) 하나로 제한하기 요약 질문 chapter7 지속적인 검사 검사와 테스트는 무엇이 다를까요? 검사기를 얼마나 자주 돌려야 할까요? 코드 메트릭: 그 역사 코드 복잡도를 줄이기 설계 검토를 지속적으로 수행하기 코드 심사(Audit)를 하여 조직에서 정한 표준을 잘 지키게 하기 중복 코드를 줄이기 PMD-CPD 사용하기 Simian 사용하기 코드 적용범위를 평가하기 코드 품질을 지속적으로 평가하기 적용범위 테스트 수행 빈도 적용범위 테스트와 성능 요약 질문 chapter8 지속적인 배포 작동하는 소프트웨어를 언제, 어느 곳에서든 릴리즈하기 저장소 안의 자산에 꼬리표 붙이기 깨끗한 환경 만들기 각 빌드에 꼬리표 붙이기 테스트를 모두 돌리기 빌드 피드백 보고서 만들기 릴리즈를 롤백할 수 있는 능력 확보하기 요약 질문 chapter9 지속적인 피드백 적절하게 적절한 정보 적절한 사람 적절한 시기 적절한 방법 지속적인 피드백 메커니즘 사용하기 이메일 SMS (문자 메시지) 앰비언트 오브와 X10 디바이스 윈도우 작업 표시줄 소리 와이드 스크린 모니터 요약 질문 epilogue 지속적인 통합의 미래 appendixA CI 관련 리소스 지속적인 통합 도구와 제품 빌드 스크립트 리소스 버전 관리 리소스 다른 버전 관리 리소스 데이터베이스 리소스 테스트 리소스 자동화된 검사 리소스 배포 리소스 피드백 리소스 문서화 리소스 appendixB CI 도구 평가하기 도구를 평가할 때 고려할 점 기능성 내가 일하는 환경과의 호환성 안정성 수명 사용자 편의성 자동화된 빌드 도구 Ant Maven 1 Maven 2 NAnt Rake 빌드 스케줄러 도구 AnthillPro Continuum CruiseControl CruiseControl.NET Draco.NET Luntbuild 결론 『릴리스 잇』 1장 소개 1.1 올바른 목표를 향해서 1.2 힘을 사용하라 1.3 삶의 질 1.4 도전의 범위 1.5 여기도 백만달러, 저기도 백만달러 1.6 실용주의 아키텍처 1부 안정성(Stability) 2장 항공사를 정지시킨 예외(Exception) 사건 2.1 정지 사태 2.2 결과 2.3 사후검토 2.4 확실한 증거 2.5 약간의 예방? 3장 안정성 소개 3.1 안정성이란? 3.2 고장 유형 3.3 크랙 전파 3.4 고장의 연쇄 3.5 패턴과 안티패턴 4장 안정성 안티패턴 4.1 통합지점 4.2 연쇄 반응 4.3 연속적인 고장 4.4 사용자들 4.5 블록된 스레드 4.6 자기부정 공격 4.7 확장 효과 4.8 불균형 용량 4.9 느린 응답 4.10 SLA 역전 4.11 끝이 없는 쿼리 결과 5장 안정성 패턴 5.1 제한시간을 사용하라 5.2 차단기 5.3 칸막이 5.4 정상 상태 5.5 빠른 고장 5.6 핸드셰이킹 5.7 테스트 하니스 5.8 분리하는 미들웨어 6장 안정성 요약 2부 용량(Capacity) 7장 고객에게 짓밟히다 7.1 카운트다운과 런칭 7.2 QA를 향해 7.3 부하 테스트 7.4 군중에 의한 살인 7.5 테스트와의 차이 7.6 사고 여파 8장 용량 소개하기 8.1 용량 정의하기 8.2 제한조건 8.3 상관관계 8.4 확장성 8.5 용량에 대한 미신 8.6 요약 9장 용량 안티패턴 9.1 리소스 풀 경쟁 9.2 지나친 JSP 프라그먼트 9.3 AJAX 대량살상 9.4 너무 오래 머무는 세션 9.5 HTML 안에 낭비된 공간 9.6 새로고침 버튼 9.7 손으로 만든 SQL 9.8 데이터베이스 부영양화 9.9 통합지점 지연 9.10 쿠키 괴물 9.11 요약 10장 용량 패턴 10.1 풀 연결 10.2 캐싱을 신중하게 사용하자 10.3 콘텐트를 미리 계산해두자 10.4 가비지 콜렉터를 튜닝하자 10.5 요약 3부 일반적인 디자인 이슈 11장 네트워킹 11.1 멀티홈드 서버 11.2 라우팅 11.3 가상IP 주소 12장 보안 12.1 최소 권한의 원칙 12.2 설정된 비밀번호 13장 가용성 13.1 가용성 요구사항 모으기 13.2 가용성 요구사항 문서화 13.3 로드 밸런싱 13.4 클러스터링 14장 관리 14.1 QA가 실전과 일치하나? 14.2 설정 파일 14.3 시작과 종료 14.4 관리자 인터페이스 15장 디자인 요약 4부 운영(Operation) 16장 경이적인 우주의 힘, 하찮은 삶의 터전 16.1 피크 시즌 16.2 아기의 첫 번째 크리스마스 16.3 맥박을 짚다 16.4 추수감사절 16.5 검은 금요일 16.6 바이탈 사인 16.7 진단 테스트 16.8 전문가에게서 호출 16.9 해결책 선택사항을 비교하다 16.10 해결책은 효과가 있었을까? 16.11 진정국면 17장 투명성 17.1 관점 17.2 투명성을 위한 설계 17.3 권능을 부여하는 기술 17.4 로깅 17.5 모니터링 시스템 17.6 법률적이며 사실상의 표준 17.7 운영 데이터베이스 17.8 지원 프로세스 17.9 요약 18장 적응 18.1 시간이 흐르면서 적응하기 18.2 적응 가능한 소프트웨어 설계 18.3 적응 가능한 엔터프라이즈 아키텍처 18.4 릴리스가 고통을 줘서는 안 된다 18.5 요약 |
저자 소개 1
고려대학교 기계공학과를 졸업하였으며 동대학원에서 석사를 마쳤다. 소프트웨어 개발, 프로젝트 관리, 컨설팅의 업무를 수행하고 있다. 관심 분야로는 더 나은 개발 환경 및 직장생활이고, 이에 대한 저작 작업에 주력하고 있다. 현재는 차량용 임베디드 소프트웨어 개발, 컨설팅을 하고 있다. 읽은 것과 생각한 것을 블로그(http://talk-with-hani.com)와 트위터(http://twitter.com/talkwithhani)에 꾸준히 남기려고 노력한다. 저서로는 『시지프스를 다시 생각하다』『겸손한 개발자가 만든 거만한 소프트웨어』『도와주세요! 팀장이 됐어요』 등이 있으며 역서로
고려대학교 기계공학과를 졸업하였으며 동대학원에서 석사를 마쳤다. 소프트웨어 개발, 프로젝트 관리, 컨설팅의 업무를 수행하고 있다. 관심 분야로는 더 나은 개발 환경 및 직장생활이고, 이에 대한 저작 작업에 주력하고 있다. 현재는 차량용 임베디드 소프트웨어 개발, 컨설팅을 하고 있다. 읽은 것과 생각한 것을 블로그(http://talk-with-hani.com)와 트위터(http://twitter.com/talkwithhani)에 꾸준히 남기려고 노력한다. 저서로는 『시지프스를 다시 생각하다』『겸손한 개발자가 만든 거만한 소프트웨어』『도와주세요! 팀장이 됐어요』 등이 있으며 역서로는 『뽀모도로 테크닉』『고약한 문제, 합당한 해결』『Manage it!』『Release it』『애자일 프랙티스』『실천가를 위한 실용주의 프로젝트 관리』『레일스와 함께하는 애자일 웹개발』등이 있다.
신승환의 다른 상품
저자 : 마이클 나이가드
마이클 나이가드(Michael Nygard)는 15년이 넘는 경력의 전문 프로그래머이자 아키텍트다. 그는 미국 정부, 군대를 포함하여 은행, 재정, 농업 그리고 유통업에 시스템을 인도하였다. 마이클은 수많은 기사와 사설을 기고했고 컴덱스에서 연설을 했으며 초창기 자바서적을 공동으로 집필하기도 했다.
저자 : 폴 M. 듀발 외
Paul M. Duvall
컨설팅 회사인 Stelligent 사의 CTO이자, 소프트웨어 생산을 최적화함으로써 개발 팀이 안정적이고 신속하게 더 나은 소프트웨어를 만드는 것을 돕고 있다. 금융, 주택, 정부, 보건, 그리고 큰 규모의 독립적 소프트웨어 벤더를 비롯한 다양한 산업 분야에서 고객들에게 컨설팅을 해왔으며, www.testearly.com와 www.integratebutton.com에서 열심히 블로깅을 하고 있다.
스티브 M. 마티야스 3세 ㅣ Stephen M. Matyas III
5AM Solutions 사의 서비스 부분인 AutomateIt의 부사장이다. 응용 소프트웨어 공학에서 다양한 경력을 가지고 있으며, 엔터프라이즈 자바와 외주 소프트웨어 및 서비스 개발에 관하여 풍부한 실무 경험을 갖추고 있다.
앤드류 글로버 ㅣ Andrew Glover
Stelligent 사의 사장이며 북미지역에서 개최되는 다양한 콘퍼런스에서 연사로 활동 중이다. 여러 권의 책과 온라인 기사를 쓴 저자이자 공저자이기도 하다.
컨설팅 회사인 Stelligent 사의 CTO이자, 소프트웨어 생산을 최적화함으로써 개발 팀이 안정적이고 신속하게 더 나은 소프트웨어를 만드는 것을 돕고 있다. 금융, 주택, 정부, 보건, 그리고 큰 규모의 독립적 소프트웨어 벤더를 비롯한 다양한 산업 분야에서 고객들에게 컨설팅을 해왔으며, www.testearly.com와 www.integratebutton.com에서 열심히 블로깅을 하고 있다.
스티브 M. 마티야스 3세 ㅣ Stephen M. Matyas III
5AM Solutions 사의 서비스 부분인 AutomateIt의 부사장이다. 응용 소프트웨어 공학에서 다양한 경력을 가지고 있으며, 엔터프라이즈 자바와 외주 소프트웨어 및 서비스 개발에 관하여 풍부한 실무 경험을 갖추고 있다.
앤드류 글로버 ㅣ Andrew Glover
Stelligent 사의 사장이며 북미지역에서 개최되는 다양한 콘퍼런스에서 연사로 활동 중이다. 여러 권의 책과 온라인 기사를 쓴 저자이자 공저자이기도 하다.
역자: 최재훈
게임 개발을 업으로 삼는 프로그래머이다. 게임 개발에 있어선 이제 막 반년이 지난 초보이지만, 흥미롭고 생소한 기술을 많이 접하고, 익숙하진 않지만 독특한 분위기를 누리느라 항상 즐겁다. 여전히 스타크래프트는 무한맵에서 하고, 올해에 나올 게임 기대작으론 스포어(Spore)를 손에 꼽는다. 게임 개발자답지 않게 평소엔 게임을 즐겨 하지 않지만, 기대작이 나오면 다른 일은 제쳐놓고 삼매경에 빠진다. 유머 사이트에 떠도는, '슈퍼로봇대전 OGS'의 엔딩을 보고 싶다고 적은 휴가 계획서를 보고 그 용기가 멋지다고 생각하는 사람이다.
락 밴드는 U2가 최고라 생각하고, 15년째 '배철수의 음악 캠프'를 들은 애청자이다. 『Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드』에 이어 이번이 두 번째 역서이다. 번역을 마치고 몇 번이나 검토를 해도, 여전히 고칠 부분이 많아 부끄럽다. 그저 전작 때보단 좀더 제대로 번역했다는 소리를 듣고 싶다. http://kaistizen.net
락 밴드는 U2가 최고라 생각하고, 15년째 '배철수의 음악 캠프'를 들은 애청자이다. 『Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드』에 이어 이번이 두 번째 역서이다. 번역을 마치고 몇 번이나 검토를 해도, 여전히 고칠 부분이 많아 부끄럽다. 그저 전작 때보단 좀더 제대로 번역했다는 소리를 듣고 싶다. http://kaistizen.net
역자: 정태중
고려대학교 기계공학과와 동대학원을 졸업하였고, 현재 LG전자 생산연구원에 근무하면서 자동화 장비 프로그램과 비전 알고리즘 개발 업무를 수행하고 있다. 공역한 책으로 『실천가를 위한 실용주의 프로젝트 관리』(위키북스), 『애자일 프랙티스』(인사이트)가 있다.
품목정보
- 발행일
- 2009년 09월 03일
- 쪽수, 무게, 크기
- 776쪽 | 1578g | 172*235*60mm
- ISBN13
- 9788992939355
책 속으로
|
소프트웨어 업계에서 근무한 지 얼마 되지 않았을 무렵엔 개별적으론 잘 동작하던 모듈도 한데 모으면, 도대체가 이해하기조차 어려운 형태로 모든 게 엉망이 되어 버리곤 했습니다. 하지만 지난 몇 년간, 통합은 프로젝트에서 가장 고생스러운 일에서 별 것 아닌 일로 축소되었습니다.
이렇게 된 가장 근본적인 원인은 좀더 자주 통합하는 실천 방법입니다. 한때는 매일 빌드하는 것을 야심 찬 목표로 생각한 적도 있었습니다. 지금 이야기하는 대부분의 프로젝트들은 하루에도 여러 차례 통합을 합니다. 참 이상하게도, 고생스러울수록 좀더 자주하는 것이 상책인 듯합니다. 지속적인 통합에 있어 흥미로운 것 중 하나는 지속적인 통합이 주는 효과에 사람들이 종종 놀란다는 겁니다. 우리는 사람들이 지속적인 통합의 효과를 별로 중요하지 않은 이점으로 치부해버리는 모습을 발견합니다. 하지만 지속적인 통합은 프로젝트에 완전히 다른 분위기를 불러일으킬 수 있습니다. 문제를 더 빨리 탐지해내기 때문에 가시성이 훨씬 좋아집니다. 잘못을 저지르고 그것을 발견해내는 간격이 줄기 때문에, 뭐가 변경됐는지 쉽게 살펴볼 수 있어서 원인을 찾아내는 데 도움이 되므로 결함을 찾아내기 더 쉽습니다. 이것이 테스트 프로그램과 결합하면, 버그를 획기적으로 줄일 수 있습니다. 그 결과, 개발자는 디버깅하는 데 시간을 덜 쓰고 기능을 넣는 데 시간을 더 쓰게 되며, 견고한 기초를 닦고 있다는 자신감을 갖게 됩니다. 물론, 통합을 더 자주하라고 말로만 해선 충분하지 않습니다. 이 간단한 캐치프레이즈 뒤에는 지속적인 통합을 현실로 만들어 주는 원칙과 실천 방법이 한 다발 있습니다. 원칙과 실천 방법에 관한 조언들은 대부분 여러 책과 인터넷에 흩어져 있었기 때문에 스스로 찾아서 탐구해야 했습니다. 그래서 폴이 이러한 정보들과 최고의 실천 방법들을 응집력 있는 한 권의 책으로 묶어서 이러한 책을 기다렸던 사람들에게 지침서를 만들어준 걸 보고 기뻤습니다. 간단한 실천 방법이 으레 그렇듯, 세세한 부분으로 들어가면 어려워집니다. 지난 몇 해에 걸쳐 우리는 그 같은 세부 사항에 대해 많은 것을 연구했고 어찌 대처하면 되는지를 공부했습니다. 이 책은 지속적인 통합이 소프트웨어 개발에 탄탄한 기초를 제공하듯, 지속적인 통합을 위한 탄탄한 기초를 마련해주는 이러한 교훈들을 모아 놓았습니다. --- '본문' 중에서 여러분이 프로젝트에 공을 들인 지 1년이 넘었다. 드디어, 모든 기능들이 실제로 완성된 것처럼 보이고, 대부분의 기능들을 위한 단위 테스트도 있다. 안도의 한숨을 쉬어도 좋다. 일은 끝났다. 정말 그럴까? '기능이 완성되었다는 것'이 '제품을 출시할 준비가 되었음'을 뜻할까? 여러분의 시스템은 정말로 배치될 준비가 됐는가? 여러분이 없더라도, 시스템은 운영요원에 의해 잘 돌아가고 실제 사용자들과 부딪히는데 문제가 없겠는가? 한밤중에 비상 전화나 호출기가 울린다면 수렁에 빠지는 기분이 들지 않을까? 결국 지금까지 구현된 모든 기능보다 앞으로 개발할 것이 훨씬 많다는 사실을 알게 된다. 너무나 자주, 프로젝트 팀은 실전에서 (정말로 원활한) 운영을 목표로 삼는 대신, QA 테스트 통과를 목표로 삼는다. 즉, 여러분이 하는 많은 일들은 십중팔구 테스트 통과에 초점을 맞춘다. 그러나 테스트만으로(애자일 테스트, 실용주의 테스트, 자동화된 테스트일지라도) 소프트웨어가 실제 세상에 나갈 준비가 되었다는 것을 증명하는 데는 충분하지 않다. 유별난 실제 사용자, 엄청난 트래픽, 들어보지도 못한 나라의 바이러스를 만드는 일당으로 가득한 실제 세상의 스트레스와 스트레인(strain)은, 우리가 테스트의 대상으로 삼았던 것들을 훌쩍 뛰어넘는다. 여러분의 소프트웨어가 실제 세상의 가혹한 현실에 맞설 준비가 되었는지 확인해야 한다. 이 책의 목적은 이러한 문제들이 어디에 있는지, 문제들을 극복하려면 무엇이 필요한지 보여주는 데 있다. 그러나 시작하기 전에, 널리 알려진 몇 가지 오해에 대해 얘기해 보자. 우선, 온갖 노력을 다해 계획했어도, 나쁜 일들은 여전히 생긴다는 사실을 받아들여야 한다. 물론 가능하다면 나쁜 일을 예방하는 것이 현명하다. 그러나 가능한 모든 나쁜 사건들을 예측하여 제거했다고 가정하는 것은 너무나 치명적이다. 대신에, 여러분은 가능한 조치를 취하고 예방할 수 있기를 바라야 하지만, 예상치 못한 심각한 트라우마가 시스템에 생기더라도 전체 시스템이 복구될 수 있다고 확신해야 한다. 둘째로, '릴리스 1.0(Release 1.0)'은 개발 프로젝트의 끝이 아니라 시스템의 삶이 시작되는 것임을 깨달아야 한다. 이런 상황은 부모가 다 자란 자녀를 처음으로 떠나 보내는 것과 비슷하다. ?러분은 성인 자녀가 돌아와 여러분과 함께 지내길 바라지 않을 것이다. 더구나 배우자, 손자 네 명, 개 두 마리 그리고 애완용 앵무새와 함께라면 말이다. 이처럼, 개발하는 동안 여러분이 내리는 설계 결정은 릴리스 1.0 이후에 펼쳐질 여러분 삶의 질에 큰 영향을 미칠 것이다. 실전 환경에 맞도록 시스템을 설계하는 데 실패한다면, 릴리스 이후 여러분의 삶은 '흥분'으로 채워질 것이다. 물론 좋은 의미의 흥분이 아니다. 이 책에서, 중요한 설계 트레이드오프(trade-off)를 살펴보고, 어떻게 영리하게 설계 트레이드오프를 결정하는지 알게 될 것이다. 그리고 마지막으로, 기술에 대한 우리들의 공동체적인 애착과 멋진 신기술, 근사한 시스템에도 불구하고, 여러분은 결국 이러한 기술들이 전혀 중요하지 않다는 사실과 마주쳐야 한다. 우리에게 일용할 양식을 주는 세계, 즉 비즈니스 세상에서 모든 것은 돈으로 귀착되기 때문이다. 시스템은 비용을 지출한다. 이 비용을 만회하기 위해 시스템은 직접적인 수익이나 비용을 절약하는 방법으로 돈을 벌어야 한다. 추가 작업은 비용을 지출하며 서비스 중단을 일으킨다. 자금과 운영 비용을 높이기 때문에 비효율적인 코드는 많은 돈을 지출케 한다. 여러분은 운영되고 있는 시스템을 이해하기 위해 이런 비용을 추적해야 한다. 그리고 여러분은 사업을 유지하기 위해 돈을 벌어야 한다. 아니면 적어도 잃지는 말아야 한다. 나는 이 책이 변화를 만들어서 여러분과 여러분의 조직이 거대한 손실과 일반적으로 엔터프라이즈 소프트웨어의 특성으로 표현되는 돈 낭비를 피하는 것을 도울 수 있기를 바란다. --- '본문' 중에서 |
리뷰/한줄평0
상품정보안내
세트도서는 개별서지정보를 모두 제공하지 못하는 경우가 있습니다. 각 권의 상세페이지도 참고해 주세요.
