IT Book Summary/Clean Architecture (16) 썸네일형 리스트형 05 아키텍처 - 1 15장 아키텍처란? 소프트웨어 아키텍트는 코드와 동떨어져서는 안되며, 팀원들이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어야 한다. 시스템을 구축했던 사람들이 만들어낸 시스템의 형태. 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수 되도록 만든다. 주된 목적은 시스템의 생명주기를 지원하는 것이다. 궁극적 목표는 시스템의 수명과 관련되 비용은 최소화하고, 프로그래머의 생산성은 최대화 하는데 있다. 개발 개발팀이 시스템을 쉽게 개발하도록 뒷받침. 작은 규모의 개발팀이라면 이러한 아키텍처 제약사항들이 방해가 된다고 느낄수도 있으나, 여러팀이 개발하고있다면 신뢰할 수 있는 안정된 인터페이스를 갖춘, 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않는다. .. 04 컴포넌트 원칙 -2 컴포넌틑 응집도와 관련된 세가지 원칙 REP: The Reuse/Release Equivalence Principle CCP: The Common Closure Principle CRP: The Common Reuse Principle 13장 컴포넌트 응집도 Component Cohesion REP: 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 릴리즈 번호가 없으면 재사용 컴포넌트들이 서로 호환되는지 보증할 수 없음. 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스 가능해야 함. CCP: 공통 폐쇄 원칙 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트에 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트에 분리 단일 컴포넌트는 변경의 이유가 여러.. 04 컴포넌트 원칙 -1 SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법이라면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법이다. 12장 컴포넌트 모든 언어에서 컴포넌트는 배포할 수 있는 단위 입자다. 자바의 경우 jar 파일, 루비는 gem 파일, 닷넷은 DLL, 컴파일형 언어는 바이너리 파일의 결합체, 인터프리터형은 소스파일의 결합체, 여러 컴포넌트를 서로 링크해 실행가능한 단일파일로 생성 가능하고, 여러 컴포넌트를 서로 묶어 .war 파일처럼 단일 아카이브로 생성도 가능. 컴포너트 각각을 독립적으로도 배포 가능. 컴포넌트의 역사 프로그래밍 초창기에는 프로그램을 메모리의 어느 위치에 로드할지 프로그래머가 직접 결정해야 했다. 라이브러리 함수 소스코드를 애플리케이션 코드에 직접 포함시켜 단일 프로그램으로 컴파일 했다. 프로그램.. 03 설계원칙 -2 10장 ISP: 인터페이스 분리 원칙 The Inteface Segregation Principle 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용. 이런 의존성으로 OPS 클래스에서 op2 소스코드가 변경되면 User1도 다시 컴파일한 후 배포해야함. 오퍼레이션을 인터페이스 단위로 분리하여 해결. ISP와 언어 정적타입 언어의 경우 include 선언문으로 소스코드 의존성이 발생함. 동적타입 언어는 선언문이 존재하지 않고 런타임에 추론이 발생. 따라서 소스코드 의존성이 존재하지 않아 유연하고 결합도가 낮은 시스템을 만들 수 있음. ISP와 아키텍처 필요이상으로 많은걸 포함하는 모듈에 의존하는 것은 해로움. 불필요한 재컴파일과 재배포를 강제하기 때문. 결론 불필요한 짐을 실은 무언가에 의존하면 예상못한.. 03 설계원칙 - 1 7장 SRP: 단일 책임 원칙 함수는 반드시 하나의 일만 해야한다는 원칙. 하나의 모듈은 하나의 오직한의 액터에 대해서만 책임져야 한다. 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 응집성 cohesion. 징후 1: 우발적 중복 단일클래스에 세 메서드가 배치되어 세 액터가 서로 결함됨. 변경이 일어날 경우 그것에 의존하는 무언가여 영향을 주게됨. 서로 다른 액터가 의존하는 코드를 너무 가까이 배치해서 발생하는 문제. SRP는 서로 다른 액터가 의존하는 코드를 서로 분리하라고 한다. 징후 2: 병합 병합은 항상 위험이 뒤따른다. 문제를 벗어나는 방법은 서로 다른 액터를 뒷받침하는 코드를 서로 분리하는 것. 해결책 메서드를 각기 다른 클래스로 이동시키는 방식. 아무런 메서드가 없는 간단한 데이터 구조인.. 02 벽돌부터 시작하기 : 프로그래밍 패러다임 - 2 4장 구조적 프로그래밍 에츠허르 비버 데이크스트라 - 진공관 시대의 이론물리학자, 최초의 프로그래머 증명 데이크스트라는 증명 Proof 수학적인 원리를 적용하여 프로그래밍의 문제를 해결하려고 했다. --> 유클리드 계층구조를 만드는 것. --> 입증된 구조를 이용하고, 이들 구조를 코드와 결합시켜, 코드가 올바르다는 사실을 스스로 증명하게 되는 방식. --> 순차 sequence, 분기 selection, 반복 iteration 이라는 세가지 구조만으로 표현할수 있다는 사실을 증명. 구조적 프로그래밍의 탄생 모듈을 증명 가능하게 하는 바로 그 제어구조가 모든 프로그램을 만들 수 있는 제어구조의 최소 집합과 동일하다는 사실. 해로운 성명서 데이크스트라가 견해 ""grto문 의 해로움" 이 글에서 세가지 제.. 02 벽돌부터 시작하기: 프로그래밍 패러다임 1945년 튜링은 사람이 식별가능한 형태의 실질적 프로그램을 컴퓨터에 코드로 작성했다. 바이너리 언어로 반복문, 분기문, 할당문, 서브루틴, 스택 등 우리에게 익숙한 구조를 사용했다. 어셈블리의 등장, 컴파일러 발명으로 수많은 언어가 탄생했다. 다른 혁신적 변화는 프로그래밍 패러다임의 등장이다. 패러다임은 언어에 독립적인 구조이다. 이런 패러다임에 세가지 종류가 있다. - 구조적, 객체지향, 함수형 프로그래밍. 3장 패더라임 개요 - 구조적 프로그래밍 최초로 적용된 패더라임 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. - 객체지향 프로그래밍 함수가 클래스의 생성자가 되고, 지역변수는 인스턴스 변수 그리고 중첩함수느 메서드가 되었다. 함수 포인터를 특정 규칙에 따라 사용하는 과정을.. 01 Introduction 우리는 어떻게 해야 미래에 어떤 변경을 하게될지 지금 알아내 중요한 결정을 구체적으로 내릴 수 있을까? 어떻게 하면 앞으로 개발에 들어갈 노력과 비용을 줄일 수 있을까? 아키텍처는 종착지가 아니라 여정에 더 가까우며, 고정된 산출물이 아니라 계속된 탐구 과정에 더 가까움을 이해해야 좋은 아키텍처가 만들어진다. 근본적으로 다른 다양한 시스템을 구축하고 경험한 작가가 깨달은 것. --> 아키텍처 규칙은 동일하다. 현재의 소프트웨어는 과거와 동일한 것들로 구성된다. 여전히 if문, 할당문, while 루프로 구성된다. 1950년대와 마찬가지로 코드는 여전히 sequence, selection, iteration의 집합체일 뿐. 언어는 조금 발전했고 도구는 좋아졌지만 프로그래밍을 이루는 기본 구성요소는 바뀌지않.. 이전 1 2 다음
