품목정보
발행일 | 2019년 08월 20일 |
---|---|
쪽수, 무게, 크기 | 432쪽 | 825g | 172*225*30mm |
ISBN13 | 9788966262472 |
ISBN10 | 8966262473 |
발행일 | 2019년 08월 20일 |
---|---|
쪽수, 무게, 크기 | 432쪽 | 825g | 172*225*30mm |
ISBN13 | 9788966262472 |
ISBN10 | 8966262473 |
ETS 토익 정기시험 기출문제집 1000 Vol.3 READING 리딩
16,020원 (10%)
ETS 토익 정기시험 기출문제집 1000 Vol.3 LISTENING 리스닝
16,020원 (10%)
2023 큰별쌤 최태성의 별별한국사 한국사능력검정시험 심화(1,2,3급) 상
13,950원 (10%)
2023 큰별쌤 최태성의 별별한국사 한국사능력검정시험 심화(1,2,3급) 하
13,500원 (10%)
=== 1부 소개 === 1장 설계와 아키텍처란? __목표는? __사례 연구 __결론 2장 두 가지 가치에 대한 이야기 __행위 __아키텍처 __더 높은 가치 __아이젠하워 매트릭스 __아키텍처를 위해 투쟁하라 === 2부 벽돌부터 시작하기: 프로그래밍 패러다임 === 3장 패러다임 개요 __구조적 프로그래밍 __객체 지향 프로그래밍 __함수형 프로그래밍 __생각할 거리 __결론 4장 구조적 프로그래밍 __증명 __해로운 성명서 __기능적 분해 __엄밀한 증명은 없었다 __과학이 구출하다 __테스트 __결론 5장 객체 지향 프로그래밍 __캡슐화? __상속? __다형성? __결론 6장 함수형 프로그래밍 __정수를 제곱하기 __불변성과 아키텍처 __가변성의 분리 __이벤트 소싱 __결론 === 3부 설계 원칙 === 7장 SRP: 단일 책임 원칙 __징후 1: 우발적 중복 __징후 2: 병합 __해결책 __결론 8장 OCP: 개방-폐쇄 원칙 __사고 실험 __방향성 제어 __정보 은닉 __결론 9장 LSP: 리스코프 치환 원칙 __상속을 사용하도록 가이드하기 __정사각형/직사각형 문제 __LSP와 아키텍처 __LSP 위배 사례 __결론 10장 ISP: 인터페이스 분리 원칙 __ISP와 언어 __ISP와 아키텍처 __결론 11장 DIP: 의존성 역전 원칙 __안정된 추상화 __팩토리 __구체 컴포넌트 __결론 === 4부 컴포넌트 원칙 === 12장 컴포넌트 __컴포넌트의 간략한 역사 __재배치성 __링커 __결론 13장 컴포넌트 응집도 __REP: 재사용/릴리스 등가 원칙 __CCP: 공통 폐쇄 원칙 __CRP: 공통 재사용 원칙 __컴포넌트 응집도에 대한 균형 다이어그램 __결론 14장 컴포넌트 결합 __ADP: 의존성 비순환 원칙 __하향식(top-down) 설계 __SDP: 안정된 의존성 원칙 __SAP: 안정된 추상화 원칙 __결론 === 5부 아키텍처 === 15장 아키텍처란? __개발 __배포 __운영 __유지보수 __선택사항 열어 두기 __장치 독립성 __광고 우편 __물리적 주소 할당 __결론 16장 독립성 __유스케이스 __운영 __개발 __배포 __선택사항 열어놓기 __계층 결합 분리 __유스케이스 결합 분리 __결합 분리 모드 __개발 독립성 __배포 독립성 __중복 __결합 분리 모드(다시) __결론 17장 경계: 선 긋기 __두 가지 슬픈 이야기 __FitNesse __어떻게 선을 그을까? 그리고 언제 그을까? __입력과 출력은? __플러그인 아키텍처 __플러그인에 대한 논의 __결론 18장 경계 해부학 __경계 횡단하기 __두려운 단일체 __배포형 컴포넌트 __스레드 __로컬 프로세스 __서비스 __결론 19장 정책과 수준 __수준 __결론 20장 업무 규칙 __엔티티 __유스케이스 __요청 및 응답 모델 __결론 21장 소리치는 아키텍처 __아키텍처의 테마 __아키텍처의 목적 __하지만 웹은? __프레임워크는 도구일 뿐, 삶의 방식은 아니다 __테스트하기 쉬운 아키텍처 __결론 22장 클린 아키텍처 __의존성 규칙 __전형적인 시나리오 __결론 23장 프레젠터와 험블 객체 __험블 객체 패턴 __프레젠터와 뷰 __테스트와 아키텍처 __데이터베이스 게이트웨이 __데이터 매퍼 __서비스 리스너 __결론 24장 부분적 경계 __마지막 단계를 건너뛰기 __일차원 경계 __퍼사드 __결론 25장 계층과 경계 __움퍼스 사냥 게임 __클린 아키텍처? __흐름 횡단하기 __흐름 분리하기 __결론 26장 메인(Main) 컴포넌트 __궁극적인 세부사항 __결론 27장 ‘크고 작은 모든’ 서비스들 __서비스 아키텍처? __서비스의 이점? __야옹이 문제 __객체가 구출하다 __컴포넌트 기반 서비스 __횡단 관심사 __결론 28장 테스트 경계 __시스템 컴포넌트인 테스트 __테스트를 고려한 설계 __테스트 API __결론 29장 클린 임베디드 아키텍처 __앱-티튜드 테스트 __타깃-하드웨어 병목현상 __결론 === 6부 세부사항 === 30장 데이터베이스는 세부사항이다 __관계형 데이터베이스 __데이터베이스 시스템은 왜 이렇게 널리 사용되는가? __디스크가 없다면 어떻게 될까? __세부사항 __하지만 성능은? __개인적인 일화 __결론 31장 웹은 세부사항이다 __끝없이 반복하는 추 __요약 __결론 32장 프레임워크는 세부사항이다 __프레임워크 제작자 __혼인 관계의 비대칭성 __위험 요인 __해결책 __이제 선언합니다 __결론 33장 사례 연구: 비디오 판매 __제품 __유스케이스 분석 __컴포넌트 아키텍처 __의존성 관리 __결론 34장 빠져 있는 장 __계층 기반 패키지 __기능 기반 패키지 __포트와 어댑터 __컴포넌트 기반 패키지 __구현 세부사항엔 항상 문제가 있다 __조직화 vs. 캡슐화 __다른 결합 분리 모드 __결론: 빠져 있는 조언 === 7부 부록 === 부록 A 아키텍처 고고학 |
클린코드라는 유명한 저자의 책이라 뒤늦게 구입했습니다.
추천합니다.
하지만 프로그램을 제대로 만드는 일은 전혀 다르다. 소프트웨어를 올바르게 만드는 일은 어렵다. 소프트웨어를 제대로 만들려면 적정 수준의 지식과 기술을 겸비해야 하지만 대다수의 젊은 프로그래머는 이 수준에 도달하지 못했다. 또한 사고력과 통찰력을 갖춰야 하지만 대다수의 프로그래머는 시간을 들여 이러한 능력을 개발하지 않는다. 그리고 어느 정도의 훈련과 헌신이 필요하지만, 대다수의 프로그래머는 훈련과 헌신이 필요하리라는 생각 조차 하지 않는다. 소프트웨어를 올바르게 만들려면 무엇보다도 기술을 향한 열정과 전문가가 되려는 열망이 필수다.
2019년에 출간된 클린 아키텍처. 읽어야지.. 속으로 생각하기만 수십번...
작년은 무엇인가 정신없었고, 한참을 달리다 잠시 쉬는 해가 필요할 것 같아 기술서적을 잠시 내려놓았던 시기였다. 올해의 첫 시작으로 읽은 책이다. 로버트 C 마틴의 도서는 여러 책을 읽었고, 좋아하는 개발자이자 저자이다. 많은 사람들이 그의 이름을 듣고, 그의 책을 읽어보았을거라고 생각된다. 그 만큼 유명하고 많은 개발자들에게 큰 도움을 주는 개발자이다.
아키텍처에는 오래전부터 관심이 있었지만 주먹구구식 학습과 경험을 토대로 역량을 쌓아올려간 시간들이 많았다. 그러면서 다양한 사람들과 토론하면서 느낀 점은 아키텍처에 좋은 아키텍처를 있어도 정답은 없다는 것이다. 뭐 물론 시간대대로 정립되어오며 특정 요구사항이나 특정 기능을 수행하는 소프트웨어를 개발할 시 가장 좋은 아키텍처가 정답으로 여겨지기도 한다. 각 개발자마다 경험과 가진 지식을 토대로 본인만의 신념과 주관을 가지고 있다는 점이다. 나 또한 마찬가지였던 것 같다. 좋은 구조를 설계하는 과정에서 소프트웨어 요구사항을 분석하지만 분석한 내용을 토대로 가장 중요한 기능적, 비기능적 요구사항을 도출해내는 것은 개발자마다 모두 다르다.
이 책은 소프트웨어 아키텍처의 기본입문서다. 소프트웨어 아키텍처를 설계하기 위한 아키텍트가 되는 과정 중 위에서 설명한 개발자들 마다 각기 다른 주관에서 공통된 부분을 뽑아서 책으로 잘 정리해놓은거라 생각한다.
어떤 구조가 정답이다. 가장 좋다라고 논의하기는 어렵지만 아키텍트로서 시작을 하는 이에게 놓칠 수 있는 부분들을 잘 정리해놓았다. 특히 3부까지는 어느정도 경험이 있는 쥬니어 이상의 개발자라면 잘 알고 활용하는 설계원칙 SOLID 정도는 모두가 아는 내용일 수 있다. 하지만 내 경험 상 마이크로 모듈 이상의 컴포넌트로 확장된 내용을 설계가 필요한 상황에서는 허둥지둥하는 개발자들을 본 적이 많다. 특히 고려해야 할 사항들을 놓치거나 고려할 필요가 없는 상세내역에 대해 시간을 많이 소모하는 개발자들을 보았다. 그런 분들을 위해서 4부 컴포넌트 원칙부터는 꼼꼼히 읽고 개인의 생각을 정리하면 좋을 것 같고 추천한다.
나도 아키텍트로서 경험과 역량이 부족하고 지식이 하나로 정립되고 나 스스로의 신념과 주관이 명확히 확립되어 가는 시기에서 놓쳐버릴 수 있는 부분을 이 책을 읽고 다시 떠올릴 수 있었다.
출처: https://sonseungha.tistory.com/555 [Developer's Delight]