소프트웨어 아키텍처 The Hard Parts 2주차 - 최지윤 #590
Conversation
|
우측에 있는 |
Summary of ChangesHello @chichoon, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 이 PR은 "소프트웨어 아키텍처 The Hard Parts" 4장 "아키텍처 분해"에 대한 학습 노트를 추가합니다. 이 노트는 아키텍처를 분해하는 다양한 전략과 코드베이스의 균형을 평가하는 데 사용되는 추상도 및 불안정도와 같은 핵심 개념을 소개합니다. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
chichoon
added
2026
Software Architecture: The Hard Parts
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
소프트웨어 아키텍처 2판 4장 '아키텍처 분해'에 대한 요약 정리를 추가하신 PR 잘 보았습니다. 아키텍처 분해의 핵심 개념인 컴포넌트 기반 분해, 전술적 분기, 그리고 추상도와 불안정도에 대해 잘 정리해주셨습니다. 리뷰에서는 내용의 정확성과 일관성을 높이기 위한 몇 가지 제안을 드렸습니다. '애플리케이션'과 '모놀리식' 용어의 표기를 일관되게 수정하고, '메인 시퀀스'의 기울기에 대한 사실 관계를 바로잡는 내용을 포함했습니다. 또한, 일부 문장을 더 명확하게 다듬는 것을 제안했습니다. 전반적으로 내용 정리가 잘 되어 있으며, 제안된 수정 사항들을 반영하면 더욱 완성도 높은 요약이 될 것 같습니다.
| ### 개요 | ||
|
|
||
| - 컴포넌트 기반 분해 | ||
| - 어플리케이션의 논리적 구성 요소 단위 (컴포넌트 단위) 를 추출하고 이를 이용하여 아키텍처를 구성 |
There was a problem hiding this comment.
'어플리케이션'과 '애플리케이션' 표기가 혼용되고 있습니다. 9행에서는 '애플리케이션'으로 올바르게 작성하셨으므로, 일관성을 위해 '어플리케이션'을 '애플리케이션'으로 수정하는 것이 좋겠습니다.
| - 어플리케이션의 논리적 구성 요소 단위 (컴포넌트 단위) 를 추출하고 이를 이용하여 아키텍처를 구성 | |
| - 애플리케이션의 논리적 구성 요소 단위 (컴포넌트 단위) 를 추출하고 이를 이용하여 아키텍처를 구성 |
|
|
||
| - 메인 시퀀스로부터의 거리 | ||
| - 추상도와 불안정도 사이의 이상적인 관계 | ||
| - x절편, y절편, 기울기 1의 직선 |
There was a problem hiding this comment.
메인 시퀀스(Main Sequence)는 추상도(A) + 불안정도(I) = 1의 관계를 나타내는 선으로, 기울기가 -1입니다. 현재 기울기 1로 잘못 기재되어 있어 수정이 필요합니다.
| - x절편, y절편, 기울기 1의 직선 | |
| - x절편, y절편, 기울기 -1의 직선 |
|
|
||
| ### 컴포넌트 기반 분해 | ||
|
|
||
| - 컴포넌트 단위의 폴더구조 및 파일로 디렉터리를 구성 및 각 코드 분리 |
There was a problem hiding this comment.
문장이 다소 어색하게 읽힙니다. '폴더구조'와 '디렉터리'가 중복 사용되었고, '구성 및 각 코드 분리'라는 표현도 자연스럽지 않습니다. "컴포넌트 단위로 디렉터리 구조를 구성하고 코드를 분리"와 같이 좀 더 명확하고 간결하게 수정하는 것을 제안합니다.
| - 컴포넌트 단위의 폴더구조 및 파일로 디렉터리를 구성 및 각 코드 분리 | |
| - 컴포넌트 단위로 디렉터리 구조를 구성하고 코드를 분리 |
| - 서로간의 의존성 때문에 추출에 한계가 있는 경우 | ||
| - A팀, B팀이 서로 각각 코드베이스 사본을 복사한 후, 각자의 팀에 필요한 코드만 남기고 나머지를 삭제하는 기법 | ||
| - 이렇게 하면 각 파트별 큰 구조는 유지하면서 모놀리식 구조를 덩어리로 쪼갤 수 있다 | ||
| - 분해보다 상대적으로 쉽지만 모놀리스 코드의 흔적이 계속 남아있을 가능성이 있다 |
There was a problem hiding this comment.
'모놀리식'과 '모놀리스' 표기가 혼용되고 있습니다. 43행, 50행 등 다른 곳에서는 '모놀리식'으로 사용하셨으므로, 일관성을 위해 '모놀리스'를 '모놀리식'으로 수정하는 것이 좋겠습니다.
| - 분해보다 상대적으로 쉽지만 모놀리스 코드의 흔적이 계속 남아있을 가능성이 있다 | |
| - 분해보다 상대적으로 쉽지만 모놀리식 코드의 흔적이 계속 남아있을 가능성이 있다 |
chichoon
requested review from
GeunJuLEE,
TaeHyoungKwon,
benscookie,
dhlee3994,
jongfeel,
tttghost and
ymkim97
| ``` | ||
| 논의점: 추상도, 불안정도, 거리 등의 요소가 굉장히 수학적인 요소로 보이는데, 개발에는 정답이 없듯이 컴포넌트가 추상적인지, 불안정한지 여부를 판가름하는 기준도 매우 모호할 듯하다. 추상 클래스 등 명확하게 추상적인 요소가 없는 경우 이러한 수치들을 계산하고, 아키텍처 구성에 참고할 만한 자료로 삼는 것이 과연 가능할까 의문이 든다. | ||
| ``` |
There was a problem hiding this comment.
추상도와 불안정도를 측정하는 기준이 책에는 공식정도 주어져 있는데, 이 공식을 기반으로 공식에서 사용되는 하위 항목들의 정의만 잘한다면, 저는 이 값들을 측정하는 것은 어려운 작업은 아니라고 생각합니다.(사람이 아니라 컴퓨터가 하니까)
특히나 AI를 활용하면 훨씬 더 잘 할거라고 생각해서, 해당 컴포넌트의 유지보수성을 판단할 때, 사용할만한 지표라고 생각했었습니다
컴포넌트 눌러펴기 및 고아 컴포넌트라는 개념이 좀 많이 어려웠습니다
그 외에는 저번보다는 모호한? 부분이 적어 읽기 좀 수월했습니다