[달랩 책모임] 적정 소프트웨어 아키텍처

 

좋았던 점 / 어려웠던 점

---

슬기

👍🏻 4장에 아키텍처 드리프트를 방지하기 위해서 아키텍처 모델을 설명하려고 노력했던 점이 인상깊었다.

👎🏻 오역 설명해주신분께 고맙다. 37쪽에 인용문은 인용이 아니라 작가의 견해다... 등등 212쪽이 진짜 인용문

원문이랑 같이 봐야겠다 라는 것을 느꼈다.

오역이 많네요 ㅎ

---

태영

👍🏻최소계획설계 부분 좋았다.

👎🏻 용어설명이 따로 없어서 어려웠다.

뷰, 포트커넥터 등 기존에 알고 있던 스키마와 충돌이 있었다.

---

아샬

👍🏻 1부 리스크 중심으로 설계를 하면돼. => 그래서 어쩌라고? 2부에 상세하게 나온다

추상적일수 있는 것을 4장에서  구체적으로 잘 잡아주었다.

👎🏻 번역이 제대로 안돼있다. 용어 설명이 부족하다. 안그래도 안읽히는 책이 그래서 더 읽기 힘들었다.

---

병호

👍🏻 일관성 관리 언급이 좋았다

👎🏻 동적 아키텍처를 모르겠다 343쪽 이해가 어려웠다.

 

아샬님의 TIP

정적

클래스다이어그램

동적

전력패턴: 그림그리는 거일때 마우스 다운이 일어날때 펜슬 컨트롤러가 실행될거고 등등 이걸 클래스 다이어그램만으로 설명하기에 불충분. 런타임으로 그리면 더 설명이 잘될 수 있음.

듀얼픽디자인패턴? 듀얼프리디자인패턴? 도 동적

---

나정

👍🏻 135쪽 아키텍처 이해가 인상깊었다.

같은 걸 보더라도 운동 코치는 신인 선수들보다 행동을 더 이해하고 잘 분석할 수 있다. 전문가들이 아키텍처를 선택, 변경, 평가할 때 더 잘 분석할 수 있다. 

👎🏻 7장까지 읽었는데 7장이 너무 안읽혀서 포기했다. 정준모델구조가 뭐지?

 

아샬님의 TIP

"보통 대충 이런식으로 써" => 표준이라는 뜻

용어 설명에 집착하면 책 다 못읽는다.

---

태호

👍🏻 

75쪽

많은 개발자가 리스크를 고려하며 개발한다고 생각하지만

가장 중요한 실패리스크가 뭐냐, 이에 대응할 수 있는 엔지니어링 기법이 뭐냐? 라는 질문에 대답하지 못한다.

86쪽

아키텍처 설계에 들이는 노력은 실패 리스크에 상응해야 한다. 등의 실용적인 조언도 좋았다.

챕터 서두에 "뭘 설명하는지" 마치며에 "뭘 설명했는지"를 먼저 읽었다.

그리고 그것에 대한 답을 찾아내는 방식으로 책을 읽었다.

그렇게 보니 이 책이 생각보다 논리적으로 구성되어 있었다.

그래서 좋았다.

 

👎🏻 

책 읽는데 시간을 투자하지 못해 예시 및 종류 설명을 잘 이해하지 못해 아쉬웠다.

---

윤석

👍🏻 머릿속에서 상상이 되느냐의 여부가 문제를 해결할 때 도움이 된다. 153쪽이 좋았다.

---

주환

👍🏻 

👎🏻 뷰와 뷰타입의 차이가 뭔지 이해가 잘 안된다. 계층패턴 설명할 때 뷰 자체가 하나의 관심사여서 뷰가 바라보고 있는 관심사를 설명하려 하는 모델이다. 뷰타입은 걔네들을 모아놨다 해서 헷갈렸다.

마스터모델. 포함되는 예시는 나오는데 그래서 마스터모델이 뭔지 이해가 안된다.

 

아샬님의 TIP

뷰타입도 사실 타입이다. 런타임뷰 타입인 무언가를 그리는 것이다.

이것은 런타임뷰입니다. 이것은 컨트롤러입니다. 가 아니라, 런타임을 묘사하는 그림이 여러장 있다.

이런 것들을 다 모아서 이런게 런타임뷰입니다.라고 설명해주는 것

코끼리를 앞, 옆, 뒤에서 찍었다. 얘네들간에 모순이 없어야 한다. 이것은 마스터모델을 얼마나 잘 반영했냐에 따름.

새 개발자가 팀에 합류했을 때 그 자가 생각하는 마스터모델이 다를 수 있다.

---

 

아샬님의 TIP

책에서 컴포넌트: 객체랑 거의 비슷함

컴포넌트 타입과 컴포넌트 인스턴스가 있다.

책에서 컴포넌트라고 말하면 보통 컴포넌트 인스턴스다 근데 아닐수도 있으니 고려 잘 해서 봐라

114쪽 그림의 네모가 컴포넌트

 

병호

서로다른 모델 서로 연결 해야 하는데 인터페이스, 그걸 연결하는 커넥터

포트는 둘 이상의 컴포넌트간의 상호 경로인 커넥트로 연결된다.

배포

노드 : 배포될 수 있는 환경

품질 속성 시나리오

뷰타임 종류

 

아샬님의 TIP

커넥터는 10장을 봐야 이해가 쉽다.

뷰타입은 병호는 사람이다. 아샬도 사람이다 할 때 "사람"에 가깝다.

그 정도로만 이해하자. 뭐가 뭐에 속하는지를 담는 그런 엄격한 정의가 아니다.

모듈 뷰타입: 소스코드, 구성파일 등

런타임 뷰타입: 기능 시나리오 등

---

기능 시나리오 진짜 좋다

시나리오를 추적하면서 객체를 역으로 정의한다. (책: 오브젝트)

---

 

회고

이름 - 기분 점수

규원 - 8

책을 읽고 와야겠다

병호 - 9

몰랐던 것 헷갈렸던 걸 많이 배우고 가서 기분 좋다

나정 - 9

신청을 책 수준을 보고 해야할 것 같다

태호 - 8

리스크주도 설계라는 새로운 관점을 배웠다.

카카오... 도 리스크주도 설계라는 관점을 중요하게 생각했다면 이런 참사가 안일어나지 않았을까? 라는 생각을 했다.

사업가의 입장에서 굉장히 중요하게 고려할 가치가 있는 관점을 배운 것 같아서 기분이 좋다.

(윤석) => 그 엔지니어들이 중요하게 생각한 리스크가 다를 수 있다. 새 관점을 배웠으니 여러 관점을 더 배워서 다양한 각도에서 살펴보셨음 좋겠다.

유진 - 8

설계에 대해서 배우고 적용해보겠다

주환 - 9

리스크를 같이 생각해서 설계하겠다.

뷰타입에 대해 알게 됐다.

슬기 - 10

새로운 조직에 들어갈 때 적용해보겠다.

의사소통할 때 리스크도 고려해야겠다.

태영-  10

뜬구름같았던 말이 스터디 참여하면서 설명을 들어서 좋았다.

코드레벨로만 생각했던 용어가 디자인쪽에서 다를 수 있다. 라는 점을 배웠다.

아샬 - 9

아키텍처 공부를 막 열심히 한 적이 있었다.

도저히 유지보수가 안돼서 다시 짠 적이 많았다.

아키텍처에 관한 얘기를 해서 좋았다.

아키텍트가 아니라 일반인들도 해야한다. 라는 관점이 좋았다.

윤석 - 9

끝까지 못 읽었던 게 아쉽다.

읽을 때 고민했던 것을 스터디 와서 같이 고민해서 좋았다.