-
Notifications
You must be signed in to change notification settings - Fork 0
[한상호] 11장, 12장, 13장: 시스템 외 2장 #28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The head ref may contain hidden characters: "11,12,13\uC7A5/\uD55C\uC0C1\uD638"
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| # 🔖 Ch11. 시스템 | ||
|
|
||
| > 작성 일자 : 2025.07.27 / 작성자 : 한상호 | ||
|
|
||
| ## 💫 기억에 남는 문구 | ||
|
|
||
| - `p.194` : 우선 제작은 사용과 아주 다르다는 사실을 명심한다. | ||
| - `p.196` : 사용과 제작을 분리하는 강력한 메커니즘 하나가 의존성 주입이다. | ||
| - `p.197` : 처음부터 올바르게 시스템을 만들 수 있다는 믿음은 미신이다. | ||
| - `p.211` : 우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤 한다. ~ 최대한 정보를 모아 최선의 결정을 내리기 위해서다. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 최선의 결정을 내리기 위한 최대의 정보와 결정을 흐지부지 미루는 경우, 이 두 사이의 경계를 잘 파악해야 할 것 같네요. |
||
| - `p.213` : 시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Node.js 의 Keep It Simple and Stupid 철학과도 비슷한 것 같아요! |
||
|
|
||
| ## 💡 느낀 점 | ||
|
|
||
| 1. DI에 대한 내용이 나와서 흥미롭게 읽을 수 있었다. 자바 & 스프링에서는 DI 컨테이너가 의존성을 관리해주는데, 이것이 스프링의 큰 장점이라는 것을 다시 상기하게 되었다. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 저는 개념 공부를 다시 해야할 것 같아요 ㅠㅠ |
||
| 2. 처음부터 올바르게 시스템을 만들 수 없다는 사실에 대해서 공감되었다. 미래를 생각해서 유지보수성 & 확장성이 높은 설계를 하려고 노력은 해야겠지만, 모든 상황에 대해서 예측하고 대응할 수는 없을 것이다. | ||
| 3. 더욱 중요한 것은, 현재 상황에서 최소의 비용으로 최선의 선택을 하기 위해서 노력해야 한다는 것이다. 그리고 문제가 발생하거나 변화가 필요한 상황에서는 기민하고 적절하게 아키텍처를 변화시킬 수 있어야 한다. 최근에 신입으로서 `오버 엔지니어링`을 피하기 위해서 노력하고 있는데, 이러한 부분들과 맥락이 유사한 것 같다. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 굳!!
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 개발자 인력을 포함해서 최소 비용을 고려한 설계가 중요한 것 같아요 👍 |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| # 🔖 Ch12. 창발성 | ||
|
|
||
| > 작성 일자 : 2025.07.27 / 작성자 : 한상호 | ||
|
|
||
| ## 💫 기억에 남는 문구 | ||
|
|
||
| - `p.216` : 문서로는 시스템을 완벽하게 설계했지만, 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면, 문서 작성을 위해 투자한 노력에 대한 가치는 인정받기 힘들다. | ||
| - `p.217` : 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻하기 때문이다. | ||
| - `p.221` : 하지만 표현력을 높이는 가장 중요한 방법은 노력이다. | ||
| - `p.222` : 클래스와 메서드 크기를 줄이자고 조그만 클래스와 메서드를 수없이 만드는 사례도 없지 않다. | ||
|
|
||
| ## 💡 느낀 점 | ||
|
|
||
| 1. 이번 챕터에서는 매우 중요한 4가지 원칙이 나왔었다. 지금까지 수없이 보았지만, 아직도 제대로 하고 있지 않음에 반성하게 되었다. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 저도요 ㅜ
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 저두..... |
||
| 2. 클래스와 메서드의 크기를 줄이기 위해서 분리를 하다 보면, 클래스와 메서드의 개수가 너무 많이 늘어나는 경우가 있다. 나 또한 그러한 경험이 존재한다. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 이 기준을 어떻게 잡을지 잘 모르겠습니다.. |
||
| 3. 우선순위는 가장 낮지만, 클래스와 메서드의 개수도 최소로 유지하도록 노력해야겠다는 생각이 들었다. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| # 🔖 Ch13. 동시성 | ||
|
|
||
| > 작성 일자 : 2025.07.27 / 작성자 : 한상호 | ||
|
|
||
| ## 💫 기억에 남는 문구 | ||
|
|
||
| - `p.226` : 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. | ||
| - `p.228` : 일반적으로 동시성 버그는 재현하기 어렵다. 그래서 진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다. | ||
| - `p.231` : 자신만의 세상에 존재하는 스레드를 구현한다. | ||
| - `p.233` : 언어가 제공하는 클래스를 검토하라. 자바에서는 java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks 를 익혀라. | ||
| - `p.239` : 프로세서 수보다 많은 스레드를 돌려보라. | ||
| - `p.240` : 다중 스레드 코드는 플랫폼에 따라 다르게 돌아간다. | ||
| - `p.242` : 좋은 테스트 케이스와 흔들기 기법은 오류가 드러날 확률을 크게 높여준다. | ||
|
|
||
| ## 💡 느낀 점 | ||
|
|
||
| 1. 동시성 테스트는 동일한 테스트 코드임에도 불구하고 다른 결과가 나올 수 있어서, 정확히 테스트하기 조금 어려운 것 같다. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 이 부분이 고민인게... 주로 ci/cd 툴은 테스트를 자동화하여, 테스트가 통과되면 배포가 진행되곤 하잖아요. |
||
| 2. 책에서 나온, concurrent 관련 클래스들을 한 번 공부해 보아야겠다는 생각이 들었다. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 동시성은 고려해야 할 게 정말 많은 것 같아요 |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저는 이런 미신을 가지고 있었습니다...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저도요...