https://www.yes24.com/Product/Goods/119108069
책의 제목
(원서) The Missing Readme: A Guide for the New Software Engineer (번역서) 필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생 감상 2023.10.23 많지 않은 분량으로 실무 개발자의 폭넓은 업무를 다루면서 결코 얄팍하지 않은 지식을 전달하는 책입니다. 협업, 설계, 구현, 테스트, 문서화, 긴급 대응, 경력 관리 등 다양한 분야에 대한 알찬 조언을 책 한권에 눌러 담았고 더 많은 분량을 학습하고 싶은 독자를 위한 참고자료들도 매 장마다 소개하고 있습니다.
https://www.yes24.com/Product/Goods/6006038
인상 깊은 단락 p39 클래스명의 어휘는 경험과 함께 향상된다.
‘숙련도별 자주 이용되는 클래스명'은 우리 나라 개발자과도 비슷한 느낌이다.
p49 ~ 50 변수의 스쿠프 관련. 옛날에 적었던 https://blog.benelog.net/1382604.html 글이 생각났다.
p115 ArrayList vs LinkedList
감상 2022.09.05 책도 얇은 편이지만 재미가 있어서 중간에 끊지를 못하고 끝까지 읽었던 기억이 있습니다. 웹 어플케이션의 구조를 어떻게 잡을지는 프로젝트마다 매번하는 고민인데, 이 고민에 생각할 거리를 더 던져주는 점에서 유익했습니다. 엉클밥 아저씨의 ‘클린 아키텍처'가 코드가 없어서 아쉬웠던 점을 이 책에서 많이 채워주는 면도 있습니다.
이 책에서 권장하는 구조가 꼭 정답은 아닐 수도 있습니다. 이 책에서 제시한 ‘계층형 아키텍처'의 문제점이 계층형을 쓰면서 극복이 불가능한 문제는 아닐수도 있다는 생각도 듭니다. 책에서 제시한 persistent layer와 serice layer의 의존관계 역전을 실무 사례를 아직까지 못 본적은 없습니다.
인상깊은 단락 서문 반면, 좋은 설계는 이렇나 복잡한 특징을 활용할 기회를 만들어 줄 수 있다.
p2 모델은 대상을 단순화한 것이다. 즉, 모델을 어떤 사실을 해석한 것으로 볼 수 있고, 당명한 문제를 해결하는 것과 관련된 측면을 추상화하고 그 밖의 중요하지 않은 세부사항에는 주의를 기울이지 않는다.
p3 도메인 모델은 어떤 특정한 다이어그램이 아니라 다이어그램이 전달하고자 하는 아이디어다. 도메인 모델은 단지 도메인 전문가의 머릿속에만 존재하는 지식이 아니라 해당 지식을 엄격하게 구성하고 선택적으로 추상화한 것이다.
인상 깊은 단락 맥락에 따라 이해해야하므로 책을 사서 전문을 꼭 읽어봐야한다.
들어가며 과학적 패러다임과 프로그래밍 패러다임과 차이점
p3 우리가 사용하는 패러다임은 ‘한 시대의 사회 전체가 공유하는 이론이나 방법, 문제의식 체계'를 의미한다.
p5 프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다. 또한 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다.
p6 쿤은 상이한 두 가지 패러다임이 있을 때 두 패러다임은 함께 존재할 수 없다고 주장했다.
도메인 주도 설계 핵심 : 핵심을 간추린 비즈니스 중심의 설계로 소프트웨어 개발 프로젝트 성공하기
인상깊은 단락 67p 문서 자체는 도메인 모델이 아니다. 더 정확히 말하면 도메인 모델 개발을 두와주는 도구일 뿐이다.
### 129p
규칙2 : 작은 애그리게잇을 설계하라.
정리 116쪽 MSDN 원문일부 (https://msdn.microsoft.com/en-us/library/27db6csx%28v=vs.90%29.aspx)
In an “is a” relationship, the derived class is clearly a kind of the base class.
인상싶은 내용 31쪽 외부의 도움을 무시한 채 모든 것을 스스로 처리하려고 하는 전지전능한 객체(god object)는 내부적인 복잡도에 의해 자멸하고 만다.
68쪽 소프트웨어 안에 구축되는 객체지향 세계는 현실을 모방한 것이 아니다. 현실의 모습을 조금 참조할 뿐 궁극적인 목적은 현실과 전혀 다른 새로운 세계를 창조하는 것이다. 또한 객체지향 세계는 현실의 추상화가 아니다. 오히려 객체지향 세계의 거리는 현실 속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다.
131쪽 이름에서 풍기는 늬앙스와는 달리 테스트-주도 개발은 테스트 작성이 아니다.
감상 몇년전에 이 책을 봤을 때에는 ‘상식적인 내용을 체계적으로 잘 정리했군’ 정도로 큰 감흥이 없었다. 그런데 상식이라고 생각한 것을 결론으로 내든 근거로 쓰든 간에, 여러 상식을 묶어서 다른 이를 설득하려면 체계성이 가장 중요하다는 것을 이제서야 조금 깨닳은 듯 하다.
감상 SOA는 구체적인 기술이 아니라, 구조를 의미한다.
SOA를 하기 위해서 꼭 특정기술을 써야한다는 주장만이 들리고 있고, 다른 선택을 말할 수 없는 상황이라면, 시스템의 이해관계자 중 솔류션 벤더사나 특정 개발 조직의 이익만이 정치적으로 관철되어 있는 상황이 아닐까?
인상깊은 부분 20쪽 SOA는 엔터프라이즈 기술 표준이 아니다. 이는 SOA가 IIOP나 SOAP 같은 특정 단일 기술 프로토콜에 의존적이지 않다는 것을 의미한다. 대신 SOA는 아키텍처 청사진을 뜻하여, 이는 많은 상이한 기술들을 통합할 수 있고, 특정 프로토콜이나 연계기술을 요구하지 않는다는 것을 의미한다.
감상 시간이 지나서 다소 빛이 바랜 내용도 있지만, 이 책이 2002년도에, 그것도 당시 32살정도였던 사람이 썼다니 감탄이 나올 뿐이다.
인상 깊은 단락 p120 Strictly seaping, this is a special case of the Strategy design pattern: it appears different because the interfaces involved are so simple. )
인상 싶은 부분 Chapter 2 (번역판 p109) 유즈케이스는 새로 만든 시스템이나 소프트웨어 변경 사항에 대한 요구사항을 찾아내는 방법입니다. 각 유즈케이스는 특정목표를 달성하기 위해 시스템이 사용자 또는 다른 시스템과 어떻게 상호작용하는지를 전달하는 하나 이상의 시나리오를 제공합니다.
https://www.yes24.com/Product/Goods/108192370
2판에서 달라진점 페이지별 제목이 큰 흐름 맥락에서의 목적을 드러내는 방식으로 바뀌고 기존 제목은 작게 표시 예: 바뀌는 부분을 찾아내봅시다 -> 최첨단 피자코드 만들기(바뀌는 부분을 찾아내봅시다) 복습하거나 중간에 있는 내용을 찾아보기에는 더 편해진 느낌이다. 낱말퀴즈가 전반적으로 바뀌어 있음. 2장 옵져버 패턴 java.util.Observer를 쓰던 예제가 2판에서는 직접 정의한 인터페이스를 쓰도록 변경 Java8이후에는 java.util.Observer 등이 거의 안 쓰인다는 설명도 추가 됨. 5장 싱글턴 패턴 Q&A에서 2가지 질문 추가 (p218) 리플렉션, 직렬화 역질력화에서의 문제는 없는지 느슨한 결합 원칙에 위배되지 않는지 Enum을 이용한 싱글턴 구현 소개 (p219) 6장 커맨드 패턴 구상 커맨트 객체를 람다 표현식으로 바꾸는 예제 추가 (p250) Swing 예제로도 커맨드 패턴 설명 (p265, p270) 7장 템플릿 메서드 Applet 예제를 AbstractList를 활용하는 예제로 대체 (p343) 8장 반복자 패턴, 컴포지트 패턴 Iterable 인터페이스, 향상된 for 구문에 대한 설명 추가 (p377-379) 복합 반복자, 널 반복자 등의 내용은 삭제됨 (1판의 p406~p413) 패턴과 설명 연결 퀴즈에서 스테이트 패턴이 빠지고 전략 패턴이 들어감(1판 p417, 2판 p409) 11장 프록시 패턴 동적 클래스 다운로딩 방식 설명 삭제(1판 p486) 인터페이스 이름 변경 PersonBean -> Person (1판 p513-514, p517, 2판 p504-505, p508) Q&A에서 RMI관련 질문 2개 삭제(1판 p524, 2판 p514) 정리 7장 템플릿 메서드 Array.
http://www.yes24.com/Product/Goods/2160417
프리팩토링: 효과적인 시스템 설계와 변경을 위한 프리팩토링 지침 65가지
인상 깊은 단락 94쪽 테스트될 수 없다면, 요구하지도 말라.
128쪽 간단한 일을 잘하면 자주 불릴 것이다. 특정한 일을 수행하는 메서드가 클래스가 더 자주 재사용될수 있다.
151쪽 많은 원칙들을 생략할 수록 목표를 좀더 빨리 달성할 수 있을 것이라는 착각에 빠지게 된다. 이는 더 많은 코드를 작성하려고 먹는 시간을 줄이는 것과는 다르다. 먹지 않으면 결국 나중에 후회하게 될 것이다.