품목정보
발행일 | 2021년 06월 07일 |
---|---|
쪽수, 무게, 크기 | 392쪽 | 183*235*30mm |
ISBN13 | 9791162244326 |
ISBN10 | 1162244321 |
발행일 | 2021년 06월 07일 |
---|---|
쪽수, 무게, 크기 | 392쪽 | 183*235*30mm |
ISBN13 | 9791162244326 |
ISBN10 | 1162244321 |
[PART 1 소프트웨어 아키텍처] CHAPTER 1 소프트웨어 아키텍트가 되다 1.1 소프트웨어 아키텍트가 하는 일 1.2 소프트웨어 아키텍처란 무엇인가 1.3 팀에서 아키텍트가 되려면 1.4 훌륭한 소프트웨어 만들기 1.5 사례 연구: 라이언하트 프로젝트 1.6 마치며 CHAPTER 2 디자인 싱킹 기초 2.1 디자인 싱킹의 네 가지 원칙 2.2 디자인 마인드셋 장착하기 2.3 생각-실행-확인하기 2.4 마치며 [PART 2 아키텍처 설계의 기초] CHAPTER 3 설계 전략 고안하기 3.1 만족스럽게 설계하기 3.2 설계를 얼마나 우선해야 하는가 3.3 위험 요소를 가이드로 삼기 3.4 설계 계획 세우기 3.5 사례 연구: 라이언하트 프로젝트 3.6 마치며 CHAPTER 4 이해관계자와 공감하기 4.1 알맞은 사람과 이야기하기 4.2 이해관계자 맵 만들기 4.3 비즈니스 목표 탐색하기 4.4 사례 연구: 라이언하트 프로젝트 4.5 마치며 CHAPTER 5 아키텍처 핵심 요구사항 알아내기 5.1 제약으로 설계 선택지 줄이기 5.2 품질 속성 정의하기 5.3 기능 요구사항 찾아내기 5.4 아키텍처에 영향을 미치는 다른 요소 찾아내기 5.5 콘웨이 법칙 5.6 필요한 정보에 깊이 들어가기 5.7 ASR 워크북 만들기 5.8 사례 연구: 라이언하트 프로젝트 5.9 마치며 CHAPTER 6 아키텍처 선택하기 6.1 대안을 위한 분기, 결정을 위한 융합 6.2 제약 수용하기 6.3 품질 속성 끌어올리기 6.4 구성 요소에 기능별 역할 할당하기 6.5 변화에 대응하는 디자인 6.6 결정은 미룰 수 있을 때까지 미룬다 6.7 사례 연구: 라이언하트 프로젝트 6.8 마치며 CHAPTER 7 패턴으로 기초 만들기 7.1 아키텍처 패턴이란 무엇인가 7.2 레이어 패턴 7.3 포트와 어댑터 패턴 7.4 파이프와 필터 패턴 7.5 서비스 지향 아키텍처 패턴 7.6 발행/구독 패턴 7.7 공유 데이터 패턴 7.8 멀티 계층 패턴 7.9 숙련된 전문가 패턴 7.10 오픈소스 공헌 패턴 7.11 큰 진흙 공 패턴 7.12 새로운 패턴 발굴하기 7.13 사례 연구: 라이언하트 프로젝트 7.14 마치며 CHAPTER 8 의미 있는 모델로 복잡도 관리하기 8.1 아키텍처 파악하기 8.2 메타모델 설계하기 8.3 코드로 모델 구현하기 8.4 사례 연구: 라이언하트 프로젝트 8.5 마치며 CHAPTER 9 아키텍처 디자인 스튜디오 운영하기 9.1 아키텍처 디자인 스튜디오 계획하기 9.2 적절한 설계 활동 선택하기 9.3 적절한 참가자 초대하기 9.4 그룹 관리하기 9.5 원격으로 협업하기 9.6 사례연구: 라이언하트 프로젝트 9.7 마치며 CHAPTER 10 설계 시각화하기 10.1 다양한 관점으로 아키텍처 표현하기 10.2 멋진 다이어그램 그리기 10.3 사례 연구: 라이언하트 프로젝트 10.4 마치며 CHAPTER 11 아키텍처 문서화하기 11.1 문서화의 가치 11.2 상황에 맞는 서술 방법 11.3 명세서의 독자 고려하기 11.4 이해도가 중요하다 11.5 이해관계자의 관심사에 맞추어 뷰 구성하기 11.6 결정에 대한 논리적 근거 설명하기 11.7 사례 연구: 라이언하트 프로젝트 11.8 마치며 CHAPTER 12 아키텍처 평가하기 12.1 평가를 통해 배우기 12.2 설계 테스트하기 12.3 평가 워크숍 꾸리기 12.4 빠르게, 자주, 지속해서 평가하기 12.5 사례 연구: 라이언하트 프로젝트 12.6 마치며 CHAPTER 13 아키텍트에게 힘 실어주기 13.1 아키텍처 사고력 향상시키기 13.2 팀의 의사결정력과 역량 높이기 13.3 안전한 훈련으로 기회 만들기 13.4 설계 권한 위임하기 13.5 함께 아키텍처 설계하기 13.6 사례 연구: 라이언하트 프로젝트, 성대한 결말 13.7 마치며 [PART 3 아키텍트의 은빛 도구상자] CHAPTER 14 문제를 이해하고 싶을 때 활동 1 하나만 고르기 활동 2 공감 지도 활동 3 GQM 접근법 활동 4 이해관계자 인터뷰 활동 5 가정 나열하기 활동 6 품질 속성 레이다 차트 활동 7 미니 품질 속성 워크숍 활동 8 관점 매드 립 활동 9 허수아비 반응 활동 10 이해관계자 맵 CHAPTER 15 해결책을 찾고 싶을 때 활동 11 아키텍처 의인화 활동 12 아키텍처 플립북 활동 13 컴포넌트-역할 카드 활동 14 개념도 활동 15 나눠서 정복하기 활동 16 이벤트 스토밍 활동 17 그룹 포스터 활동 18 라운드 로빈 설계 활동 19 화이트보드 토론 CHAPTER 16 손에 잡히는 설계를 만들고 싶을 때 활동 20 아키텍처 의사결정 기록(ADR) 활동 21 아키텍처 하이쿠 활동 22 컨텍스트 다이어그램 활동 23 인기 독서 목록 활동 24 인셉션 덱 활동 25 모듈식 분해 다이어그램 활동 26 가지 않은 길 활동 27 프로토타입 활동 28 시퀀스 다이어그램 활동 29 시스템 메타포 CHAPTER 17 설계 대안을 평가하고 싶을 때 활동 30 아키텍처 브리핑 활동 31 코드 리뷰 활동 32 의사결정 매트릭스 활동 33 관측하기 활동 34 질문-코멘트-우려사항 활동 35 리스크 스토밍 활동 36 온전성 검사 활동 37 시나리오 훑어보기 활동 38 스케치하고 비교하기 부록: 기여자들 |
주로 프로그래밍 언어나 이론들을 공부해왔는데 앞으로 본격적인 개발을 한다면 실제 소프트웨어를 설계하는 것도 중요해보여서 책을 구매했다. 책의 분량은 생각보다 두껍지 않아서 부담되진 않았다. 그리고 라이언하트라는 예시 프로젝트를 다루면서 설명도 자세하게 해주니까 이해가 잘 되었다. 이 책 하나로 소프트웨어를 설계하는 방법을 다 알았다고 할 순 없겠지만 큰 줄기는 이해할 수 있었다. 책에서 배운 내용을 혼자 프로젝트를 해보면서 적용해보고 개발해보면 좋을 것 같다.
『개발자에서 아키텍트로』
마이클 킬링 지음
이 책을 읽어야 할 대상은 분명하다. 아키텍쳐를 진짜로 고민하는 사람.
개발자나 그저 막연히 아키가 하고 싶어서 보려고 한다면 비추다.
마치 대학 학부수업 느낌이 들 것이다. 코딩이라던가 실습예제 같은 것을 기대했다가는 영락없이 책꽂이로 직행이다. 대학교재 바로 옆자리로. 사진 찍은 골동품 교과서 『소프트웨어 아키텍처 이론과 실제』 옆이라면 더 좋을 것이다.
추천의 글을 보면 뭔가 있을 것 같은 기대감이 올라온다. 그러나 솔직히 지루하다. 우리나라에서 이렇게 프로젝트 하는 경우가 일년에 몇 개나 있을까? 다른 리뷰어들의 글을 보면서 진짜 저렇게 많은 사람이 높은 평점을 주는 이유가 뭘까 궁금했다. 내 내공은 아직 멀었나보다.
또 하나 아키텍트의 역할과 To-do list를 제시했지만, PM이나 PL 역할과 너무 중첩된다. 국내 어떤 프로젝트에서 PM, PL 제쳐놓고 아키가 나서서 이해관계자나 ASR을 분석하고 있나? 20년 넘게 프리랜서로 경험했던 것들은 너무 뻔한 국한된 프로젝트들 뿐이었나
이 책을 비난하는 것은 아니다. 어쨌든 건질만한 것들은 있다.
우리가 아키텍쳐를 너무 우습게 생각하고 있었다는 것, 점점 사라져가는 아키 포지션이 그래도 가치가 있다는 것, 골동품처럼 생각했던 아키텍처 패턴을 떠올릴 수 있었다는 교훈은 남는다. 책꽂이를 장식하던 『소프트웨어 아키텍처 이론과 실제』를 소환한 것도 단발성이지만 의미는 있었는데, 요 골동책보다는 훨씬 간결하고 이해가 쉽기 때문이다.
제대로 된 소프트웨어 팀을 만든다면 이렇게 해보고 싶다는 생각이 들기는 하다. 초중급 수준의 개발자라면 이 책보다는 디자인 패턴 관련 책이 더 적당할 것 같다.
※ 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.
아키텍트와 아키텍쳐...비슷한 말이지만 완전 다른...
특히 아키텍쳐는 많이 들어서 알고 있지만, 아키텍트는 잘 모르는 사람들이 많다..
현업에 있는 사람들도 생소한 단어가 아닐까 싶다.
다양한 하드웨어, 소프트웨어 개발을 하는 입장에 있는 개발자라면,
아키텍쳐를 빼놓고 얘기할 수 없다. 특히, 자동차 의료기기등 안전과 관련된 부분에서 개발하는 사람들이라면 이 아키텍쳐를 안 만들수 없다.
개발 관련 업무를 보는 사람들이라면 누구나 아키텍쳐라는 말은 들어봤다고 생각한다. 직접 만들어 보거나, 누가 만들어 놓은것을 보았거나, 수정해서 작성해 보았을 수도 있다.
그런데 직접 만들어 볼려고 하면 업무 영역에 따라 어떻게 만들어야 할까?...이게 맞게 만든것일까? 만들어진 것을 어떻게 평가할 것인가?등등...고민을 하게 되는 부분이 이 아키텍쳐를 만드는 작업이 아닐까 싶다.
재미있는건 아키텍쳐라는것은 그냥 만들어지지 않는다는것이다. 그냥 막 만들어서 이게 아키텍쳐요...라고 얘기할 수 있는것이 아니라는 것이다. 모든 개발에는 Requirement라는 것이 꼭 있고, 그 요구사항에 맞춰 제품들이 만들어지고 그것을 평가하여 제품화 하는 작업을 하게 된다는 것이다.
기본적은 소프트웨어 개발 lifecycle 은 요구사항 -> 아키텍쳐 -> Unit 구현 -> Unit 검증 -> 복합검증 -> 시스템검증 등의 순서로 작업이 이뤄지게 된다. 요구사항을 어떻게 구현하는 가에 있어 중요한 부분이 아키텍쳐를 잘 만드는 작업이다. 이 아키텍쳐가 잘 만들어져야 해당 unit들을 잘 만들수 있으며, V&V작업에서도 잘 평가할 수 있기 때문이다.
이런 과정을 생각한다면 아키텍쳐를 만든다는것이 생각외로 중요하다고 볼 수 있다.
아키텍쳐를 만든다고 하였을때, 아키텍쳐 관련된 책들은 생각외로 많이들 있다. 그런데 대부분이 방법론에 치우져 있는것이 대부분인거 같다. 그리고 내용들이 많이 어렵다. 글도 많고...
개인의 성향 차이가 있겠지만, 책의 내용을 잘 인지하고 빠르게 활용하고자하는 개발자 입장에서는 책 읽는데 소요되는 시간들이 너무 많이 걸린다는 부분은 마이너스 요인으로 볼수 있지 않을까....하는 생각을 가지고 있다. 나의 경우, 다른 아키텍쳐 책들이 몇개 있는데 끝까지 읽어본건 별로 없다.
그런점에서 이 책은 글 들이 간결하다. 그림도 좀 들어가 있고, 예도 많이 들어가 있다.
무엇보다 팀웍으로 작업이 가능하도록 내용들이 구성되어 있어서 실무에서도 try & error를 통한 완성도 높은 작업으로 진행할 수 있는 재미있는 구성으로 되어 있다.
빠른시간에 볼수 있고, 실무에서 궁금하거나 생각하지 않고 지나쳤던 부분도 같이 볼 수 있어서 책을 보는 시간동안 좋은 시간을 보낼수 있었다. 물론, 실무에도 참고할 수 있어서 좋은거 같다.