아키텍트 책

출판사 톤앤매너, 뉘앙스를 알기 위해 몇권을 책을 읽고 있는데, 이 책은 정말 훌륭한 책이다. 실무 엔지니어 입장에서 하고 싶었던 말들이 참 많이 담겨 있다. 

http://www.yes24.com/24/goods/4839616?scode=032&OzSrank=1

소프트웨어 아키텍트가 알아야 할 97가지

소프트웨어 아키텍트로서 성공하려면, 비즈니스와 기술을 모두 익힐 필요가 있다. 이 책은 소프트웨어 아키텍트들이 무엇을 중요하게 생각하고, 어떻게 프로젝트를 접근하는지를 알려 준다. 48명 이상의 저자들의 합작품이며, 이들 모두 아무런 보상없이 소프트웨어 아키텍처에 대한 자신들의 생각과 충고를 제공했다. 어떤 측면에서 진정한 의미의 오픈 소스 서적이다. 각 ...

www.yes24.com

이 책에 만큼은 장황한 독후감을 지양하고 싶어, 깊이 공감한 주제에 관하여 볼드체로 표시한다. 그 중 가장 중요한 것은 [제목3]을 적용해서 더 크게 하였다. 공감이 가지만, 국내 활동 중인 아키텍트의 칼럼은 제외했다. 해외에서는 내가 뭘 썼던 잘 모를 것이기에. 글을 보면 이 사람이 관리적 아키텍트인지 엔지니어 출신인지가 어렴풋이 보인다. 프로젝트 성공에는 관리적 아키텍트가 더 나을 수도 있겠지만, 지속 가능한 성공과는 거리가 멀 것이라 생각한다. 곁에 두고 사전처럼 읽어야 할 책이다.

고객의 요구사항보다 여러분의 이력에 더 우선순위를 두지 말라 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