본문 바로가기

전체 글

 (117)
웹은 고전적인 검은 백조였다. 실용주의 사고와 학습을 다시 읽으면서 좋아했던 부분이 기억이 나서 그 부분을 정리해 봤다. 5장의 1절 부분 인지적 편향 관련 글인데 평소에 관심이 있던 내용들이고 내가 좋아했던 나심 탈레브가 쓴 블랙스완을 인용해서 기억에 더 남았다. 어떻게 보면 내가 이렇게 이 부분만 쓰 고 정리하는 것도 확증 편향의 사례라고 볼 수 있지 않을까 먼저 표상적 축소 오류를 간단히 정리하면 책에서 계속 이야기한 L모드(언어, 분석, 상징, 추상, 추론, 논리, 선형)는 복잡한 물체나 시스템을 나타내는 간편한 표상을 좋아함. 그러면 어쩔 수 없이 미묘한 부분은 놓치게 되고 때떄로 문제의 본질을 놓칠 수 있음. 예측 실패 표상적 축소로 인해 생기는 유해한 문제가 있음. 원래 뇌가 현실의 복잡성을 이해할 수 있는 방법은 표상으..
동적인 협력, 정적인 코드 이번에도 오브젝트 부록을 정리했는데 마지막 부록이다. 이 책에서 계속 강조하는 협력에 대해서 종합적으로 정리한다. 책 전반적인 부분을 요약하는 내용이 있어서 복습도 되고 좋았다. 동적인 협력, 정적인 코드 객체는 동적임. 프로그램은 정적임. 객체는 시간에 따라 다른 객체와 협력하며 계속 변화함. 프로그램은 고정된 텍스트라는 형식 안에 갇혀 있으면서도 객체의 모든 변화 가능성을 담아야 함. 객체지향 프로그램을 위한 2가지 모델이 있음 하나는 실행 구조를 표현하는 동적모델, 다른 하나는 코드의 구조를 담는 정적 모델임. 동적 모델은 객체와 협력, 정적 모델은 타입과 관계로 구성됨. 책에서도 전반적으로 이야기했지만, 대부분의 사람들은 정적 모델을 중심으로 설계를 해나간다고 함. 하지만 동적모델이 더 중요하고 ..
계약에 의한 설계 오브젝트 책 부록 부분에 좋은 내용이 있어서 정리했다.인터페이스만으로는 객체의 행동에 관한 다양한 관점을 전달하기 어렵다는 것. 그래서 부수효과를 쉽고 명확하게 표현할 수 있는 커뮤니케이션 수단이 필요한데 그게 계약에 의한 설계임(Design By Contract)01. 협력과 계약부수효과를 명시적으로인터페이스를 통해서 메시지는 정의할 수 있지만, 객체 사이의 의사소통 방식은 정의할 수 없음. 시그니처를 통해 메시지 이름과 파라미터 목록은 전달하지만, 협력을 위해 필요한 약속과 제약은 인터페이스를 통해 전달할 수 없음.계약계약은 협력을 명확하게 정의하고 커뮤니케이션할 수 있는 범용적인 아이디어임. 객체 사이의 계약은 다음과 같음협력에 참여하는 각 객체는 계약으로부터 이익을 기대하고 이익을 얻기 위해 의무..
부분적 경계 다음은 클린 아키텍처 24장을 정리한 내용 아키텍처 경계를 완벽하게 만드는 데는 비용이 많이 든다. 쌍방향 다형적 Boundary 인터페이스, Input과 Output 을 위한 데이터 구조를 만들어야 할 뿐 아니라, 두 영역을 컴파일하고 배포할 수 있는 컴포넌트로 격리하는 데 필요한 모든 의존성을 관리해야 함. 아래의 예시에서도 2가지 인터페이스를 사용해서 구현했음 많은 경우에 아키텍트들은 비용이 너무 크니까, 어느 정도 타협을 하면서 설계함. 애자일 커뮤니티에서는 YAGNI(You aren't going to need it) 같은 원칙을 위배하기 때문에 선행 적인 설계를 선호하지 않지만, 아키텍트라면 한 번쯤 언젠가 필요할 상활을 고민하는 게 좋음. 그렇다면 부분적 경계를 구현해 볼 수 있음 여기서는 ..
정책과 수준 그리고 업무 규칙 다음은 클린 아키텍처 19~20 장 정리한 내용이다. 19장 정책과 수준 소프트웨어 시스템이란 정책을 기술한 것이다. 실제로 컴퓨터 프로그램의 핵심부는 이게 전부다. 컴퓨터 프로그램은 각 입력을 출력으로 변환하는 정책을 상세하게 기술한 설명서임. 다시 한번 정리하면, 아키텍처 개발은 재편성된 컴포넌트들을 비순환 방향 그래프로 구성하는 기술을 포함함. 그래프에서 정점은 동일한 수준의 정책을 포함하는 컴포넌트에 해당함. 방향이 있는 간선은 컴포넌트 사이의 의존성을 나타냄. 간선은 다른 수준에 위치한 컴포넌트를 서로 연결함 이러한 의존성은 실제 소스 코드, 컴파일타임의 의존성임. 자바의 경우 import 문에 해당함. 좋은 아키텍처라면 각 컴포넌트를 연결할 때 의존성의 방향이 컴포넌트 수준을 기반으로 연결되도..
컴포넌트 응집도, 결합 13장 컴포넌트 응집도 어떤 클래스를 어느 컴포넌트에 포함시켜야 하나? 이거에 관련한 컴포넌트 응집도와 관련된 세 가지 원칙에 대해 다룸 REP: 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다 사실 재사용/등가 원칙은 너무 당연하게 여겨짐. 직관적으로만 봐도 릴리즈 번호가 다르면 컴포넌트들이 서로 호환되는지 보증할 방법이 없음. 이 원칙을 소프트웨어 설계와 아키텍쳐 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻함. 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스할 수 있어야 함. 하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 하며, 동일한 릴리즈 버전, 문서에 포함되어야 함. 이 뒤에 CCP와 CRP는 REP를 엄격하게, 하지만 제약..
프로그래밍 패러다임 클린 아키텍처를 읽다가 2부에서 프로그래밍 패러다임들에 대한 간략한 설명이 나오는데 근본적인 물음에 대한 답들을 해주는 부분이 있어서 정리를 했다. 3장 패러다임 개요 크게 3가지 패러다임을 간략하게 소개함. 구조적 프로그래밍, 객체 지향 프로그래밍, 함수형 프로그래밍. 이 외의 패러다임은 없고 다시는 나오지 않을 거라 함. 각 패러다임을 한 줄로 정리하면 다음과 같음 구조적 프로그래밍: 제어흐름의 직접적인 전환에 대해 규칙을 부과한다 객체지향 프로그래밍: 제어흐름의 간접적인 전환에 대해 규칙을 부과한다 함수형 프로그래밍: 할당문에 대해 규칙을 부과한다. 구체적으로는 다음 장들에서 하나씩 다룸. 그럼 왜 이 패러다임들 외에는 다른건 나오지 않을 거라고 했나? 각 패러다임을 보면 프로그래머에게 제약을 걸면..
계층형 설계 1,2 chapter 8 계층형 설계 1 계층형 설계는 코드를 추상화 계층으로 구성함. 각 계층이 다른 계층에 구체적인 내용을 몰라도 됨. 8,9장에 걸쳐 계층형 설계를 구현하는 방법을 소개하는데 여기서는 직접 구현 방식을 소개함. 이게 특별한 게 아니고 이름처럼 특정 기능을 직접 구현하는 거임. 목적은 특정 계층이 의존하는 계층과의 차이가 크지 않게 구현하는거임. 정석은 현재 계층이 바로 밑에 계층에만 의존하게 만드는 거임. 여기서는 가장 아래 계층을 자바스크립트 기본함수들 계층 으로 두고. 그 위에 하나씩 계층을 쌓아 올림. 이렇게 하면 일반화된 함수도 뽑힐 테고, 그걸 재사용하는 계층이 자연스럽게 생김. 또한 호출 그래프를 보여주면서 쉽게 계층을 파악하는 예시를 제공함. 그리고 단순히 '중복 코드'를 찾기..

티스토리툴바