전체 글 129

[개발서적] Clean Architecture 4부(ch12~14) 요약

Ch12. 컴포넌트 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 각 언어별 컴포넌트 단위를 보면Java : jar루비: gem닷넷: DDL모든 언어에서 컴포넌트는 배포할 수 있는 단위 입자다. 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있다. 또는 여러 컴포넌트를 서로 묶어서 .war 파일과 같은 단일 아카이브로 만들 수도 있다. 컴포넌트가 마지막에 어떤 형태로 배포되든, 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. [컴포넌트의 간략한 역사]소프트웨어 개발 초창기에는 메모리에서의 프로그램 위치와 레이아웃을 프로그래머가 직접 제어했다.따라서 로드할 메모리의 위치를 정하는 일..

Book Notes 2025.11.26

[개발서적] Clean Architecture 3부(ch7~11) 요약

Ch7. SRP: 단일 책임 원칙 SOLID 원칙 중에서 그 의미가 가장 잘 전달되지 못한 원칙은 바로 단일 책임 원칙이다.역사적으로 SRP는 아래와 같이 기술되어 왔다. 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다. 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다.SRP에서 말하는 ‘변경의 이유’란 바로 이들 사용자와 이해관계자를 가리킨다.좀더 명확한 SRP의 최종 버전은 아래와 같다.하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다. 그럼 ‘모듈’이란 또 무슨 뜻인가? 가장 단순한 정의는 바로 소스 파일이다.대부분의 경우 이 정의는 잘 들어 맞는다. ‘응집된’이라는 단어가 SRP를 암시한다. 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 바로 응집성이다..

Book Notes 2025.11.16

[개발서적] Clean Architecture 6. 함수형 프로그래밍

여러 가지 의미로, 함수형 프로그래밍이라는 개념은 프로그래밍 그 자체보다 앞서 등장했다.패러다임에 핵심이 되는 기반은 람다 계산법으로, 알론조 처치가 1930년대에 발명했다. [정수를 제곱하기]함수형 프로그래밍이 무엇인지 설명하려면 몇 가지 사례를 보여주는게 가장 좋다. 25까지의 정수의 제곱을 출력하는 간단한 문제를 다뤄보자.먼저 자바 언어라면 아래와 같이 작성이 가능하다.public class Squint { public static void main(String args[]) { for (int i = 0; i 리스프에서 파생한 클로저는 함수형 언어로, 클로저를 이용하면 같은 프로그램을 다음과 같이 구현할 수 있다.(println (take 25 (map (fn [x] (* x x)) (r..

Book Notes 2025.11.10

[개발서적] Clean Architecture 5. 객체 지향 프로그래밍

나중에 살펴보겠지만, 좋은 아키텍처를 만드는 일은 객체 지향(Object-Oriented, OO) 설계 원칙을 이해하고, 응용하는데서 출발한다.그렇다면 대체 OO는 무엇인가? 이 질문에 대해 누군가는 “데이터와 함수의 조합”이라고 답할 수 있다.대체로 이런 방식으로 많이 설명되지만, 그다지 만족스러운 대답은 아니다.또한 이 질문에 흔히 “실제 세계를 모델링하는 새로운 방법”이라고들 답한다. 이는 기껏해야 얼버무리는 수준에 지나지 않는다. OO의 본질을 설명하기 위해 세 가지 주문에 기대는 부류도 있는데,캡슐화상속다형성이다. 이제 이들 세 가지 개념을 차례대로 살펴보자. [캡슐화]OO를 정의하는 요소 중 하나로 캡슐화를 언급하는 이유는 데이터와 함수를 쉽고 효과적으로 캡슐화하는 방법을 OO 언어가 제공하기..

Book Notes 2025.11.07

[개발서적] Clean Architecture 4. 구조적 프로그래밍

에츠허르 비버 데이크스트라는 1930년에 로테르담에서 태어났다.데이크스트라는 최초로 자신을 ‘프로그래머’라는 직업 명칭을 썼으며, 암스테르담의 수학센터에 취업한다. 데이크스트라는 진공관 시대에 자신의 경력을 시작했는데, 이 시대는 컴퓨터가 거대하고, 쉽게 손상되며, 느린 데다가 결과마저 믿을 수 없는, 그래서 극도로 제한적으로만 사용될 때였다. 이 초창기에는 프로그램을 바이너리로 또는 매우 투박한 기계어를 이용해서 작성했다.데이크스트라는 이처럼 원시적인 환경에서 위대한 발견을 해냈다. [증명]데이크스트라가 초기에 인식한 문제는 프로그래밍은 어렵고, 프로그래머는 프로그래밍을 잘하지 못한다는 사실이다.데이크스트라는 증명이라는 수학적인 원리를 적용하여 이 문제를 해결하고 하였다. 데이크스트라는 이 연구를 진행..

Book Notes 2025.11.04

[개발서적] Clean Architecture 3. 패러다임 개요

이 장에서는 세 가지 패러다임인 구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍에 대해 설명한다. [구조적 프로그래밍]최초로 적용된 패러다임(하지만 최초로 만들어진 패러다임은 아닌)은 구조적 프로그래밍이다.1968년 에츠허르 비버 데이크스티라가 발견했으며, 무분별한 점프(goto 문장)는 해롭다는 사실을 제시했다. 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. [객체 지향 프로그래밍]두 번째로 도입된 패러다임은 구조적 프로그래밍보다 사실 2년 앞선 1966년, 요한 달과 크리스텐 니가드에 의해 등장했다. 이들 두 프로그래머는 알골 언어의 함수 호출 스택 프레임을 힙으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견했다...

Book Notes 2025.11.04

[개발서적] Clean Architecture 2. 두 가지 가치에 대한 이야기

모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공한다. 바로 행위(behaivor)와 구조(structure)가 그것이다. [행위]소프트웨어의 첫 번째 가치는 바로 행위다. 프로그래머를 고용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서다. 예를 들어프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다.이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성한다.만약 기계가 이러한 요구사항을 위반하면 프로그래머는 디버거를 열고 문제를 고친다.많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각한다. 슬픈 일이지만 그들은 틀렸다. [아키텍처]소프트웨어의 두 번째 가치는 ‘소프트웨어(software)’..

Book Notes 2025.11.01

[개발서적] Clean Architecture 1. 설계와 아키텍처

설계(design)과 아키텍처(architecture)의 사이에는 오랫동안 많은 혼란이 있었다. 설계란 무엇인가? 아키텍처는? 둘의 차이는? 결론적으로 얘기하면 둘은 아무 차이가 없다. 새로운 집을 설계하는 아키텍트가 있다고 하자.이 집은 모든 고수준의 결정사항을 지탱하는 모든 세부사항을 자세하게 확인할 수 있다. 이러한 저수준의 세부사항과 고수준의 결정사항은 집의 전체 설계의 구성요소가 된다. 소프트웨어 설계도 마찬가지다.저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다.고수준에서 저수준으로 향하는 의사결정의 연속성만 있을 뿐이다. [목표는?]그렇다면 이러한 의사결정의 목표는? 좋은 소프트웨어의 목표는?소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는..

Book Notes 2025.11.01

[개발서적] Clean Code 17. 냄새와 휴리스틱

❓휴리스틱?더보기휴리스틱은 정보가 불충분하거나 시간이 부족할 때, 경험과 직관에 의존하여 신속하게 결론을 내리거나 문제를 해결하는 방법을 말한다.이는 '발견법' 또는 '어림짐작'이라고도 불리며, 정확한 답보다는 현실적인 만족을 목표로 하는 경우가 많다.아래 목록은 다양한 프로그램을 검토하고 리팩터링하면서 만들었다.프로그램을 수정할 때마다 나는 “왜?”라고 자문한 다음 그 답을 기록했다.코드를 읽으면서 나쁜 냄새를 정리하다보니 목록이 상당히 길어졌다. [주석]C1: 부적절할 정보다른 시스템(예를 들어 소스 코드 관리 시스템, 버그 추적 시스템, 이슈 시스템 등)에 저장할 정보는 주석으로 적절하지 못하다.일반적으로 작성자, 최종 수정일 ,SRP(Software Problem Report) 번호 등과 같은 메..

Book Notes 2025.10.28

[개발서적] Clean Code 15. Junit 들여다보기

[JUnit 프레임워크]JUnit의 저자는 많다. 하지만 시작은 켄트 백과 에릭 감마, 두 사람이다.우리가 살펴 볼 모듈은 문자열 비교 오류를 파악할 때 유용한 코드다. 목록 15-2 ComparisonCompactor.java(원본)package junit.framework;public class ComparisonCompactor { private static final String ELLIPSIS = "..."; private static final String DELTA_END = "["; private static final String DELTA_START = "]"; private int fContextLength; private String fExpected; private ..

Book Notes 2025.10.28