“소프트웨어
아키텍트가 알아야 할 97가지”의 목차를 부분적으로 요약
설명과 함께 정리하였다. 다수 저자의 자료를 취합 정리하여 하나의 책으로 엮었으므로, 다소 산만하기도 하지만 소프트웨어 아키텍트의 다양한 관점을 제공하고 있는 유용한 자료이다. 상세한 내용은 원서와 번역서를 참고하기 바란다. 원서는 책이나 eBOOK으로 구매할 수 있고, 인터넷에서 무료 PDF 파일로 다운로드 받을 수도 있다.
1.
요구사항보다 여러분의 이력을 우선하지 말라 Nitin Borwankar
최선의 문제 해결 방법이
아닌데 개인의 호기심 또는 이력에 포함시키기 위해 기술, 방법론, 일하는
방식을 추천하는 경우가 있는데, 대부분 좋은 결과를 얻지 못한다. 개인의
단기 요구보다는 고객의 장기 요구를 우선하면, 잘못되는 일이 없다.
2.
본질적인 복잡성을 단순화하고, 의도하지 않은 복잡성을 줄인다 Neal Ford
3.
가장 큰 문제는 기술이 아니고 사람이다 Mark Ramm
항상 목표를 공유하고, 사람 문제를 배우는 기회로 활용하고, 당신의 감정을 관리하면, 당신은 더 효과적일 뿐 아니라 항상 무엇인가를 배울 것이다.
4.
소통이 왕이라면, 명확성과 리더십은 겸손한 신하이다 Mark Richards
5.
어플리케이션 아키텍처는 어플리케이션 성능을 결정한다 Randy Stafford
6.
요구 기능이 업무에 도움 (value) 이 되는지 이해한다 Einar Landre
7.
일어서라 Udi Dahan
소프트웨어 아키텍트의 가이드와
권장사항이 개발자와 관리자에게 효과적으로 받아들여지기 위해서는 효과적인 의사소통이 중요하다. 서서 말하면
아이디어를 소통할 때 2배 이상 효과적이다.
8.
모든 것은 궁극적으로 실패한다 Michael Nygard
소프트웨어 오류가 발생할
수 있다는 것을 받아들이고 오류가 발생했을 때 대응 방안을 설계하고 구현한다.
9.
생각하는 것보다 더 자주 협상한다 Michael Nygard
10.
구체적으로 수치화한다 Keith Braithwaite
11.
한 줄의 실행 코드가 500 줄의 명세만큼 가치 있다 Allison Randa
설계는 처음부터 완벽하지
않고, 구현하면서 수정된다.
12.
모든 경우에 적합한 해결책 (one-size-fits-all solution) 은
없다 Randy Stafford
13.
성능을 처음부터 고려한다 Rebecca Parsons
14.
아키텍처는 기술과 업무 요구사항의 균형 (balancing)을 이루는 것이다 Randy Stafford
15.
적절한 선행 테스트 없이 커밋하고 실행 (commit and run) 하는
것은 것은 범죄다 Niclas Nilsson
단위테스트를 충분히 하지
않고 통합테스트를 바로 실행하여 오류로 인하여 관련되는 많은 개발자의 업무에 심각한 문제가 생기는데, 프로젝트에서
자주 발생한다.
16.
하나 이상의 방법이 존재할 수 있다 Keith Braithwaite
서로 다른 비기능적 요구사항이
다른 해결책을 요구한다. 복잡한 어플리케이션 요구사항을 충족하기 위해서는 하나의 획일적인 표준을 적용하지
못할 수도 있다.
17.
업무 중심의 의사결정이 장기적으로 소프트웨어 개발 조직에게 도움이 된다 Dave
Muirhead
18.
일반화하기 전에 단순화하고, 재사용하기 전에 사용한다 Kevlin Henney
추측에 의한 일반화 보다는
경험에 따라 단순화한다. 재사용을 위해 설계된 많은 컴포넌트는 종종 아무도 만족시키지 못한다. 우선적으로 컴포넌트는 사용하도록 설계하여야 한다. 일반화는 업무에
대한 이해가 있어야 가능하고, 이해는 단순화를 가능하게 한다.
19.
아키텍트는 구현 능력 (hands on)을 가져야 한다 John Davies
아키텍트는 프로젝트 초기부터
프로젝트에 참여한다. 업무와 기술에 대한 충분한 지식과 경험을 보유하지 않으면, 팀원으로부터 인정을 받고, 팀원을 가르치기 어려우며, 팀원이 아키텍트의 가이드에 따라 프로젝트를 진행하게 하는 것은 불가능하다.
20.
지속적으로 통합한다 David Bartlett
21.
일정을 지킨다 Norman Carnovale
일정 변경이 필요하면 미치는
영향을 고려하여 일정을 조정한다. 필요한 경우 개발 범위를 조정하거나 인력을 추가로 투입한다.
22.
아키텍처의 상호 영향 (tradeoffs)을 고려한다 Mark Richards
높은 성능, 높은 가용성, 높은 보안, 높은
추상화 등 모든 요구사항을 만족하는 아키텍처를 설계하는 것은 불가능하다.
23.
요새같이 튼튼한 데이터베이스를 구축한다 Dan Chak
24.
설계의 기준으로 불확실성을 사용한다 Kevlin Henney
25.
거울로 보이는 문제는 보이는 것보다 클 수도 있다 Dave Quick
사소해 보이는 문제가 중요한
문제로 커지거나, 서로 경험과 지식을 잘 공유하지 않고, 낙관적이고, 서로 관점이 달라서 프로젝트에 문제가 발생한다.
26.
재사용은 단지 아키텍처가 아닌 사람과 교육에 관한 것이다 Jeremy Meyer
재사용을 위해서는 개발자가
컴포넌트가 어디에 있는지 (know it’s there) 그리고
어떻게 사용하는지를 알아야 (know how to use it) 하고,
자신들이 직접 개발하는 것보다 재사용이 도움이 된다는 것을 인식하여야 한다.
27.
아키텍처에는 “나” 는 없다 Dave Quick
아키텍처에서 “나”를 없애면
성공을 보장하지는 않지만, 실패의 일반적인 원천인 아키텍트의 잘못을 없앨 수 있다. 이것을 극복하기 위하여 아키텍트는 고객 요구사항에 충실하고, 팀에
집중하고, 항상 일하는 것을 점검하고, 방어적으로 행동하고
있지 않은지 살펴 보아야 한다.
28.
1000피트의 관점을 가진다 Erik
Doernenburg
29.
결정하기 전에 시도한다 Erik Doernenburg
30.
비즈니스 도메인을 이해한다 Mark Richards
31.
프로그래밍은 건설하는 것이 아니고, 설계하는 것이다 Einar Landre
32.
개발자에게 자율성을 부여한다 Philip Nelson
33.
시간은 모든 것을 바꾼다 Philip Nelson
경험으로부터 배우고, 되돌아가서 고치려는 유혹에서 벗어 나라. 시간이 지나면 잘 못된
것을 쉽게 발견할 수 있다.
34.
소프트웨어 아키텍트는 단지 소문자 a를 갖는다. 그것을 다뤄라 Barry Hawkins
35.
범위는 성공의 적이다 Dave Quick
범위를 줄이면 종종 아키텍처가
단순해지고, 아키텍트가 성공할 가능성을 높여주는 가장 효과적인 전략이다.
36.
장사꾼 (showmanship) 보다는 봉사 (stewardship) 에 가치를 둔다 Barry Hawkins
고객의 돈으로 일하고 있다는
사실을 명심한다.
37.
소프트웨어 아키텍처는 윤리적 결과를 가져온다 Michael Nygard
모든 의사결정은 사용자에게
미치는 영향을 고려하여, 사용자의 편의를 위해 아키텍트는 자신의 일을 기꺼이 받아들여야 한다.
38.
마천루는 확장할 수 없다 Michael Nygard
다른 공학 영역과는 다르게
소프트웨어를 변경할 수 있다. 많은 가치를 제공하면서 더 좋은 아키텍처 품질을 동시에 만족시키는 것은
어렵지만, 개별 컴포넌트의 조기 이행을 통하여 가치와 아키텍처 품질을 제고할 수 있다.
39.
이질성 (heterogeneity) 이 이긴다 Edward Garson
40.
성능이 전부다 Craig RusselI
41.
백지 위에 그린다 (engineer in the white spaces)
Michael Nygard
42.
소통이 중요하다 (talk the talk) Edward Garson
소프트웨어 아키텍트는 분명하고, 간단하고, 효과적인 방법으로 소통하는 능력이 필요하다. 이러한 수단이 아키텍처와 설계 패턴이다. 소프트웨어 아키텍트는 함께
나아가면서 소통할 수 있도록 패턴을 배우고 이해한다.
43.
Context가 왕이다 (context is king)
Edward Garson
이상에서 벗어나, 주어진 업무와 기술적인 요구를 받아들이고 나서 가장 단순한 솔루션을 찾는다.
정황이 왕이고, 단순함은 검소한 신하이다.
44.
아키텍트는 다양한 배역을 한 방향으로 이끈다 Evan Cofsky
아키텍트는 난장이, 장난꾸러기, 마법사를 다루는 왕과 같다. 아키텍트는 모든 이해당사자를 염두에 두고 프로젝트를 이끌어야 한다.
45.
건물의 건축가로부터 배운다 Keith Braithwaite
46.
반복 작업과 싸운다 Niclas Nilsson
중복이 나쁜 것이고 반복
작업이 개발을 지연시킨다는 사실을 받아 들이고 반복 작업을 최소화한다.
47.
현실을 바로 이해한다 Gregor Hohpe
현실은 맞거나, 틀린 단순한 2차원이 아니다.
48.
통제하지 말고, 관찰한다 Gregor
Hohpe
49.
야누스로서 아키텍트 David Bartlett
아키텍트는 야누스처럼 문과
길을 지키고, 옛 것과 새로운 것을 동시에 받아 들이면서, 내일의
변화를 받아 들일 준비를 하면서, 현재의 요구사항을 충족시키기 위해 건전한 공학과 창의성을 통합한다.
50.
아키텍트의 초점은 경계와 인터페이스에 있다 Einar Landre
복잡한 문제 해결을 위해서는
나누어서 정복하는 (divide and conquer) 전략을 사용한다. 관심의 분리 (separation of concern)와 동일한
개념이며, 관심의 분리는 캡슐화 (encapsulation)를, 캡슐화는 경계와 인터페이스 (boundaries and interfaces)를
다룬다.
51.
개발자 역량을 개발한다 (empower) Timothy High
개발자에게 필요한 개발 도구를
제공하고, 필요한 스킬을 가지고 있는지 확인하고, 개발자가
주어진 설계 원칙하에서 스스로 의사 결정하도록 하고, 개발 이외의 업무로부터 개발자를 최대한 보호한다.
52.
결정에 대한 근거를 남긴다 Timothy High
53.
가정에 도전한다. 특히 당신의 가정에 대하여 Timothy High
54.
경험과 지식을 공유한다 Paul W. Homer
55.
패턴 중독을 피한다 Chad LaVigne
프로젝트에 불필요하게 패턴을
강요하면 지나친 엔지니어링이 일어난다. 디자인 패턴은 만병통치약이 아니며, 패턴 사용은 저절로 좋은 설계를 보장하지 않는다. 반복되는 문제에
대한 재사용 해결책이다. 효과적인 업무 솔루션을 제공하기 위한 시스템 설계에 집중하고, 해결하려는 문제를 풀기 위하여 패턴을 사용한다.
56.
아키텍처 메타포어를 확대하지 않는다 David Ing
시스템 은유에 빠져서는 안된다. 설명을 위한 소통 수단으로만 사용하고, 스스로 은유에 사로 잡히지
않아야 한다.
57.
운영과 유지 보수에 집중한다 Mncedisi Kasper
지원인력의 학습곡선이 최소화되도록
설계한다. 추적 가능하고, 검증가능하며, 기록을 남기는 (traceability, auditing, and
logging) 것이 중요하다. 운영자가 행복하면 모두가 행복하다 (특히 당신의 상관이).
58.
두 개를 받아들일 준비를 한다 Bill de hora
59.
견해, 취향보다는 원리, 원칙, 유추를 우선한다 Michael Harmer
60.
걸어 다니는 해골 (walking skeleton) 으로 시작한다 Clint Shank
걸어 다니는 해골은 모든
주요한 아키텍처 콤포넌트를 연결하는 최소한의 처음부터 끝까지의 이행을 말한다. 걸어 다니는 해골로 시작해서
실행하면서 점진적으로 발전시킨다.
61.
데이터가 핵심이다 Paul W. Homer
62.
간단한 것은 간단하게 해결한다 Chad La Vigne
63.
우선적으로 아키텍트는 개발자이다 Mike Brown
당신이 설계한 것을 당신이
코딩을 할 수 있어야 한다.
64.
투자 수익율 (ROI) 을 고려한다
George Malamidis
아키텍처 결정을 투자로 생각하고
투자 수익율을 고려한다. 그것이 테이블에 있는 모든 선택사항이 얼마나 실용적인지 또는 적합한지를 발견하는
유용한 방식이다.
65.
시스템이 레거시라고 생각하고 설계한다 Dave Anderson
66.
단 하나의 솔루션만 있다면, 다른 솔루션을 찾는다 Timothy High
67.
변경의 영향을 이해한다 Doug Crawford
68.
하드웨어도 알아야 한다 Kamal Wickramanayake
69.
편법 (shortcuts) 은 나중에 이자가 붙어 돌려 받는다 Scot Mcphee
아키텍트로서, 아키텍처 문제나 설계 결함을 발견하면 바로 수정한다. 수정하는 것을
미루면 나중에 더 높은 이자를 지불한다.
70.
완벽은 충분함의 적이다 (Perfect is the enemy of good
enough) Greg Nyberg
어플리케이션 개발은 미인
선발대회가 아니다. 완벽을 위해 결함을 찾기 위해 시간을 낭비하면 안 된다.
71.
좋은 아이디어를 피한다 Greg Nyberg
프로젝트를 망칠 수 있는
무책임한 아이디어를 경계한다.
72.
좋은 콘텐츠가 좋은 시스템을 만든다 Zubin Wadia
컨텐츠기반 시스템을 구축할
경우 컨텐츠는 왕이고, 네트워크이고, 인터페이스이다. 컨텐츠 품질은 프로젝트 성공과 실패의 기준이 된다.
73.
업무와 좋은 관계를 유지한다 Chad LaVigne
74.
시스템을 검증하기 위해 주요 영역 (key dimensions)을 넓힌다 Stephen Jones
75.
설계하면, 개발할 수 있어야 한다 Mike
Brown
76.
명명할 수 없으면 개발할 수 없다 Sam Gardiner
이름을 부여할 수 없으면
개발할 수 없다. 이름을 3번 바꾸면, 개발하려는 것이 무엇인지 알기 전에는 개발하지 않는다.
77.
안정적인 문제는 높은 품질의 솔루션을 얻는다 Sam Gardiner
78.
근면해야 한다 (it takes diligence) Brian Hart
79.
결정에 책임진다 Yi Zhou
80.
독창적으로 구현하지 않는다 (Don’t
be clever) Eben Hewitt
81.
신중하게 무기를 선택하고, 조심스럽게 버린다 Chad LaVigne
문제를 해결할 기술을 선택하는
것이 아키텍트의 주요한 일이다. 무기를 신중하게 선택하고 조심스럽게 버린다. 과거 성공으로부터 미래 성공을 확보하고, 새로운 기술 영역을 조심스럽게
확장한다.
82.
여러분의 고객은 여러분의 고객이 아니다 Eben Hewitt
여러분의 고객의 고객이 여러분의
고객이다. 고객의 고객이 요구하는 것을 챙긴다.
83.
처음 보이는 것처럼 되지 않는다 Peter Gillard-Moss
설계는 발견의 과정이다. 개발이 진행됨에 따라 이전에 발견하기 어려운 것을 발견한다. 설계가
끊임없이 변하는 세상에서 지속적으로 바뀌는 프로세스라는 것을 인정한다면, 설계 프로세스는 유연하고 계속된다는
것을 알아야 한다.
84.
다른 프레임워크와 잘 어울리는 프레임워크를 선택한다 Eric Hawthorne
85.
강력한 비즈니스 사례를 만든다 Yi Zhou
§
아키텍처의 이점을 설명한다 (establish the value
proposition)
§
정량화 한다
§
금액으로 환산한다
§
언제 멈출지를 안다
§
적절한 시점을 찾는다
86.
코드뿐만 아니라 데이터도 제어한다 Chad LaVigne
87.
기술 채무를 갚는다 Burkhardt Hufnagel
88.
단순한 문제 해결사가 되지 않는다 Eben Hewitt
89.
사용하기 편리한 시스템을 구현한다 Keith Braithwaite
90.
열정적인 문제 해결사를 찾고 유지한다 Chad LaVigne
91.
소프트웨어는 실제로 존재하지 않는다 Chad LaVigne
92.
새로운 언어를 배운다 Burkhardt Hufnagel
93.
미래를 만족하는 솔루션을 개발할 수는 없다 Richard Monson-Haefel
오늘의 솔루션은 내일의 문제이다. 현재의 문제에 가장 적합한 솔루션을 구현한다.
94.
사용자 인수 문제를 피한다 Norman Carnovale
프로젝트 챔피언을 선정하고
좋은 관계를 유지하여 사용자 인수
문제가 발생하지 않도록 한다.
95.
맑은 수프 콩소매처럼 아키텍처를 투명하게 정련한다 Eben Hewitt
96.
최종 사용자에게는 인터페이스가 시스템이다 Vinayak Hegde
97.
좋은 소프트웨어는 만드는 것이 아니라 성장한다 Bill de hora
댓글 없음:
댓글 쓰기