책소개 책소개 보이기/감추기

『소프트웨어 아키텍트가 알아야 할 97가지』 소프트웨어 아키텍트로서 성공하려면, 비즈니스와 기술을 모두 익힐 필요가 있다. 이 책은 소프트웨어 아키텍트들이 무엇을 중요하게 생각하고, 어떻게 프로젝트를 접근하는지를 알려 준다. 48명 이상의 저자들 모두 아무런 보상없이 소프트웨어 아키텍처에 대한 자신들의 생각과 충고를 제공했다. 어떤 측면에서 진정한 의미의 오픈 소스 서적이다. 개인의 지식이나 지혜보다, 코드로 공헌하는 오픈 소스 소프트웨어 프로젝트와 크게 다를 바가 없다. 『프로젝트 관리자가 알아야 할 97가지』 성공적인 프로젝트를 위한 관리자의 역할! 숙련된 관리자들이 전하는 104개의 노하우 예산에서부터 조직 관리까지 이르는 다양한 주제의 참신한 해법을 한 권으로 만날 수 있다. 지금 맡고 있는 프로젝트가 원하는 대로 매끄럽게 진행되고 있지 않다면, ‘프로젝트 관리자가 알아야 할 97가지’를 통해 수많은 시행착오로 얻은 값진 노하우를 전수받을 수 있다. IT 영역을 넘어 전세계에서 가장 경험이 많은 프로젝트 관리자들과 소프트웨어 개발자들이 이야기한, 97가지의 실용적인 내용을 담고 있다. 『프로그래머가 알아야 할 97가지』 이 땅의 모든 프로그래머에게 전하는 현장의 지혜를 담은 107가지 의미있는 이야기 이 책은 다양한 프로그래머들의 지혜와 경험의 목소리를 담았다. 모든 프로그래머가 알아야 하는 것의 큰 그림으로서 크라우드 소싱 모자이크로 구성된 내용에서는 코드에 대한 조언에서 문화까지, 알고리즘의 사용에서 애자일적 생각까지, 구현 노하우에서 전문성까지, 그리고 스타일에서 본질까지 다룬다. 세트 구성 : 전3권 『소프트웨어 아키텍트가 알아야 할 97가지』 『프로젝트 관리자가 알아야 할 97가지』 『프로그래머가 알아야 할 97가지』 ※ 구매 후 비닐 포장을 뜯으셨을 경우에는 반품이 불가합니다. (파본 및 배송 중 파손의 경우 제외)

더보기

목차 목차 보이기/감추기

『소프트웨어 아키텍트가 알아야 할 97가지』 고객의 요구사항보다 여러분의 이력에 더 우선순위를 두지 말라 Nitin Borwankar 본질적인 복잡성을 단순화시키고 예상치 못한 복잡성을 줄여라 Neal Ford 가장 큰 문제는 기술이 아니다 Mark Ramm 소통이 왕이라면, 명확성과 리더십은 그의 신하이다 Mark Richards 애플리케이션 아키텍처는 애플리케이션 성능을 결정한다 Randy Stafford 요구된 기능에서 가치 추구하기 Einar Landre 일어서라 Udi Dahan 모든 것은 궁극적으로 실패하게 된다 Michael Nygard 여러분은 생각보다 더 자주 협상한다 Michael Nygard 정량화시켜라 Keith Braithwaite 한 줄의 실행되는 코드가 500줄의 명세(스펙)만한 가치를 한다 Allison Randal 한번에 딱 맞는 해결책은 없다 Randy Stafford 성능은 조기에 고려해야 한다 Rebecca Parsons 아키텍팅이란 균형에 관한 것이다 Randy Stafford 커밋하고 도망가는 것은 범죄다 Niclas Nilsson 한 가지 이상의 방식이 존재할 수 있다 Keith Braithwaite 비즈니스 추진력 Dave Muirhead 일반화 이전에 단순화, 재사용성 이전에 사용성`Kevlin Henney 아키텍트는 직접 실무를 담당해야 한다 John Davies 지속적으로 통합하라 David Bartlett 일정을 지켜라 Norman Carnovale 아키텍처적인 트레이드오프를 고려하라 Mark Richards 요새 같은 데이터베이스를 구축하라 Dan Chak 설계의 기준으로써 불확실성을 사용하라 Kevlin Henney 주의 : 거울로 보이는 문제는 보이는 것보다 클 수 있다 Dave Quick 재사용은 단지 아키텍처뿐 아니라 사람과 교육에 관한 것이다 Jeremy Meyer Architecture에 I는 없다 Dave Quick 1000피트의 뷰를 가져라 Erik Doernenburg 결정하기 전에 시도하라 Erik Doernenburg 비즈니스 도메인 이해하기 Mark Richards 프로그래밍은 새로운 제품을 설계하는 행위와 같다 Einar Landre 개발자에게 자율성을 부여하라 Philip Nelson 시간은 모든 것을 바꾼다 Philip Nelson 소프트웨어 아키텍트는 단지 소문자 a를 나타낸다. 소문자 a처럼 행동하라 Barry Hawkins 범위는 성공의 적이다 Dave Quick 쇼맨십을 넘는 가치 있는 청지기 정신 Barry Hawkins 소프트웨어 아키텍처에도 윤리가 있다 Michael Nygard 마천루는 확장할 수 없다 Michael Nygard 이질성의 승리 Edward Garson 모든 것은 성능에 관한 것이다 Craig Russell 백지 위에 아키텍트 Michael Nygard 정황이 왕이다 Edward Garson 드워프, 엘프, 마법사, 그리고 왕 Evan Cofsky 건축물을 짓는 건축가에게 배워라 Keith Braithwaite 반복 작업과 싸워라 Niclas Nilsson 현실 세계에 오신 것을 환영합니다`Gregor Hohpe 제어하지 말아라. 대신 관찰하라 Gregor Hohpe 야누스 아키텍트 David Bartlett 아키텍트의 초점은 경계와 인터페이스에 있다 Einar Landre 개발자에게 권한을… Timothy High 결정에 대한 근거를 남겨라 Timothy High 가정에 도전하라. 특히 여러분이 세운 가정에! Timothy High 경험과 지식을 공유하라 Paul W. Homer 패턴 중독 Chad LaVigne 아키텍처 메타포어를 확대 해석하지 말자 David Ing 운영과 유지 보수에 집중하라 Mncedisi Kasper 두 개를 선택할 마음의 준비를 하라 Bill de hora 견해, 취향보다는 원리, 원칙, 유추를 먼저 고려하라 Michael Harmer 걸어다니는 해골로 시작하라 Clint Shank 데이터가 핵심이다 Paul W. Homer 간단한 것은 간단하게 하라 Chad LaVigne 설계하기 전에, 그것을 먼저 코드화할 수 있어야 한다 Mike Brown ROI 변수 George Malamidis 여러분의 시스템이 레거시인 것을 고려해 설계하라 Dave Anderson 단 하나의 솔루션만 있다면, 다른 의견을 구하라 Timothy High 변화의 충격을 이해하라 Doug Crawford 하드웨어 역시 이해해야 한다 Kamal Wickramanayake 손쉬운 방법은 훗날 이자가 붙어 되돌려 받게 된다 Scot Mcphee 완벽함은 충분함의 적이다 Greg Nyberg ‘좋은 아이디어’를 피하라 Greg Nyberg 훌륭한 콘텐츠는 훌륭한 시스템을 만든다 Zubin Wadia 영업부서와 화가 난 아키텍트의 대결 구도 Chad LaVigne 시스템을 검증하기 위해 범위를 늘려라 Stephen Jones 구현 가능한 것만 설계해야 한다 Mike Brown 장미를 장미라 부르지 않으면, 결국 양배추가 된다 Sam Gardiner 문제가 안정적이어야 높은 품질의 솔루션을 얻을 수 있다 Sam Gardiner 근면성이 필요하다 Brian Hart 자신의 결정에 책임감을 가져라 Yi Zhou 영악하지 말자 Eben Hewitt 주의깊게 무기를 선택하고, 신중하게 내려 놓아라 Chad LaVigne 여러분의 고객은 여러분의 진정한 고객이 아니다 Eben Hewitt 보이는 것처럼 그렇게 되지 않는다 Peter Gillard-Moss 다른 프레임워크와 잘 어울리는 프레임워크를 선택하라 Eric Hawthorne 탄탄한 비즈니스 사례를 만들어라 Yi Zhou 코드뿐만 아니라 데이터도 제어하라 Chad LaVigne 기술 채무를 갚아라 Burkhardt Hufnagel 문제 해결사가 되지 말라 Eben Hewitt 편리한 시스템을 구현하라 Keith Braithwaite 열정적인 문제 해결사들을 찾고 유지하라 Chad LaVigne 소프트웨어는 실제로 존재하지 않는다 Chad LaVigne 새로운 언어를 배워라 Burkhardt Hufnagel 미래를 보장하는 솔루션을 만들 수는 없다 Richard Monson-Haefel 사용자 수용성 문제 Norman Carnovale 맑은 콩소메의 중요성 Eben Hewitt 최종사용자에게는 인터페이스가 시스템이다 Vinayak Hegde 훌륭한 소프트웨어는 만들어지는 것이 아니라 성장하는 것이다 Bill de hora 한국의 아키텍트들 정경유착 김동열 소통하는 아키텍처가 되자 김선형 소프트웨어 아키텍트에게 필요한 세 가지 역량 류한석 불나방과 프로젝트 박현철 컨설팅 그리고 사과 손영수 개발에 있어 형식에 얽매이는 행위야말로 삽질이다 신현묵 ‘공통’은 모든 사람들이 접근하는 광장이다 이충헌 소프트웨어를 넘어 시스템으로, 아키텍처를 넘어 시스템으로 이해일 『프로젝트 관리자가 알아야 할 97가지』 가능한 빨리 사용자를 참여시켜라 바비 데이비스 두더지 게임 방식의 개발을 하지 마라 벤캣 수브라마니암 한 단어로 인해 프로젝트 마감일을 놓칠 수 있다 파벨 심사 프로젝트 후원자 스스로 요구사항을 작성하게끔 하라 미요코 타케야 복잡함보다 간결함을 추구하라 스캇 데이비스 빚을 갚아라 브라이언 슬레튼 팀에 기술이 아닌 재능을 부여하라 리차드 셰리던 간결함을 유지하라 크리슈나 카달리 품질높은 오픈소스나 상용도구를 사용하라 자레드 리차드슨 과거의 경험으로부터 배워라 킴 맥코맥 이슈 해결에 비용을 아껴라 랜디 루미스 훌륭한 IT 개발자를 알아보는 방법 제임스 그래함 개발자 생산성 : 숙련된 개발자와 평범한 개발자 닐 포드 규모의 중요성 아누팜 쿤두 절차를 문서로 만들고, 이를 꼭 따르게 하라 몬테 데이비스 당장 그러한 기법은 그만두고 나아가라 나레쉬 자인 요구사항 명세서의 모순 알랜 그린블랫 성공은 항상 비즈니스 가치로 결정된다 바비 데이비스 프로젝트를 위해 휴가를 빼먹지 마라 조 제네비치 집중할 수 있는 정해진 시간을 보장하라 제임스 레이 프로젝트 관리는 곧 문제 관리다 로린 웅거 개발자에게 권한을 위임하라 : 팀이라 불렸던 남자 켄 사이프 기발한 코드는 유지보수하기 어렵다 데이비드 우드 IT 프로젝트 관리의 인적 요소 관리 제임스 그래함 위키를 활용하라 아드리안 위블 잃어버린 연결 고리 폴 와거너 추정하고, 추정하고, 추정하라 리차드 셰리던 개발자들의 일체화 - PMO가 선두에 선다 안젤로 발레 노력만이 아닌, 결과에도 가치를 두어라 벤캣 수브라마니암 소프트웨어 실패는 조직의 실패이다 브라이언 슬레튼 과도한 자동화에 대한 고객의 목소리 마티 스코멀 자신의 시각을 유지하라 제임스 그래함 ‘완료’단계를 어떻게 정의할 것인가? 브라이언 샘-보덴 60/60 법칙 데이비드 우드 우리가 만난 적은 바로 우리였다 바비 데이비스 주기적으로 작업하라 제임스 레이 여러분 자신에게 충실하라 해리 터커 회의는 코드를 만들지 않는다 윌리엄 J. 밀스 변화 곡선을 그려라 캐시 맥도걸 IT 프로그램 관리 : 비전 공유 데이비드 디아즈 카스틸로 현실적인 계획 수립 크레이그 레타벡 완벽한 실행에 대한 허구 데이비드 우드 더 민첩한 소통 체계를 도입하라 브라이언 샘-보덴 방법론에 목숨걸지 마라 파비오 텍세이라 데 멜로 사람 이슈에 스프레드시트를 사용하지 마라 아누팜 쿤두 한 산출물에는 오직 한 사람에게만 알랜 그린블랫 완벽한 지식에 대한 허구 데이비드 우드 스프린트가 아니라, 마라톤을 완주하게 팀을 만들어라 나레쉬 자인 프로젝트 관리의 세가지 요소 폴 와거너 로드맵 : 최근에 우리는 무엇을 하였는가? 케시 맥도걸 프로젝트 범위 기술서의 중요성 킴 헬드먼 비전이 기대 결과로 이어지도록 하라 데이비드 디아즈 카스틸로 앨리스는 더 이상 여기 안 산다 바비 데이비스 계약 분쟁을 피하는 방법 조지 젤라버트 측정한 대로 얻는다 나레쉬 제인 NIH 신드롬에 빠지지 말자 폴 기암말보 박사 미루지 말고 지금 당장 하세요 스캇 데이비스 속도가 생명이다, 빠를수록 좋다 맷‘붐’다니엘 팀의 사기 형성 데이비드 복 프로젝트는 팀 협력에 좌우된다 렐리도 바렐라 여러분 팀에 봉사하라 카렌 길리슨 커다란 원구에 대한 허구 데이비드 우드 위기에 대응하기 제임스 그래함 통합 지점을 파악하자 몬테 데이비스 분산 프로젝트에서는 적극적으로 의사소통하라 아누팜 쿤두 결과를 염두에 두고 시작하라 루이스 E. 토레스 명확한 거래는 곧 오랜 친분 관계이다 마테오 베치 최고의 추정자는 그 일을 하는 사람들이다 조 제네비치 소통이 열쇠다 게나디 미로노프 프로젝트는 곧 해결책을 찾는 것이다 신시아 A. 베르그 바보야, 문제는 사람이야 아드리안 위블 문서는 결과가 아니라 수단에 불과하다 패트릭 콰 획득 가치와 개발 속도는 보고서 상에 공존할 수 있을 것인가? 바비 데이비스 범위 변경은 일어나기 마련이다. 이에 익숙해져라 페이벨 심사 상용 소프트웨어 구매 에르나니 마르퀘스 다 실바 프로젝트 스폰서 - 좋거나, 나쁘거나, 이상하거나 호르헤 겔라버트 과소한 공약이냐, 과대한 실천이냐? 조 제네비츠 모든 프로젝트 관리자는 곧 계약 관리자이다 파비오 테세이라 드 멜로 중요하지만 긴급하지 않은 일 알렉스 밀러 프로세스를 가르쳐라 리차드 세리던 프로젝트 진척률에 대한 허구 우디 다한 아무튼, 그들이 듣고 싶은 것이 무엇인가? 마사 레게어 팀 사기에 대한 가치를 인식하라 데이비드 복 프로젝트 기간 내내 모든 이해관계자들을 참여시켜라 루크먼 로월 계획 수립의 가치 데리 심멜 항?‘전달만 하는 사람’이 되지 마라 맷 세코스케 산출물을 효과적으로 관리하라 에르나니 마르퀘스 더 실바 \ 우리는 프로젝트 관리자이지 슈퍼영웅이 아니다 앙기네 J. 쇽-스미스 효과적인 회의를 해서 소통을 늘려라 리차드 셰리던 프로젝트 관리를 단순화시키기 위해 유연해져라 크리슈나 카달리 지금으로서는 웹이 곧 길이다 데이비드 우드 개발자는 상황보고를 싫어하고, 관리자는 좋아한다 페이벌 심사 통제하지 말아라 패트릭 콰 비전을 공유하라 자레드 리차드슨 진정한 성공은 지원 조직과 함께 한다 신시아 A. 베르그 프로젝트 관리 거버넌스를 구축하라 에르나니 마르퀘스 더 실바P 당신의 웹사이트를 싫어하는 9.7가지 이유 바비 데이비스 한국의 프로젝트 관리자들 수렵문화와 농경문화 - 당신의 스타일은? 김동열 마음으로 이끄는 힘 손재현 폭포를 떠나 안개고지로... 송태국 ‘`To Do More’보다는‘`To Do Less’를 이충헌 SI 프로젝트에서 관리자의 역할 이희두 훌륭한 소프트웨어보다 사용하는 소프트웨어를 만들어라 임병인 건강한 육체가 프로젝트를 완성한다 진상민 『프로그래머가 알아야 할 97가지』 신중하게 행동하라 Seb Rose 함수형 프로그래밍 법칙을 적용하라 Edward Garson 당신은 사용자가 아니다 Giles Colborne 코딩 표준을 자동화하라 Filip van Laenen 아름다움은 단순함에 있다 Jørn Ølmheim 리팩토링하기 전에 Rajith Attapattu 공용화에 대해 주의하라 Udi Dahan 보이스카웃 규칙 Robert C. Martine(Uncle Bob) 다른 사람을 비난하기 전에 먼저 자신의 코드를 리뷰하라 Allan Kelly 심사숙고해서 도구를 선택하라 Giovanni Asproni 도메인 언어로 코딩하라 Dan North 코드는 설계다 Ryan Brush 코드 레이아웃은 중요하다 Steve Freeman 코드 리뷰 Mattias Karlsson 이치에 맞는 코딩 Yechiel Kimchi 주석에 관한 조언 Cal Evans 단지 코드가 말하지 않는 것을 주석으로 추가하라 Kevlin Henney 끊임없는 배움 Clint Shank 편리함은 명사형이 아니다 Gregor Hohpe 자주 빠르게 릴리즈하라 Steve Berczuk 상황에 맞는 예외처리가 필요하다 Dan Bergh Johnsson 많은 의도적 수련-계획된 연습을 하라 Jon Jagger 도메인에 특화된 언어들 Michael Hunger 부수는 것을 두려워하지 마라 Mike Lewis 테스트 데이터를 속이지 마라 Rod Begbie 에러는 발견 즉시 고쳐라 Pete Goodliffe 언어만 배우지 말고 문화를 배워라 Anders Noras 프로그램을 너무 높은 곳에 매달아 못박지 마라 Verity Stob 기적이 일어난다는 생각을 버려라 Alan Griffiths 중복을 제거하라 Steve Smith 그 코드를 건드리면 안 된다 Cal Evans 상태뿐 아니라 행위까지도 캡슐화하라 Einar Landre 부동소수점 수는 실수가 아니다 Chuck Allison 오픈 소스를 통해 잠자고 있는 열망을 이뤄라 Richard Monson-Haefel API 설계의 황금률 Michael Feathers 구루에 대한 근거 없는 믿음 Ryan Brush 고생은 성과를 내지 못한다 Olve Maudal 버그 트래커를 이용하는 방법 Matt Doar 제거를 통해 코드를 개선하라 Pete Goodliffe 나를 인스톨하라 Marcus Baker 프로세스간 통신은 응용프로그램 반응 시간에 영향을 미친다 Randy Stafford 빌드를 깨끗하게 유지하라 Johannes Broadwall 커맨드라인(command line) 도구 사용법을 알아라 Carroll Robinson 두 개 이상의 프로그래밍 언어를 습득하다 Russel Winder 자신의 통합 개발 환경을 이해하라 Heinz Kabutz 자신의 한계를 알아라 Greg Colvin 다음 커밋을 알아라 Dan Bergh Johnsson 서로 연결된 큰 데이터는 데이터베이스에 속한다 Diomidis Spinellis 다른 세계의 언어를 배워라 Klaus Marquardt 예측하는 것을 배워라 Giovanni Asproni ‘Hello World’를 작성하는 것을 배워라 Thomas Guest 프로젝트가 스스로 말할 수 있게 하라 Daniel Lindner 링커는 마법의 프로그램이 아니다 Walter Bright 임시 솔루션의 장수 Klaus Marquardt 정확한 사용이 쉽고, 잘못된 사용이 어려운 인터페이스를 만들어라 Scott Meyers 보이지 않는 것을 더 잘 보이게 하라 Jon Jagger 병렬 시스템에서 메시지 전달 방식은 더 나은 확장성을 제공한다 Russel Winder 미래로의 메시지 Linda Rising 다형성을 고려하지 않아 놓쳐 버린 기회들 Kirk Pepperdine 이상한 뉴스: 테스터는 여러분의 친구다 Burk Hufnagel 하나의 바이너리 Steve Freeman 오직 코드만이 진실을 말한다 Peter Sommerlad 빌드를 소유하라 (그리고 재작성하라) Steve Berczuk 짝 프로그래밍으로 흐름을 느껴라 Gudny Hauknes, Kari Røssland, Ann Katrin Gagnat 원시 타입보다 도메인에 특화된 타입을 선호하라 Einar Landre 에러를 예방하라 Giles Colborne 프로페셔널 프로그래머 Robert C. Martin(Uncle Bob) 모든 것의 버전을 관리하라 Diomidis Spinellis 마우스를 내려 놓고 키보드에서 떨어져라 Burk Hufnagel 코드를 읽어라 Karianne Berg 인문학을 읽어라 Keith Braithwaite 처음부터 다시 개발하라 Jason P. Sage 싱글톤 패턴의 유혹을 견뎌라 Sam Saariste 좋은 성능에 이르는 길에는 더러운 코드 폭탄이 곳곳에 도사리고 있다 Kirk Pepperdine 단순함은 제거로부터 온다 Paul W. Homer 단일 책임의 원칙 Robert C. Martin(Uncle Bob) “예”로 시작하라 Alex Miller 한 걸음 물러서라. 그리고 자동화, 자동화, 또 자동화를 하라 Cay Horstmann 코드 분석 도구를 활용하라 Sarah Mount 부수적 행위가 아닌, 실제 요구된 행위에 대해 테스트를 수행하라 Kevlin Henney 테스트를 명확하고 구체적으로 작성하라 Kevlin Henney 당신이 자는 동안(그리고 주말 동안) 테스트를 수행하라 Rajith Attapattu 테스팅은 소프트웨어 개발의 엔지니어링 리거다 Neal Ford 상태에 대해 생각하기 Niclas Nilsson 종종 한 사람보다 두 사람이 낫다 Adrian Wible 두 번의 잘못이 옳은 것을 만들 수 있다(그리고 이것은 고치기 어렵다) Allan Kelly 친구들을 위한 우분투 코딩 Aslam Khan 유닉스 도구는 여러분의 친구다 Diomidis Spinellis 올바른 알고리즘과 자료 구조를 사용하라 Jan Christiaan “JC”van Winkel 장황한 로깅은 잠을 방해할 것이다 Johannes Brodwall WET은 성능 병목을 찾기 힘들게 한다 Kirk Pepperdine 프로그래머와 테스터가 협업할 때 Janet Gregory 마치 평생 지원해야 하는 것처럼 코드를 작성하라 Yuriy Zubarev 예를 사용해 작은 함수를 작성하라 Keith Braithwaite 사람들을 위해 테스트를 작성하라 Gerard Meszaros 코드에 주의를 기울여라 Pete Goodliffe 고객이 말한 것과 의도한 것은 다르다 Nate Jackson 한국의 프로그래머들 개발자로 늙고 싶다면 코딩(코더)에서 벗어나라 강승준 과거에서 미래를 찾아라 고재관 훌륭한 소프트웨어를 개발하기 위해 필요한 것들 김병곤 잘못 알려진 디자인 패턴의 두번째 원칙 손영수 좋은 소프트웨어의 개발은 서로를 이해하면서 시작된다 송홍진 개발자 - "?" = 0 유명환 피드백 유석문 너의 언어는 너의 사고의 한계이다 장선진 개발자들이 가져야 할 것들 장회수 공유하고 연대해라 조정현

더보기

저자 소개 관련자료 보이기/감추기

저자 : 리차드 먼슨 해펠

독립 소프트웨어 개발자로, Enterprise Jave Beans의 5판 모두, Java Message Service(O' Relly 출판)의 1, 2판 모두의 공동 저자이다. 그는 현재 멀티 터치 인터페이스 디자이너/개발자이자, 엔터프라이즈 컴퓨팅을 이끌어가는 전문가이다.

저자 : 바비 데이비스

바비 데이비스(MA, PHR, PMP)는 PMI(Project Management Institute)의 Community Post 잡지에 두 달에 한 번 칼럼을 기고한다. 데이비스 컨설팅사에서 교육과 워크샵, 컨설팅 서비스를 제공하고 있다.

저자 : 케블린 헤니

독립 컨설턴트이자 강사. 패턴과 아키텍처, 프로그래밍 기법, 언어, 개발 프로세스와 프랙티스에 관심이 많다. The Register, Better Software, Java Report, CUJ, C Report를 포함하여 다양한 잡지와 온라인 매체의 칼럼니스트이기도 하다.

역자 : EVA

Pattern과 소프트웨어 공학 지식을 외부에 알린다는 의미로 Eva (Evangelism) 라는 이름으로 10년이 넘게 꾸준히 활동하고 있다. 다양한 도메인의 맴버들이 모여, 90개가 넘는 무료 Webcast를 공유, 잡지 기고, 패턴 만들기등 왕성한 활동을 하고 있다. 또한 패턴의 진원지인 PLoP(패턴 학회)에 패턴을 발표한, 패턴 저자들의 모임이다.

역자 : 넥스트리

지난 10여년간 소프트웨어 개발에 있어서 150여 차례의 프로젝트를 수행했다. 매 프로젝트마다 객체지향/컴포넌트/아키텍처 등의 다양한 이슈에 있어서 원칙과 원리를 정확하고 올바로 적용하려고 노력했으며, 그러한 지식을 여러 회사들에게도 교육/컨설팅하고 있다.

역자 : 손영수

소프트웨어 공학과 아키텍팅을 국내 개발자들에게 널리 알리기 위해 노력하고 있는 EVA팀의 한 마리 기러기이다. 국내에 몇 안 되는 패턴 저자이며, 아시아 패턴 학회인 AsianPLoP의 공동 의장이다. 지식 공유를 위해 세미나, 워크숍, 기고 등 왕성한 활동을 하고 있다. 요즘 후배들을 양성하고 있으며, 더 큰 성장을 위해 수련을 하고 있다.

역자 : 김수현

1997년부터 자바의 매력에 빠져 모든 개발을 자바로 하려고 부단히 노력하고 있는 자바사랑 개발자이다. 정적분석 기법으로 아키텍처를 분석/개선하는 업무로 아키텍트의 꿈을 키워가던 도중 오픈 소스의 유혹에 이기지 못하고 오픈소스 컴플라이언스 관련 활동을 진행하고 있다. 현재는 국내 최고의 오픈소스 라이선스 전문가가 되는 것을 최우선의 목표로 하고 있으며 궁극적으로 기업과 오픈커뮤니티 간의 에코시스템 구축을 꿈꾸고 있다.

역자 : 최현미

SW 테스트 기법, 품질평가 모델 개발 등의SW 품질 확보 영역을 시작으로 소프트웨어 공학 분야에 입문하였고, 이후 삼성전자에서 프로세스, 메트릭, 분석/설계 기법 적용(Feature Modeling, QAW, ATAM 등), Reverse Engineering을 통한 소스코드 분석 등 소프트웨어 공학의 다양한 분야에서 멀티플레이어로 활동해왔다. 현재는 이러한 다양한 경험을 바탕으로 삼성전자 산하 해외연구소의 SE조직 컨설팅 및 기술지원 역할을 담당하고 있다.

더보기

발행일	2013년 11월 18일
쪽수, 무게, 크기	796쪽 \| 17623060mm
ISBN13	9788993827712
ISBN10	8993827710

배송 구분	예스24 배송 배송비 : 무료배송
포장 안내	안전하고 정확한 포장을 위해 CCTV를 설치하여 운영하고 있습니다. 고객님께 배송되는 모든 상품을 CCTV로 녹화하고 있으며, 철저한 모니터링을 통해 작업 과정에 문제가 없도록 최선을 다 하겠습니다. 목적 : 안전한 포장 관리 촬영범위 : 박스 포장 작업

반품/교환 방법	고객만족센터(1544-3800), 중고샵(1566-4295) 판매자 배송 상품은 판매자와 반품/교환이 협의된 상품에 한해 가능합니다.
반품/교환 가능기간	출고 완료 후 10일 이내의 주문 상품 디지털 콘텐츠인 eBook의 경우 구매 후 7일 이내의 상품 중고상품의 경우 출고 완료일로부터 6일 이내의 상품 (구매확정 전 상태)
반품/교환 비용	고객의 단순변심 및 착오구매일 경우 상품 반송비용은 고객 부담임 직수입양서/직수입일서중 일부는 변심 또는 착오로 취소시 해외주문취소수수료 20%를 부과할수 있음 단, 아래의 주문/취소 조건인 경우, 취소 수수료 면제 오늘 00시 ~ 06시 30분 주문을 오늘 오전 06시 30분 이전에 취소 오늘 06시 30분 이후 주문을 익일 오전 06시 30분 이전에 취소 직수입 음반/영상물/기프트 중 일부는 변심 또는 착오로 취소 시 해외주문취소수수료 30%를 부과할 수 있음 단, 당일 00시~13시 사이의 주문은 취소 수수료 면제 박스 포장은 택배 배송이 가능한 규격과 무게를 준수하며, 고객의 단순변심 및 착오구매일 경우 상품의 반송비용은 박스 당 부과됩니다.
반품/교환 불가사유	소비자의 책임 있는 사유로 상품 등이 손실 또는 훼손된 경우 소비자의 사용, 포장 개봉에 의해 상품 등의 가치가 현저히 감소한 경우 : 예) 화장품, 식품, 가전제품, 전자책 단말기 등 복제가 가능한 상품 등의 포장을 훼손한 경우 : 예) CD/LP, DVD/Blu-ray, 소프트웨어, 만화책, 잡지, 영상 화보집 소비자의 요청에 따라 개별적으로 주문 제작되는 상품의 경우 디지털 컨텐츠인 eBook, 오디오북 등을 1회 이상 다운로드를 받았을 경우 eBook 대여 상품은 대여 기간이 종료 되거나, 2회 이상 대여 했을 경우 취소 불가 중고상품이 구매확정(자동 구매확정은 출고완료일로부터 7일)된 경우 LP상품의 재생 불량 원인이 기기의 사양 및 문제인 경우 (All-in-One 일체형 일부 보급형 오디오 모델 사용 등) 시간의 경과에 의해 재판매가 곤란한 정도로 가치가 현저히 감소한 경우 전자상거래 등에서의 소비자보호에 관한 법률이 정하는 소비자 청약철회 제한 내용에 해당되는 경우
소비자 피해보상	상품의 불량에 의한 반품, 교환, A/S, 환불, 품질보증 및 피해보상 등에 관한 사항은 소비자분쟁해결기준(공정거래위원회 고시)에 준하여 처리됨
환불 지연에 따른 배상	대금 환불 및 환불 지연에 따른 배상금 지급 조건, 절차 등은 전자상거래 등에서의 소비자 보호에 관한 법률에 따라 처리

Collective Wisdom - 97가지 시리즈

: 소프트웨어 아키텍트가 알아야 할 97가지+프로젝트 관리자가 알아야 할 97가지+프로그래머가 알아야 할 97가지

이 책을 구입하신 분들이 산 책

품목정보

관련분류

책소개 책소개 보이기/감추기

목차 목차 보이기/감추기

저자 소개 관련자료 보이기/감추기

회원리뷰 (0건) 회원리뷰 이동

한줄평 (0건) 한줄평 이동

상품정보안내

배송/반품/교환 안내

배송 안내

반품/교환 안내

이 책을 구입하신 분들이 산 분야 책

이 책과 내용이 비슷한 추천 책

카트에 넣기

이 책을 구입하신 분들이 함께 산 책