티스토리

Chamy's Blog

검색하기

블로그 홈

Chamy's Blog

chamy619.tistory.com/m

Chamy619 님의 블로그입니다.

구독자: 1

방명록 방문하기

주요 글 목록

28장 테스트 경계 테스트는 시스템의 일부이며, 아키텍처에도 관여한다. 시스템 컴포넌트인 테스트 아키텍처 관점에서 모든 테스트는 모두 동일하다. 테스트는 태생적으로 의존성 규칙을 따르고 세부적이고 구체적인 것이다. 따라서 테스트의 의존성은 항상 테스트 대상이 되는 코드를 향한다. 또한 테스트는 독립적으로 배포 가능하다. 테스트를 고려한 설계 테스트를 고려해 설계를 해야 하는 이유는 테스트가 시스템의 설계와 잘 통합되지 않으면 테스트가 깨지기 쉬워지고 그로 인해 시스템을 변경하기가 어려워지기 때문이다. 문제는 결합인데 테스트가 시스템 컴포넌트에 의존하므로 시스템 컴포넌트의 변화가 많은 테스트를 깨지게 만든다. 깨지기 쉬운 테스트는 시스템을 유연하지 못하게 만들고, 간단한 변경이 많은 테스트를 깨지게 만든다면 개발자는 변경을 .. 공감수 0 댓글수 0 2024. 1. 6.
27장 '크고 작은 모든' 서비스들 서비스를 사용한다고 상호 결합이 분리된다는 것과 개발과 배포 독립성을 지원한다는 것은 일부만 맞는 말이다. 서비스 아키텍처? 시스템 아키텍처는 의존성 규칙을 준수하며 고수준의 정책을 저수준의 세부사항으로 분리하는 경계에 의해 정의된다. 따라서 단순히 애플리케이션의 행위를 분리하는 서비스는 아키텍처 관점에서 중요하지 않다. 서비스의 이점? 결합 분리의 오류 시스템을 서비스들로 분리하면서 얻게 되는 이점은 서비스 사이의 결합이 확실히 분리된다는 점이다. 그러나 사실 이는 완전히 맞는 말은 아니다. 서로 네트워크로 공유되는 데이터들이 있을 것이고 이 데이터에 결합된다. 개발 및 배포 독립성의 오류 대부분 서비스를 분리하면 각 서비스별로 팀을 꾸리고 개발하고 유지보수하며 배포할 수 있을 것이라고 생각하지만, 항.. 공감수 0 댓글수 0 2024. 1. 6.
25장 계층과 경계 시스템은 주로 UI, 비즈니스 로직, 데이터베이스 세 가지 컴포넌트로 구성된다고 생각할 수 있지만, 대개 더 많은 컴포넌트로 구성될 수 있다. 마지막에 말하지만 쪼개려면 얼마든지 더 작은 컴포넌트들로 분리할 수 있다. 움퍼스 사냥 게임 움퍼스 사냥 게임은 간단히 GO EAST 와 SHOOT WEST 같은 명령어를 사용한다. 플레이어는 명령어를 입력하고, 컴퓨터는 명령어 기반으로 동작을 수행한다. 만약 영어로 되어 있는 현재 상태에서 한글 서비스를 추가하고 싶을 경우 어떻게 만들어야 할지 상상해보자. 명령을 내리는 부분과 게임을 구분하여 영어 UI, 한글 UI 에서 게임을 사용하면 된다. 추가로 기존에 메모리에 저장했던 것을 클라우드에 저장하고 싶은 요건이 생겼다면 클라우드 데이터가 게임을 호출하도록 하면.. 공감수 0 댓글수 0 2023. 10. 19.
24장 부분적 경계 아키텍처 경계를 분리하는 데는 비용이 많이 든다. 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들고 관리하기 위해서는 의존성 관리가 필수인데 많은 노력이 들어간다. 애자일 커뮤니티에 속한 사람 중 많은 사람들은 YAGNI 원칙에 위배된다고 말하며 경계를 만드는 것에 반대하기도 하지만, 아키텍처는 부분적 경계가 어쩌면 필요할지도 모른다고 생각한다. 마지막 단계를 건너뛰기 소스코드 레벨에서 모두 분리를 하지만, 컴포넌트를 분리하지 않으면 동시에 컴파일하고 배포할 수 있다. 하지만 완전히 독립되지 않은 형태이므로 의존성이 잘못된 방향으로 선을 넘을 가능성이 크다. 일차원 경계 인터페이스와 구현체를 분리해 일차원 경계를 만드는 것이다. Controller(C) -> Service(I) 공감수 0 댓글수 0 2023. 10. 2.
23장 프레젠터와 험블 객체 22장에서 다룬 클린 아키텍처는 험블 객체 구현체들로 가득 차 있다. 험블 객체 패턴 험블 객체 패턴은 디자인 패턴으로 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안되었다. 행위들을 테스트하기 쉬운 것은 남기고 테스트하기 어려운 것들을 모두 험블 객체로 옮긴다. GUI의 경우 각 요소가 필요한 위치에 위치하는 것은 테스트하기 어렵기 때문에 이를 Humble object 로 옮기고 쉽게 테스트할 수 있는 것만 뷰에 남기면 Humble object 는 뷰, 나머지는 프레젠터가 된다. 프레젠터와 뷰 뷰는 험블 객체이고 테스트하기 어렵다. 이 객체에 포함된 코드는 가능한 간단하게 유지한다. 뷰는 데이터를 GUI로 이동시키고 데이터를 직접 처리하지는 않는다.. 공감수 0 댓글수 0 2023. 9. 30.
22장 클린 아키텍처 육각형 아키텍처 포트와 어댑터라고도 알려져 있는 아키텍처로 외부에서 내부로 의존성이 향하고 각 계층에는 포트와 어댑터가 존재함 DCI: Data, Context and Interaction BCE: Boundary-Control-Entity 세 개의 아키텍처 모두 세부적인 면에서는 차이가 있어도 이들 모두의 목표는 관심사의 분리이다. 세 아키텍처 모두 소프트웨어를 계층으로 분리해 관심사 분리의 목표를 달성한다. 아키텍처의 목표 프레임워크 독립성 테스트 용이성 UI 독립성 데이터베이스 독립성 모든 외부 에이전시에 대한 독립성 의존성 규칙 모든 의존성은 프레임워크와 드라이버 -> 인터페이스 어댑터 -> 애플리케이션 업무 규칙 (유스케이스) -> 엔터프라이즈 업무 규칙 (엔티티) 방향을 따라야 한다. 엔티티 .. 공감수 0 댓글수 0 2023. 9. 30.
21장 소리치는 아키텍처 우리가 만드는 아키텍처는 우리가 무엇인지 소리쳐야 한다. 소리쳐야 하는 부분은 디렉터리 구조, 패키지에 담긴 소스파일이다. 그것이 무엇이라고 소리치는지 보자. 나는 헬스 케어 시스템이야 또는 재고 관리 시스템이야 라고 소리친다면 올바른 아키텍처지만, 만약 나는 스프링이야, 나는 ASP야 라고 소리친다면 이를 수정하는게 좋다. 아키텍처의 테마 애플리케이션 아키텍처는 유스케이스에 대해 소리쳐야 한다. 프레임워크에 대해 소리치고 있다면 유스케이스에 대해 소리치도록 바꿔보자. 프레임워크는 우리를 돕는 주체이지 우리가 맞춰야 하는 주체가 아니다. 아키텍처의 목적 좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에, 프레임워크나 도구, 환경에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 아무런 문제 없이 기술할.. 공감수 0 댓글수 0 2023. 9. 2.
20장 업무 규칙 업무 규칙은 수익을 얻거나 비용을 줄일 수 있는 규칙이다. 이는 컴퓨터로 구현됐을 수도 있고, 사람이 수동으로 하는 작업들이 될 수도 있다. 예를 들어 은행에서 대출에 N%의 이자를 붙인다는 것은 사람이 하던, 컴퓨터가 하던 업무 규칙이다. 대출에 이자를 붙인다는 것을 핵심 업무 규칙이라고 하고, 이러한 핵심 업무 규칙에는 대출 잔액, 이자율, 지급 일정과 같은 핵심 업무 데이터가 필요하다. 핵심 업무 규칙과 핵심 업무 데이터를 객체로 만든 것이 엔티티다. 엔티티 엔티티는 컴퓨터 시스템 내부 객체로 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구체화한다. 엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수로 구성된다. 엔티티는 입출력 장치 등과 같은 외부 .. 공감수 0 댓글수 0 2023. 8. 30.
19장 정책과 수준 좋은 시스템일수록 저수준 컴포넌트가 고수준 컴포넌트에 의존하도록 설계되어 있다. 수준 수준은 입력과 출력까지의 거리이다. 시스템의 입력과 출력과의 거리가 멀어질수록 정책의 수준은 높아진다. 입력과 출력을 다루는 정책은 시스템의 최하위 수준에 위치해야 한다. 따라서 고수준의 정책(비즈니스 로직)이 입출력 시스템에 영향을 받게 되어 있다면 잘못 설계된 경우일 가능성이 크다. 아래의 코드가 그렇다. function encrypt() { while (true) { writeChar(translate(readChar())); } } 고수준의 encrypt 함수가 저수준(입력과 출력을 담당하는)의 writeChar 와 readChar 에 의존성을 가지고 있다. 이러한 경우 입출력 시스템의 정책에 변화가 생긴다면 e.. 공감수 0 댓글수 0 2023. 8. 29.
18장 경계 해부학 시스템 아키텍처는 일련의 소프트웨어 컴포넌트와 그 컴포넌트들을 분리하는 경계에 의해 정의된다. 경계 횡단하기 '런타임에 경계를 횡단한다' 는 뜻은 경계 한쪽에 있는 기능이 반대편의 기능을 호출하는 것이다. 적절하게 경계를 횡단하는 방법은 소스코드 의존성 관리이다. 두꺼운 단일체 모놀리틱 구조에서는 대부분 다형성에 의존해 내부 의존성을 관리한다. 따라서 특히 객체 지향 패러다임이 중요해진다. 가장 단순한 형태의 경계 횡단은 저수준 클라이언트에서 고수준 서비스로 향하는 함수 호출이다. 이 경우 런타임 의존성과 컴파일 의존성 모두 저수준 컴포넌트에서 고수준 컴포넌트로 향한다. 배포형 컴포넌트 아키텍처의 경계가 물리적으로 드러나는 경우 배포형 컴포넌트다. 배포형 컴포넌트는 별도의 실행 파일이 존재해 배포 과정에.. 공감수 0 댓글수 0 2023. 8. 28.
17장 경계: 선 긋기 소프트웨어 아키텍처는 선을 긋는 기술이다. 이 선은 소프트웨어를 분리하고 이 선을 사이에 두고 한 쪽은 다른 쪽을 알지 못한다(반대는 알 수 있다). 결합을 줄이고 일찍 결정하지 않아도 되는 요소들을 나중으로 미루는 것이 선 긋기의 목표다. 어떻게 선을 그을까? 그리고 언제 그을까? 관련이 있는 것과 없는 것 사이에 선을 긋는다. GUI 와 비즈니스 로직은 관련이 없기 때문에 GUI 와 비즈니스 로직 사이에는 선이 그어져야 한다. 그리고 비즈니스 로직과 DB 사이에도 선이 그어져야 한다. 어떤 DB 를 사용하더라도 비즈니스 규칙이 그에 따라 변화되어서는 안된다. 이렇게 정하고 보면 인터페이스가 어떤 계층에 있어야 하는지 알게 된다. 기본적으로 스프링 컨트롤러 - 서비스 - 레포지토리 구조에서 DB 인터페.. 공감수 0 댓글수 0 2023. 8. 21.
16장 독립성 좋은 아키텍처가 지원하는 것들 유스케이스 운영 개발 배포 유스케이스 시스템 아키텍처는 반드시 시스템의 요구사항을 지원해야 한다. 명확한 이름을 짓는 것, 유스케이스 단위로 분리하는 것이 유스케이스를 지원하는 좋은 방법이 될 수 있다. 운영 운영시에 어떠한 환경이 필요한지에 대해 고민하다 보면 시스템마다 다른 아키텍처를 가져가게 된다. 어떤 시스템은 실시간 처리를 해야할 수도 있고, 어떤 시스템은 대용량의 데이터를 다루어야 할 수도 있다. 그리고 또 어떤 시스템은 트래픽이 많지 않아 단순한 요청만 처리하는 시스템일 수 있다. 각각의 특징마다 어떤 시스템은 마이크로 서비스로, 어떤 시스템은 모노리틱 구조로 구현하면 된다. 만약 모노리틱 구조로 시스템 아키텍처를 구현하더라도 소스 코드 단계에서 컴포넌트로 잘 .. 공감수 0 댓글수 0 2023. 8. 15.
15장 아키텍처란? 아키텍트는 프로그래밍 작업을 놓아서는 안된다. 아키텍트는 프로그래밍 작업을 통해 발생하는 문제를 경험하고 프로그래머를 지원하는 역할을 해야 한다. 시스템 아키텍처의 목표는 시스템을 쉽게 개발하고 배포하고 운영하며 유지보수 되도록 만드는 것이다. 시스템 아키텍처는 시스템이 제대로 동작하기를 최우선 목표로 삼는 것은 당연하나 아키텍처가 엉망이더라도 시스템은 제대로 동작할 가능성이 크다. 사실상 아키텍처는 운영보다 배포, 유지보수, 개발을 쉽게 하는데에 초점이 맞춰져야 한다. 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다. 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해준다. 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프.. 공감수 0 댓글수 0 2023. 8. 15.
14장 컴포넌트 결합 ADP: 의존성 비순환 원칙 간단히 말하면 컴포넌트 의존성 그래프에 순환이 있으면 안된다는 원칙이다. 최신 스프링 부트 버전에서는 컴포넌트는 아니더라도 빈의 의존성이 순환을 하게 되면 에러를 발생시킨다. 순환 의존성 제거 개발 환경을 릴리스 가능한 컴포넌트 단위로 분리한 후 컴포넌트별로 담당자 또는 담당팀을 지정한다. 컴포넌트가 동작 가능하도록 만들고 릴리스 번호를 부여해 다른 팀에서 사용할 수 있도록 만들면 다른 팀은 해당 컴포넌트를 사용하기만 하면 된다. 만약 새로운 릴리스 버전이 만들어졌다고 하면, 이것을 사용할지 이전 릴리스 버전을 사용할지는 전적으로 사용하는 사람의 몫이다. 따라서 사용하는 팀과 만드는 팀의 결합이 느슨해졌다. 이러한 구조를 잘 사용하기 위해서는 컴포넌트 의존성이 순환하지 않아야.. 공감수 0 댓글수 0 2023. 8. 4.
13장 컴포넌트 응집도 REP: 재사용/릴리즈 등가 원칙 재사용 단위는 릴리스 단위와 같다. REP는 당연한 것이다. 한 번에 같이 릴리즈 되어야 하는 클래스들이 한 곳에 뭉쳐야 하고, 이를 지키는 것은 너무나 당연해서 지키지 않았을 때 너무 많이 티가 난다. CCP: 공통 폐쇄 원칙 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어야 한다. 다른 말로 하면 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리해야 한다. CCP는 SRP 단일 책임 원칙을 컴포넌트 단위에서 작성한 것이다. CRP: 공통 재사용 원칙 CRP는 함께 재사용되는 경우가 많은 클래스와 모듈은 한 컴포넌트로 묶어야 한다고 말한다. 개별 클래스가 단독으로 사용되는 경우는 거의 없고 다른 클래스와 상호작용 하는 경우가 많다. CRP를 지키려면.. 공감수 0 댓글수 0 2023. 8. 2.
12장 컴포넌트 컴포넌트는 자바의 jar 파일과 같은 배포 단위이다. 여러 컴포넌트를 하나로 묶어서 아카이브로 만들 수도 있고, 각각의 컴포넌트를 독립적으로 배포할 수도 있다. 잘 설계된 컴포넌트는 반드시 독립적으로 배포 및 개발이 가능해야 한다. 프로그램이 커질수록 프로그램을 컴파일하고 실행하는데까지 점점 더 많은 시간이 소요되었다. 그러나 그것보다 더 빠르게 메모리의 속도가 빨라지고 가격이 저렴해지면서 이제는 링크 시간이 초 단위 수준이 되었다. 이후 액티브 X 와 공유 라이브러리 시대가 열렸고 이제는 jar 파일이나 DLL, 공유 라이브러리를 기존 애플리케이션에 플러그인 형태로 배포하는 것이 일상적인 일이 되었다. 현재 이 아키텍처가 컴포넌트 플러그인 아키텍처다. 공감수 0 댓글수 0 2023. 8. 1.
11장 DIP: 의존성 역전의 원칙 의존 관계에서 구체적인 모듈을 참조해서는 안되지만 이는 사실상 불가능하다. 자바의 String 클래스가 대표적인 예인데, String 클래스는 구체 클래스이나 대부분의 모듈에서 이에 의존한다. 따라서 우리가 의존하는 것을 피해야 할 것은 변동성이 큰 구체적인 요소이다. 안정된 추상화 인터페이스를 최대한 변경하지 않고 새로운 기능을 추가할 수 있는 방법을 가장 먼저 찾아라. 변동성이 큰 구현체에 의존하는 것을 최대한 피하고 안정된 추상 인터페이스를 의존해야 한다. 변동성이 큰 구체 클래스를 참조하지 말라 추상 팩토리 사용을 고려하라 변동성이 큰 구체 클래스로부터 파생하지 말라 상속은 가장 강력한 결합이다 구체 함수를 오버라이드 하지 말라 구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라 팩토리 소.. 공감수 0 댓글수 0 2023. 7. 31.
10장 ISP: 인터페이스 분리 원칙 ISP와 언어 정적 타입 언어는 import, use, include 등과 같은 선언문을 사용해야 한다. 이로 인해 소스 코드 의존성이 발생하는데, 루비나 파이썬과 같은 동적 언어는 이러한 의존성이 아예 없어서 정적 타입 언어를 사용할 때보다 결합도가 낮은 시스템을 만들 수 있다. ISP와 아케틱처 시스템을 만들 때 특정 프레임워크를 사용하기로 강제로 결정을 내리고, 해당 프레임워크는 특정 데이터베이스를 강제로 사용해야 한다면, 시스템은 결국 데이터베이스까지 의존성을 가지게 된다. 이는 데이터베이스에 변경사항이 발생하면 프레임워크도 재컴파일 및 재배포를 해야 하고, 그렇게 되면 시스템도 재컴파일 및 재배포를 해야 한다. 또한 시스템이 전혀 사용하지 않는 데이터베이스의 특정 기능이 문제를 일으키면 시스템에.. 공감수 0 댓글수 0 2023. 7. 1.
9장 LSP: 리스코프 치환 원칙 책에서 리스코프 치환 원칙을 위반하는 좋은 예제를 정사각형/직사각형 문제로 보여준다. 사각형이라는 인터페이스가 있고 사각형 인터페이스는 가로 설정, 세로 설정 메서드를 제공한다. 그리고 이를 구현한 구현체는 직사각형 구현체와 정사각형 구현체가 있다. 사용자가 사각형 인터페이스를 사용할 때, 가로 설정과 세로 설정을 모두 사용한다고 가정하면 정사각형의 구현체를 사용한 사람은 해당 메서드가 원하는대로 동작하지 않을 것이다. 사용하는 입장에서 사용하는 것의 정확한 구현체를 알아야 한다면 이는 리스코프 치환 원칙에 위배된다. LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야만 한다. 치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다. 공감수 0 댓글수 0 2023. 7. 1.
8장 OCP: 개방-폐쇄 원칙 소프트웨어 개체는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다. 의존성 방향이 향하는 것은 화살표가 시작하는 곳의 변경사항을 화살표가 향하는 곳에서 지키기 위해서다. 만약 A -> B 로 화살표가 향한다면, A의 변경사항이 B에 영향을 주지 않게 하기 위함이다. 따라서 가장 중요한 비즈니스가 담긴 로직은 화살표를 받기만 하는 것이 좋고, 세부 사항으로 내려갈 수록 다른 것들을 의존해야 한다. 이런 화살표를 제어할 수 있는 가장 좋은 방법이 Interface 를 사용하는 것이다. OCP는 시스템 아키텍처를 떠받치는 원동력 중 하나다. OCP의 목표는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는 데 있다. 이러한 목표를 달성하려면 시스템을 컴포넌트 단위.. 공감수 0 댓글수 0 2023. 7. 1.
7장 SRP: 단일 책임 원칙 단일 책임 원칙은 함수는 단 하나의 일만 해야 한다는 원칙이 아니라 사실은 "단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다." 라는 의미이다. 우발적 중복 단일 책임 원칙을 위반하는 대표적 사례인 우발적 중복을 살펴보자. Employee 클래스가 아래 세 가지 메서드를 가지고 있다. calculatePay() : 회계팀에서 기능을 정의하며, CFO 보고를 위해 사용 reportHours() : 인사팀에서 기능을 정의하며, COO 보고를 위해 사용 save() : 데이터베이스 관리자가 기능을 정의하며, CTO 보고를 위해 사용 calulatePay() 메서드와 reportHours() 메서드가 업무 시간을 계산하는 regularHours() 메서드를 동시에 사용한다고 했을때 CFO 팀에서 업무 .. 공감수 0 댓글수 0 2023. 6. 17.
6장 함수형 프로그래밍 함수형 프로그래밍이라는 개념은 프로그래밍보다 먼저 등장했다. 정수를 제곱하기 자바 언어에서 25까지 정수 제곱을 출력하려면 아래처럼 코드를 작성하면 된다. public class Squint { public static void main(String args[]) { for (int i = 0; i < 25; i++) { System.out.println(i*i); } } } 함수형 언어인 클로저는 아래와 같다. (println (take 25 (map (fn [x] (* x x)) (range)))) 위의 코드를 쪼개보면 (println (take 25 (map (fn [x] (* x x)) (range)))) 자바에서는 가변 변수인 i를 사용하지만 클로저에서는 가변 변수가 전혀 없다. 가변 변수처럼 .. 공감수 0 댓글수 0 2023. 6. 5.
5장 객체 지향 프로그래밍 좋은 아키텍처를 만드는 일은 객체 지향 설계 원칙을 이해하고 응용하는 데서 출발한다. 객체 지향이란? 데이터와 함수의 조합 실제 세계를 모델링하는 방법 캡슐화 상속 다형성 캡슐화? OO가 데이터와 함수를 쉽게 캡슐화하는 방법을 제공한다고 말하는데, 이는 잘못된 설명이다. OO를 기반으로 설계되지 않은 C 언어에서 오히려 더 완벽한 캡슐화를 제공한다. point.h struct Point; struct Point* makePoint(double x, double y); double distance(struct Point* p1, struct Point* p2); point.c #include "point.h" #include #include struct Point { double x, y; }; struc.. 공감수 0 댓글수 0 2023. 6. 5.
4장 구조적 프로그래밍 구조적 프로그래밍은 데이크스트라라는 네덜란드 프로그래머에 의해 만들어졌다. 증명 데이크스트라는 프로그래밍에도 수학의 증명을 도입하려고 했다. 프로그래머가 검증된 구조를 사용해 코드를 작성하여 이 코드가 올바르다는 사실을 스스로 증명하게 만드려고 했다. 이런 과정에서 goto 문은 단순 반복문/조건문으로 대체할 수 있다는 것을 발견했다. goto 문을 사용하면 증명을 하기가 어렵지만, 반복문/조건문은 세부 단위로 쪼갤 수 있고, 따라서 증명을 하기가 더 쉽다. 모든 프로그램을 순차, 분기, 반복이라는 세 가지 구조만으로 표현할 수 있다는 사실을 증명했다. 해로운 성명서 데이크스트라는 "goto문의 해로움"이라는 제목의 글을 썼고, 여기에 많은 사람들이 지지와 반대를 보냈다. 현재 살펴보면 goto 문은 코.. 공감수 0 댓글수 0 2023. 6. 5.
3장 패러다임 개요 이 장에서는 세 가지 패러다임인 구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍에 대해 다룬다. 구조적 프로그래밍 구조적 프로그래밍은 최초로 적용된 패러다임으로 goto 문은 if / then / else 와 do / while / until 문으로 대체해야 한다는 것이다. 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. 객체 지향 프로그래밍 객체 지향 프로그래밍은 함수 호출 스택 프레임을 힙으로 옮기면 지역 변수가 오랫동안 유지될 수 있음을 발견하고 만들어졌다. 이런 함수가 생성자가 되었고, 지역 변수는 인스턴스 변수, 중첩 함수는 메서드가 되었다. 함수 포인터를 특정 규칙에 따라 사용하는 과정을 통해 필연적으로 다형성이 등장했다. 객체 지향 프로그래밍은 제어흐름의 간접.. 공감수 0 댓글수 0 2023. 6. 5.
2장 두 가지 가치에 대한 이야기 소프트웨어 시스템은 이해관계자에게 행위와 아키텍처를 제공한다. 행위 이해관계자가 요구한 내용을 만족하는 코드를 작성하는 것을 행위라고 한다. 요약하자면 행위는 기능이다. 이들은 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다. 슬픈 일이지만 그들은 틀렸다. 아키텍처 소프트웨어는 부드러운 제품이다. 언제나 변경이 가능하고 유연해야 한다. 소프트웨어 개발 비용 증가는 변경사항의 범위에 달려있는데, 변경사항이 클수록, 시간이 오래 지날수록 개발 비용은 증가한다. 아키텍처는 변경하기 어려운 부분. 소프트웨어 큰 틀이라고 이해할 수 있다. 문제는 당연히 시스템 아키텍처다. 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다. 따라서 아.. 공감수 0 댓글수 0 2023. 6. 2.
1장 설계란 아키텍처란? 목표 좋은 소프트웨어 설계 목표는 필요한 시스템을 만들고 유지보수하는데 최소한의 비용과 인력이 투입되는 것이다. 만약 새로운 기능이 추가되는데 점점 더 많은 인력 또는 비용과 시간이 필요하다면 무언가 잘못되고 있는 것이다. 사례 연구 엉망진창이 되어 가는 신호 시스템을 급하게 만드는 것 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않을 경우 무엇이 잘못되었나? 현대의 개발자도 이와 비슷한 경주를 하며, 토끼와 유사한 과신을 드러낸다. 물론 개발자가 잠을 자는 것은 아니다. 오히려 정반대다. 현대의 대다수 개발자는 뼈 빠지게 일한다. 하지만 그들의 뇌는 잠에 취해 있다. 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고 있는 바로 그 뇌가 잠자고 있다. 시장에 출시하는 것이 먼저니까 .. 공감수 0 댓글수 0 2023. 6. 2.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.