집에가고싶을때마다

•  About
•  Project
•  IT
•  Travel
•  ETC

두번째 책을 마치고 두번째 책은 클린 아키텍처, 클린 코드에 뒤이어서 '클린'이란 무엇일까라는 의문점을 풀기 위해 읽었다. 다 읽은 지는 약 이주가 되었지만 뒤늦게 후기를 남긴다. 결론부터 말하자면 클린 코드에 비해 클린 아키텍처는 더 포괄적이었다. 클린 코드는 포괄적이었지만 예시와 함께 말하고자 하는 바를 명확히 알 수 있었는데, 클린 아키텍처는 조금 어려웠다. 내가 아키텍처적인 지식이 부족한 것일까? 다시 한 번 읽어봐야 하는 것은 분명하다. 아키텍처 지식이 부족한 상태에서 읽은 책은 난해하고 어려웠을 뿐이다. 그래서 별점을 말하자만 2/5 이다. 클린 아키텍처는 설계 원칙에 대해 말한다. 클린 아키텍처의 기본, 설계원칙. 회사를 다니면서 설계원칙에 대해 깊게 생각할 수 없다. 설계 단계는 대부분 위..

Clean Architecture 6부, 세부사항 30장, 데이터베이스는 세부사항이다 아키텍처 관점에서 데이터베이스는 엔티티가 아님 > 데이터베이스는 소프트웨어일 뿐 데이터베이스는 결국 기술일 뿐, 최하위 유틸리티 함수를 제외하고는 데이터베이스에 대해서 몰라야 함 > 데이터베이스가 테이블 형태라는 것을 알게 되면, 데이터 구조에 결합하게 됨 > 디스크가 어떤 형식인지조차 인식하면 안됨 > 성능은 완전히 캡슐화하여 저수준의 데이터 메커니즘 단에서 다뤄야 함 31장, 웹은 세부사항이다 웹은 GUI이다. GUI는 계속 바뀐다. > 그러나 웹과 장치독립성은 어쩌면 비현실 적임 UI는 애플리케이션 사이의 추상화가 가능 - 업무 로직은 다수의 유스케이스로 구성 - 각 유스케이스는 사용 자를대신해서 일부함수를 수행 ..

클린 아키텍처 22장, 클린 아키텍처 육각형 아키텍처, DCI, BCE 등 다양한 아키텍처들은 모두 관심사 분리라는 목표를 가지고 있음 관심사 분리 - 프레임워크 독립성: 아키텍처는 프레임워크 존재 여부에 의존하지 않음 - 테스트 용이성: 업무 규칙은 UI, 데이터베이스, 웹서버 등의 외부 요인이 없어도 테스트 가능 - UI 독립성: 시스템의 나머지 부분을 변경하지 않아도 UI 쉽게 변경 - 데이터베이스 독립성: 오라클을 몽고DB, 빅테이블 등으로 변경 가능, 업무 규칙은 데이터베이스에 결합되지 않음 - 모든 외부 에이전시에 대한 독립성: 실제 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못함 의존성 규칙 각각의 동심원은 소프트웨어에서 서로 다른 영역을 표현함 > 안으로 들어갈 수록 고수준의 ..

Clean Architecture 5부, 아키텍처 15장, 아키텍처란 - 아키텍처는 코드와 동떨어져서는 안됨 - 시스템을 구축했던 사람들이 만들어낸 시스템의 형태 > 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수가 되어야 함 > 선택지를 가능한 많이, 오래 남겨야 한다. - 시스템 아키텍처는 시스템의 동작 여부와 관련이 없음 why? 형편없는 아키텍처들도 잘 동작하기 때문 따라서, 아키텍처는 시스템의 수명과 관련된 비용을 최소화하고 프로그래머의 생산성을 최대화 해야한다. 개발 시스템 아키텍처는 개발팀이 시스템을 쉽게 개발할 수 있도록 뒷받침해야한다. 배포 배포 비용이 높을수록 시스템의 유용성은 떨어짐 > 시스템을 단 한번에 쉽게 배포할 수 있도록 만들어야 함 마이크로 서비스 아키텍처 - 컴포넌트..

12장, 컴포넌트 컴포넌트란? 배포 단위 ex) 자바의 jar - 컴포넌트롤 서로 링크하여 실행 가능한 단일 파일로 생성 할 수 있음 ex) .exe, .dll 역사 ... 일부 생략 ... - 링커: 프로그래머가 느린 부분을 처리해주는 링크 과정 처리, 링크가 완료된 재배치 코드를 만듦 -> 로드 속도 향상 = 한 번 만들어둔 실행 파일을 언제나 빠르게 로드 가능 1980년대: 소스 모듈 .c -> .o 컴파일된 후, 링커로 전달되어 로드될 수 있는 실행파일로 만들어 짐 -> 컴파일은 빨랐지만, 링커에서 더 많은 시간이 걸리게 됨 1980년대 후반: 무어의 법칙의 등장으로 디스크가 작아지고 빨라짐 1990년대 후반: 프로그램 링크 속도가 줄어들고, .jar 파일 등 등장 현재: .jar를 기본 애플리케..

SOLID - 함수와 데이터 구조를 클래스로 배치하고 결합하는 방법 종류 SRP: 단일 책임 원칙 - 소프트웨어 모듈은 변경 이유가 하나여야 함 OCP: 개방-폐쇄 원칙 - 기존 코드를 수정하기 보다 새로운 코드를 추가하는 방법으로 행위를 변경해야 함 LSP: 리스코프 치환 원칙 - 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 구성요소는 반드시 서로 치환 가능해야 함 ISP: 인터페이스 분리 원칙 - 소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 함 DIP: 의존성 역전 원칙 - 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 의존해서는 안됨 > 세부사항이 정책에 의존 장점 - 변경에 유연 - 이해하기 쉬움 - 컴포넌트 기반 7장, SRP: 단일 책..

Clean Architecture 2부, 프로그래밍 패러다임 패러다임이란 - 프로그래밍을 하는 방법, 언어에 독립적 -어떤 프로그래밍 구조를 사용할 지, 언제 이 구조를 사용해야 하는 지 결정 3장, 패러다임 개요 3가지 패러다임: 구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍 구조적 프로그래밍 - 최초로 적용된 패러다임 - 무부별한 점프(goto문장)은 프로그램에 해로움 -> if/then/else, do/while/until 등 구조로 변경 - 제어 흐름의 직접적인 전환에 대해 규칙을 부과 객체 지향 프로그래밍 - 스택 프레임을 힙으로 옮기면 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지할 수 있음을 발견 -> 클래스의 생성자 - 지역 변수 = 인스턴스 변수, 중..

Clean Architecture 1장, 설계와 아키텍처 좋은 설계란? 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수 하는 데 투입 인력을 최소화 하는 것에 있다. - 생산성은 낮아지고, 비용을 올라가면 좋지 않은 아키텍처 - 엉망진창인 코드가 쌓이면 결국 생산성은 0으로 수렴 - 자신을 과시하면 재설계 해도 원래 프로젝트와 똑같이 엉망으로 됨 > 재설계가 좋은 방향은 아니다. 그래서 소프트웨어 아키텍처는 - 과신을 미리 방지해서 소프트웨어 품질을 고민해야 한다. - 비용은 최소화하고 생산성은 최대화하는 아키텍처란 2장, 두 가지 가치에 대한 이야기 소프트웨어 개발자가 반드시 높게 가치를 유지해야 하는 것: 행위, 구조 행위 - 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서 소프..