Update and closing 스트리트 코더 sprint 7 1장 2장 3장 총 112 페이지 2026 04 03

2026/Street_Coder/jongfeel/Chapter1_To_the_street.md

@@ -0,0 +1,30 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1658
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1658#issuecomment-4155910135
+
+## 리뷰
+
+크게 두 가지이다.
+
+- 훌륭한 스트리트 코더란?
+- 현재 소프트웨어 개발의 문제점 (출판일 기준 2022년 관점)
+
+### 스트리트 코더
+
+- 질문을 잘 해서 시야를 넓히고 배우자
+- 결과를 내야 한다
+- 기능이 잘 처리되어야 한다 (높은 처리량)
+- 복잡하고 모호한 걸 단순화시키자
+
+### 소프트웨어 개발의 문제
+
+- 기술이 너무 많다
+- 패러다임 중심적이며, 따라서 보수적이다
+- 기술은 자동차처럼 점점 불투명해지고 있다
+- 사람들은 코드의 오버헤드를 신경 쓰지 않는다
+- 프로그래머는 자신이 작업 중인 스택에 집중할 뿐 나머지 부분이 어떻게 동작하는지에는 관심이 없으며, 이것을 당연하게 생각한다
+- 그동안 배운 패러다임에 감사하자

2026/Street_Coder/jongfeel/Chapter2_Practical_theory.md

@@ -0,0 +1,15 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1659
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1659#issuecomment-4155880188
+
+## 후기
+
+전반적으로 컴퓨터공학과에서 배우는 기초 지식을 다시 리뷰하는 느낌인데다
+C# 언어를 알고 있기 때문에 C#의 특정 문법을 설명하는 것도 다 아는 내용을 설명해 주고 있다.
+
+그래서 내용이 많고 길어도 짧게 정리할 수 있었다.
+꼭 정리를 하지 않더라도 컴퓨터공학과에서 배우는 내용을 한 번 리마인드 해본다는 데 의미가 더 있을 것 같다.

2026/Street_Coder/jongfeel/Chapter3_Useful_anti-patterns.md

@@ -0,0 +1,72 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1661
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1659#issuecomment-4155880188
+
+### 논의 주제
+
+SOLID 원칙에 대한 비판의 내용은 저한테는 상당히 신선했습니다.
+너무 많은 자료에서 SOLID 원칙은 신성불가침의 영역이라고 생각했었는데, 그걸 비판한 글을 출판할 수 있다는 점은
+무비판 적으로 수용하는 태도를 경계하는게 좋겠다의 생각도 들게 합니다.
+
+저자가 주장하는 SOLID 원칙의 비판 내용 중에서 공감이 되거나 아니라고 하는 부분이 있으면 얘기해 보면 재미있을 것 같습니다.
+
+### 3.3.1 미래를 향한 경주
+
+이 소주제의 제목이 아주 마음에 든다.
+왜냐하면 나도 그렇게 느끼기 때문이다. 오래된 특정 버전, 특히 LTS에 안주하고 변화를 거부하는 건 내 성향상 맞지 않다.
+미래에 더 좋은 게 나온다면 그걸 받아들이고 조금씩 업데이트를 진행해 미래가 현재가 됐을 때 동참하는게 좋은 방향이라고 본다.
+한 때 "최신 버전 성애자" 라는 별명이 있었는데, 지금도 유효하다.
+
+## 아래는 SOLID 원칙에 대해 저자의 비판적인 시각을 담은 글이다.
+오랫동안 SOLID 원칙을 이해하고 있는 나에게는 확실하고 근거있는 주장 처럼 들리지는 않는다.
+
+예) 인터페이스 분리 원칙은 사실 오래 개발해보고 단순한 설계를 지향하다 보면 이해가 되는 원칙인데 비판을 하면서도 설계 요구사항에 근거해야 한다는 이해할 수 없는 말을 하고 있다.
+
+핵심은 이해하되 무비판적인 수용음 금물이라는 측면에서는 읽어 볼만 하고, 다소 신선한 주장으로 여겨진다.
+분명 로버트 마틴의 빠돌(빠순)이 들에게 있어서는 오히려 비판적인 시각이 생기기도 할 것이다.
+
+### On SOLID principles
+
+There is a famous acronym, SOLID, that stands for five principles of object-oriented programming.
+The problem is that SOLID feels like it was invented to make a meaningful word rather than to make us better programmers. 
+I don’t think all its principles carry the same importance, and some may not matter at all.
+I strongly oppose embracing a set of principles without being convinced of their value.
+
+The single-responsibility principle, the S of SOLID, says a class should be responsible for one thing only as opposed to one class doing multiple things, aka God classes.
+That’s a bit vague because it’s we who define what one thing entails. Can we say a class with two methods is still responsible for one thing anymore?
+Even a God class is responsible for one thing at a certain level: being a God class.
+I’d replace this with the clear-name principle: the name of a class should explain its function with as little vagueness as possible.
+If the name is too long or too vague, the class needs to be split into multiple classes.
+
+The open-closed principle states that a class should be open for extension but closed for modification.
+It means that we should design our classes so that their behavior can be modified externally.
+This is, again, very vague and can even be unnecessarily time consuming.
+Extensibility is a design decision and may not be desirable, practical, or even safe at times. It feels like the advice to “use the racing tires” of programming. 
+I would instead say, “Treat extensibility as a feature.”
+
+The Liskov substitution principle, coined by Barbara Liskov, states that a program’s behavior shouldn’t change if one of the classes used is replaced with a derived class.
+Although the advice is sound, I don’t think it matters in daily programming work.
+It feels like the advice “Don’t have bugs” to me.
+If you break an interface’s contract, the program will have bugs.
+If you design a bad interface, the program will also have bugs.
+That’s the natural order of things.
+Perhaps this can be turned into simpler and more actionable advice like “Stick to the contract.”
+
+The interface segregation principle favors smaller and goal-specific interfaces over generalized, broadly scoped interfaces.
+This is unnecessarily complicated and vague, if not just plain wrong, advice.
+There could be cases where broadly scoped interfaces are more suitable for the job, and overly granular interfaces can create too much overhead.
+Splitting interfaces shouldn’t be based on scope, but on the actual requirements of the design.
+If a single interface isn’t suitable for the job, feel free to split it, not to satisfy some granularity criteria.
+
+The dependency inversion principle is the final one.
+Again, it’s not a very good name.
+Just call it depend on abstractions.
+Yes, depending on concrete implementations creates tight coupling, and we’ve already seen its undesirable effects.
+But that doesn’t mean you should start creating interfaces for every dependency you have.
+I say the opposite: prefer depending on abstractions when you prefer flexibility and you see value in it, and depend on the concrete implementation in cases where it just doesn’t matter.
+Your code should adapt to your design, not the other way around.
+Feel free to experiment with different models.