『소프트웨어 아키텍트가 알아야 할 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 유명환
피드백 유석문
너의 언어는 너의 사고의 한계이다 장선진
개발자들이 가져야 할 것들 장회수
공유하고 연대해라 조정현