-
-
소프트웨어 아키텍트가 알아야 할 97가지
Richard Monson-Haefel 지음, Eva Study 옮김 / 지&선(지앤선) / 2011년 4월
평점 : 
품절
아키텍트가 꿈인 저로썬 책 제목에 아키텍트가 들어간 책을 모른척하기엔 쉽지가 않은 편입니다. 새롭게 책이 나와서 보게 되었는데.
다 본 느낌은 대박입니다. 절.대.강.추 -_-b
책은 유명 아키텍트들과 국내 아키텍트들이 자신의 생각을 모아놓은 한권의 아름다운 책입니다. 좋은 글에 줄을 그으면서 보다 보니 거의 장마다 줄이 그어져 있는 상황이 벌어졌습니다. 실제로 경험이 많은 아키텍트가 얘기를 해줘서 그런것인지 도움이 되는 글들이 참 많았습니다.
1. 아키텍트는 직접 실무를 담당해야 한다
- 아키텍트는 보통 훌륭한 이력과 인상적인 경력을 갖고 잇습니다. 아키텍트는 비즈니스와 기술자들에게 깊은 인상을 줄 수는 있지만, 자신의 능력을 직접 실무에서 검증할 수 없다면 팀의 존경을 얻기 힘들며, 그 팀은 기술을 습득하기 어렵게 되고, 그 팀 멤버들은 원래 하려고 했던 일을 해내기가 거의 불가능하게 됩니다.
2. 일정을 지켜라
- 성급한 설계 스케줄 지시는(디자인 스케줄을 밀어붙이면) 저렴한 설계, 나쁜 문서, 그리고 품질 보증 또는 사용자 수용성에 문제가 생기게 합니다.
- 성급한 코딩이나 출시 일정은(코딩 또는 출시 일을 밀어붙이면) 사용자에게 제공되는 버그의 수와 직접적인 관계가 있습니다.
- 조급한 테스트 일정 지시는 완성도 낮은 테스트 코드 작성, 그리고 결함 발생률 증가와 직접적인 관계가 있습니다.
- 이상의 모든 지시에 의한 생산 문제를 해결하기 우해서는 훨씬 많은 비용이 들어갑니다.
3. 아키텍처적인 트레이드오프를 고려하라
- 높은 성능, 높은 가용성, 고수준의 보안 그리고 고수준의 추상화 모두를 동시에 충족하는 아키텍처를 설계하는 것은 사실상 불가능합니다.
4. 설계의 기준으로서 불확실성을 사용하라
- 어느 부분에서 자세한 사항을 미룰 수 있고, 또 어느 부분에서 설계 결정의 중요성을 감소시키기 위해 분할하고 추상화할지 불확실성을 기준으로 결정하십시오.
- 아키텍트는 둘 중 하나를 선택해야 하는 혼란스러운 상황이 오기 전에 미리 이런 상황에 빠져들 필요가 있습니다.
5. 재사용은 단지 아키텍처뿐 아니라 사람과 교육에 관한 것이다.
- 오직 다음에 언급할 사람들만 재사용합니다.
1) 재사용 요소가 있는 곳을 아는 사람
2) 재사용 요소를 사용할 수 있는 사람
3) 자신이 스스로 하는 것보다 재사용 요소가 낫다가 확신하는 사람
6. 범위는 성공의 적이다
- 고객이 실제 요구하는 것을 알아내십시오.
- 분할 후 정복하십시오.
- 우선순위를 두십시오.
- 가능한 결과가 나오자마자 전달하십시오.
- 복잡한 아키텍처는 간단한 아키텍처보다 훨씬 자주 실패합니다.
7. 쇼맨십을 넘는 가치 있는 청지기 정신
- 자신의 가치를 입증하는 것이 개인의 기술적 탁월함으로 팀을 좌절시키는 쇼맨십으로 이루어져야 한다고 오해하는 아키텍트들이 있습니다.
- 아키텍트는 확고한 리더십으로 팀의 존경을 얻어야만 하고 기술과 팀이 운영하는 비즈니스 도메인의 이해가 있어야 합니다.
8. 말하는 것에 대해서 말하다
- 유능한 아키텍트가 되기 위해서는 반드시 기본이 되는 아키텍처와 디자인 패턴들을 이해하고, 언제 사용되고, 적용할지 알아야 합니다. 그리고 다른 아키텍트.개발자와 대화하기 위해 패턴을 사용할 수 있어야 합니다.
- GoF의 기본 디자인 패턴들을 아는 것은 모든 소프트웨어 아키텍트에겐 필수적입니다.
- 이러한 패턴들은 아키텍트와 개발자 간에 효율적인 대화를 나누게 하는 표준 어휘의 일부입니다.
- 다양한 안티패턴들을 알고 이해하는 것 역시 ㅁ우 중요합니다.
9. 개발자에게 권한을...
- 개발자를 불필요한 업무에서 보호해야 합니다.
10. 패턴 중독
- 디자인 패턴들은 단지 되풀이되는 문제들에 대한 재사용 가능한 솔루션들입니다.
11. 견해, 취향보다는 원리, 원칙, 유추를 먼저 고려하라
- 아키텍트를 구성할 때에는 견해, 취향보다는 원리, 원칙, 유추를 먼저 고려하라
- 신기술을, 디자인패턴을 써보려고 두리번 거리고 있는 않는가?
12. 간단한 것은 간단하게 하라
- 간단한 것은 간단하게 유지해야 합니다.
- 복잡한 해결책으로 발생할 비용이 작을지도 모르지만 기회비용은 훨씬 많이 발생할 수 있습니다. 아키텍처 수준에서 오버 엔지니어링 문제는 개발 단계에서도 동일한 문제를 발생시키며 부정적인 영향은 배가 됩니다.
- 요구사항 이전에 아키텍처를 결정하고, 요구사항을 받아들인 후, 잘못된 것을 제거하는 것이 얼마나 어려운지 자문해 봐야 합니다.
- 미래 요구사항을 추측한다면 여러분의 50%가 틀렸을 겁니다. 그리고 나머지 49%는 완전히 틀린 요구사항일 것입니다. 오늘의 문제는 오늘 풀어야 합니다.
13. 설계하기 전에, 그것을 먼저 코드화할 수 있어야 한다
- 아키텍처 설계의 일부 구성 요소 중 여러분이 스스로 사용해본 적이 없는 구성 요소가 큰 비중을 차지한다면, 몇 가지 부작용이 일어나게 됩니다.
............................................
좋은 내용이 너무 많아서 다 못 옮기겠네요.. -_-;
좋은 책입니다.
아키텍트를 꿈꾸시는 분이라면 강추해드립니다. ^^