블로그 모아보기 - 인프런

[도서 정리] 도메인 주도 개발 시작하기 - 최범균

최범균님의 도메인 주도 설계 관련 도서를 읽고 내용을 정리했다.도메인 주도 DDD Start! 도메인 주도 설계 구현과 핵심 개념 익히기 (2016년)도메인 주도 개발 시작하기 (2022년)DDD Start를 보완하여 출판한 도서이기 때문에 도메인 주도 개발 시작하기를 보면 된다 새롭게 알게 된 개념애그리거트같은 생명주기를 공유하는 도메인들을 의미하며, 팩토리 메서드 등으로 루트엔티티에서 로직의 일관성을 지키며 관리하도록 한다도메인 서비스기존에도 서비스를 분리하거나 필요한 유틸들을 생성하여 사용했었지만 도메인 로직을 서비스에서 관리한다는 개념 자체는 단순하지만 생각하지 못했던 부분이었던 것 같다.도메인 모델 로직을 한없이 늘리거나 응용 계층에서 일반 로직과 섞어서 복잡하게 짜지말고 도메인 서비스를 사용하는 것이 좋을 것 같다인프라스트럭처계층 아키텍처 기준으로 repository는 영속성 계층이었지만 도메인 주도 설계에서는 repository는 도메인 계층이며 실제 repository의 기능을 구현한 구현체는 인프라스트럭처 계층으로 나뉘었다도메인 주도 설계에서는 고수준 모듈과 저수준 모듈을 구분하고 고수준은 interface 로직을 호출할 뿐 저수준 구현체와는 아무런 관계를 하지 않는다 도메인 주도 설계란, 도메인을 중심으로 설계하는 것이다도메인이란 소프트웨어로 해결하고자 하는 문제 영역이다쉽게 말해서 쇼핑몰 서비스라 하면 상품, 주문, 배송 등이 해당 서비스에서 해결하고자하는 문제 영역이라 할 수 있다 도메인과 엔티티는 다르다도메인 모델 엔티티는 테이블만이 기준이 아니라 같은 단위의 속성도 묶는다엔티티의 특징은 식별자를 갖는다는 것이다Value의 특징은 값들의 묶음이라는 것이다테이블이 있다하더라도 모두 엔티티는 아니다한 엔티티에 포함되지만 DB 정규화에서 나눠진 테이블들이 있다객체로 속성을 관리하게 되면 가독성이 높아지고 상태 관리의 일관성을 높일 수 있다 애그리거트운명공동체인 객체의 묶음이다루트 엔티티에서 기능을 제공한다다른 객체에서 변경할 수 있도록 하면 일관성이 깨지고 중복 로직이 발생한다루트 엔티티가 변경 주체이지만 실제 변경은 대상 객체에게 위임할 수 있다트랜잭션 범위는 작을수록 좋으며, 한 트랜잭션에서 두 개 이상의 애그리거트를 건들지 않도록 한다서비스에서 서로 다른 애그리거트를 호출하여 변경하도록 한다JPA의 지연로딩의 개념과 같다. 즉시로딩은 객체 간의 결합도가 높아진다N+1이 발생한다면 한 번에 호출하는 join 쿼리를 생성하여 조회하도록 한다N:M 관계에서는 중간 테이블을 두어 다루는 것이 좋다논리적인 하나의 도메인은 나열식으로 생성하기보다 하나의 애그리거트에서 팩토리 메서드로 함께 생성하는 것이 좋다 도메인 주도 설계에서의 계층표현 계층, 응용 계층, 도메인 계층, 인프라 스트럭처 계층 고수준 모듈은 응용 계층과 도메인 계층이며, 저수준 모듈은 인프라스트럭처 계층이다interface가 호출되는 곳은 고수준 모듈이어야한다표현 계층, 응용 계층에 도메인 로직은 넣지 않도록 한다응용 계층에서 중복 로직이 발생한다면 메서드로 분리할 필요가 있으며, 서비스 로직이 커진다면 서비스 클래스 수준에서 분리가 필요하다응용 계층은 트랜잭션을 관리한다응용 계층(서비스 계층)은 표현 계층에 필요한 데이터만 전달한다계층 간 필요한 정보만 교환하고 서로 의존성을 줄인다보통 표현 계층에서는 값을 검증하고, 응용 계층에서는 논리적 검증/존재 검증을 한다리포지토리는 domain 계층이며, 리포지토리를 구현한 클래스는 infrastructure 계층이다infrastructure 계층 : 영속성을 구현하거나 외부와 통신하는 기능을 제공하는 레이어도메인 계층에는 도메인 모델과 도메인 서비스가 있다저수준을 추상화하는 것을 경계해야한다!저수준을 추상화하면 도메인이 구현체에 의존하게 된다 핵심 서비스 로직에서 -> 도메인 모델 로직과 부가 서비스 로직을 호출한다주문과 할인 도메인 로직이 있을 때 주문에 할인된 금액 정보가 필요하다면 해당 로직을 주문 애그리거트에 할당하지 않아야한다도메인 서비스를 생성하여 기능을 구현하는 것이 맞다 => 주문 도메인 서비스에서 할인금액을 계산하도록 한다할인 로직이 달라지는 경우, 로직을 추가하기보다 interface로 구현체를 조립할 수 있다 Bounded Context; 모델은 컨텍스트(문맥)에서 결정된다상품 모델은 카탈로그 상품, 주문 상품, 배송 상품 등 다양한 상품이 있다각 컨텍스트에서의 상품이 각각의 모델이 된다 이벤트이벤트가 발생할 때 후처리 관련한 트리거를 발생시키거나 데이터 동기화 작업을 한다예를 들어 결제는 외부 서비스를 이용하는 경우가 많은데 외부 서비스에 문제가 생겼을 때 롤백을 할 것인지, 추후에 재시도할 것인지를 결정해야한다이러한 경우 트랜잭션이나 여러 경우를 고려하여 로직을 짜게 되면 복잡한 로직으로 이어지게 되기 때문에 이벤트를 발생시켜 처리하도록 한다spring에서 ApplicationEventPublisher와 @EventListener를 사용할 수 있다비동기 처리는 다음과 같은 방식이 있다코드 수준에서 @Async를 사용메세지 큐 사용이벤트 저장소 DB 및 별도 프로그램 구축재처리 정책이나 멱등성 등을 고려하여 설계하도록 한다 CQRSCommand and Query Responsibility Segregation명령과 조회의 책임 분리DB에 대한 Write와 Read가 분리되는 것이다데이터 변경이 있을 시 -> 메세지 이벤트 발생 -> 연관 데이터 변경

도서･DDD

2

1

운영체제(OS)와 컴퓨터 시스템 3 - 메모리

메모리 메모리 종류 RAM(Random Access Memory) 정보 기록(쓰기)이 가능한 메모리 휘발성 DRAM(Dynamic RAM) : 메인 메모리. 대용량, 소비 전력이 적고 속도가 비교적 느림. SRAM(Static RAM) : 캐시 메모리. 저용량. 소비 전력이 크고 속도가 비교적 빠름. ROM(Read Only Memory) 읽기만 가능한 메모리 비휘발성 메모리 PROM(Programmable ROM) : 갱신 가능한 ROM EPROM(자외선), EEPROM(전기적), 플래시 메모리(전기적, USBº SD카드º SSD) 캐시 메모리 : 하드디스크에 대한 액세스를 줄이기 위해 하드디스크를 참조하는 메모리 가상 메모리 : 하드디스크 안에 페이징 파일을 물리 메모리와 매핑하여 메모리로 활용 메모리 용도에 따른 영역 힙 - 데이터를 저장할 때와 같이 필요한 만큼만 확보하여 사용. First In First Out 스택 - 프로그램 실행 중 이용하는 변수를 일시적으로 저장. Last In First Out 메모리 확보와 해제 가비지 콜렉션 - 힙 영역의 불필요한 메모리를 자동으로 해제 컴팩션 - 단편적 미사용 영역을 연속적인 이용 가능한 영역으로 만듦 <도서 정리> OS가 보이는 그림책 - ANK Co., Ltd. 저 | 이영란 역

OS･시스템･메모리･도서

1

운영체제(OS)와 컴퓨터 시스템 2 - CPU

CPU os가 프로그램을 실행하는 구조 os가 프로그램을 실행 하드디스크 안의 프로그램을 메모리로 읽어들인 후 실행 메모리에 할당된 프로그램은 '프로세스'라고 일컬음 프로세스 상태 : 실행 상태, 실행 가능 상태, 대기 상태 cpu에 할당되어 실행 중인 상태가 실행 상태. 우선순위가 높은 프로세스에 의해 인터럽트(중단) 처리되기도 함. 멀티태스킹 태스트(Task) : os가 cpu에 의뢰하는 작업 단위 멀티태스킹 : 여러 개의 태스크를 동시에 처리하는 행위 스케줄링을 통해 순서대로 처리하는 것; 빠른 전환으로 인해 동시에 수행되는 것처럼 보임 프로세스가 메모리와 같은 공유 자원을 이용할 때는 영향이 가지 않도록 잠금(Lock)이 일어나기도 함. 이 경우, 양 쪽 프로세스 모두 계속해서 대기 상태에 빠지는 데드락이 발생할 수 있음. 프로세스 제어 - 프로그램 상태어 (PSW : Program Status Word) cpu 속 레지스터에 인퍼럽트로 중단된 프로그램 상태나 연산의 종료 상태를 저장. - 프로세스 제어 블럭 (PCB : Process Control Block) 각 프로세스의 CPU상태(컨텍스트)나 프로세스의 상태를 제어해두는 메모리 영역. - 컨텍스트 스위치 인터럽트로 인해 프로세스를 전환할 때 os가 컨텍스트를 PCB에 저장하고 복원하는 것 프로세스 동기 배타 제어 : 처리가 끝날 때까지 하나의 프로세스에게 자원을 독점시켜 일관성을 유지. 세마포: 정해진 수 이상의 프로세스가 공유 자원에 동시 접근하지 않도록 카운터를 이용해 제어하는 장치. 무한정 대기 상태 데드락 피하기 -> 세마포와 뮤텍스(세마포 카운터 1) 여러 개의 프로세스에 의한 공유 자원 경쟁이 없어짐; 배타 제어 프로세스 통신 메시지 큐 : os의 메시지 기능을 통해 1대1 통신 파이프 : 여러 개의 프로세스 입출력을 연결하는 장치. 일방향. 공유 메모리와 스레드 공유 메모리 : 여러 개의 프로세스에서 공통으로 사용할 수 있는 메모리 영역. 스레드 : 프로세스 안의 프로그램 실행의 흐름. 스레드끼리는 같은 메모리 공간 참조 멀티 스레드 : 여러 스레드 동시 실행 <도서 정리> OS가 보이는 그림책 - ANK Co., Ltd. 저 | 이영란 역

OS･시스템･CPU･도서

1

운영체제(OS)와 컴퓨터 시스템 1

운영체제 1. 운영체제란 무엇인가. 운영체제는 컴퓨터를 관리 및 제어하기 위한 소프트웨어이다. - 프로세스 관리 - 메모리 관리 - 디스크 관리 - 네트워크 관리 대표적인 운영체제 : Windows, UNIX(Linux), Max OS 2. 컴퓨터 구성 부품 메인보드 : 컴퓨터를 구성하는 부품을 접속하고, 데이터 처리와 부품의 제어를 수행 CPU : 컴퓨터의 작동 제어 또는 연산 처리를 수행한다. (두뇌 역할) 메모리 : 명령, 프로그램, 데이터, 처리 결과 등을 일시적으로 기억하는 장치이며 휘발성이이다.(현재 작업을 처리하는 역할 및 공간) 하드디스크 : 대용량 기억 장치이며, 비휘발성이다. (데이터, 프로그램 저장창고) BIOS (Basic Input Output System) : 컴퓨터에 접속된 기기를 제어한다. 칩셋 : 각 부품이 주고받는 데이터 흐름을 관리한다. 수억 개 이상의 트랜지스터가 집적되어 있다. 3. OS 기능 컴퓨터 기동 하드웨어 -> BIOS -> 부팅로더 -> OS 사용자 영역의 요청(쉘, 응용 소트프웨어) -> 커널 -> OS 쉘 인터페이스는 CUI(명령 프롬프트;cmd) 또는 GUI(사용자들이 주로 사용하는 디스플레이) I/O 포트 ; Input/Output 입출력 구조 I/O 주소 공간에 명령이나 데이터를 넣어 디바이스를 제어 ex) 키보드 컨트롤러 메모리 기억장치 레지스터 CPU 안에 레지스터는 연산 결과를 저장한다. 캐시메모리는 CPU와 메모리 사이에 빠른 전달을 돕기 위한 CPU의 메모리이다. 내부 기억장치 메인 메모리 외부 기억장치 하드디스크 고속화를 위해 디스크 캐시가 존재한다. <도서 정리> OS가 보이는 그림책 - ANK Co., Ltd. 저 | 이영란 역

OS･시스템･도서

1

0

운영체제(OS)와 컴퓨터 시스템 - 디스크

디스크 관리 데이터 액세스 방식에 따른 외부 기억 장치 종류 - 랜덤 액세스 목적 데이터에 직접 접근하는 방식. 고속으로 접근. HDD, CD/DVD, FDD - 시퀀셜 액세스 기억 영역의 맨 처음부터 데이터를 순서대로 검색하여 액세스해 나가는 방법 자기 테이프, 플래시 메모리(USB), SD 메모리 카드 하드디스크 구조 플래터(원반), 트랙(동심원 형태의 영역), 섹터(트랙의 재분할), 실린더(트랙의 모음) os가 사용하는 단위는 클러스터 == 여러 개의 섹터 모음 항상 클러스터(섹터)를 모두 사용할 수 없기 때문에 미사용 영역 발생. 스트림 스트림 : 파일 간에 데이터가 통하는 통로가 있으며, 그 통로를 흐르는 데이터의 흐름을 의미. 스트림에 대한 조작에는 open, read, write, close가 있음. 프래그먼테이션(단편화) 하나의 파일이 여러 트랙에 분할되어 기록되는 상황. 시크 횟수가 증가하여 액세스 시간 증가하는 문제 발생. -> 디프래그로 해결; 연속된 영역으로 다시 기록. 디스크 캐시 하드디스크에서 읽어드린 데이터를 일시적으로 저장하기 위한 메모리. 매번 디스크로부터 읽어들일 필요가 없어지기 때문에 액세스 속도 향상. 리던던시 시스템의 리던던시 : 시스템 장애가 발생해도 큰 손실이 나지 않도록 시스템에 여유를 가지게하는 것. 데이터의 리던던시 : 실질적으로 의미가 없는 여분의 데이터 또는 데이터의 정당성을 검증하기 위해 값을 추가하는 것 RAID : 여러 개의 하드디스크를 연결하여 동시에 여러 개의 하드디스크에 액세스하는 방식 분산 중복 저장, 오류 발견 디스크 마련 등 CPU, 메모리에 부담이 적어짐. <도서 정리> OS가 보이는 그림책 - ANK Co., Ltd. 저 | 이영란 역

OS･시스템･디스크･도서

0

<도서정리> 객체지향의 사실과 오해

객체지향이란. 흔히 객체지향을 세상을 객체들의 모임으로 보고, 객체들이 상호작용하는 것을 소프트웨어 세계에 모방하는 방식으로 소개한다. 하지만, 객체지향은 실세계를 모방하는 것이 아닌 새로운 세계를 창조하는 것이다. 현실 속에서 수동적인 존재가 소프트웨어 객체로서는 능동적인 객체가 된다. 사물의 의인화가 이루어지며, 얼마든지 필요한 능력을 가질 수 있다. 객체 상태와 행동의 명명 또한 창조의 영역이다. 객체란. 객체들 간에는 특정한 목표를 위해 협력하며, 객체는 협력 속에서 맡은 역할에 책임을 진다. 협력은 연쇄적인 요청과 응답으로 구성되어있다. 객체 특징재활용성 - 여러 객체가 동일한 역할을 수행할 수 있다.활용성 - 역할을 대체가능성을 의미한다.다형성 - 책임을 수행하는 방법은 자율적으로 선택할 수 있으며, 다양한 방식으로 요청 수행이 가능하다.한 객체가 동시에 여러 가지 역할을 수행할 수 있다. 다양한 곳에 참여한다.(참조되어 사용된다) 협력. 시너지; 전체는 부분의 합보다 크다. 성공적인 협력을 위해서는 적절한 단위적인 책임을 부여하는 것이 중요하다. 객체는 충분히 협력적이어야한다. 다른 객체에게 적극적으로 도움을 요청할 정도로 열린 마음을 지녀야 하며, 모든 것을 스스로 해결하려는 전지전능한 객체는 복잡함에 의해 자멸한다. 객체는 자율성을 가진다. 객체의 자율성. 캡슐화 - 객체의 자율성은 객체의 내부와 외부를 명확하게 구분하는 것으로부터 나온다. 객체의 사적인 부분은 객체 스스로 관리하고, 외부에서 일체 간섭할 수 없도록 차단해야한다. 객체의 외부에서는 접근이 허락된 수단을 통해서만 객체와 의사소통해야한다. 무엇을 수행하는지는 알 수 있지만 어떻게 수행하는지에 대해서는 알 수 없다. 객체는 상태와 행동을 지닌다. 객체는 자신의 상태를 직접관리하고 상태를 기반으로 스스로 판단하고 행동하는 자율적인 존재이다. 객체의 행동이 상태를 결정한다. 객체의 행동은 객체가 협력에 참여하는 방법이며, 객체의 적합성은 객체의 행동으로부터 결정된다. 책임주도설계 - 객체가 어떤 책임을 갖는가가 설계를 주도한다. interface를 통해 제공가능한 정보와 서비스를 알려주는 동시에 캡슐화를 수행할 수 있다 인터페이스가 변경되지 않는다면, 내부 방식을 변경하더라도 그것이 영향을 끼치지 않는다. 동일한 인터페이스에 의존한다면, 어떠한 구현체와도 상호작용을 할 수 있다. 객체와 추상화. 추상화를 통해 현실세계의 복잡성을 극복할 수 있으며, 그를 통해 사물의 본질에 접근할 수 있다. 추상화 과정 - 유사성, 공통점을 통해 분류한다. 객체의 추상화는 분류(classification)를 통해 이루어진다. 객체지향은 객체를 지향하는 것이지 클래스를 지향하는 것이 아니다 일반화/특수화 서브타입은 슈퍼타입(본질)을 대체할 수 있어야한다. 슈퍼타입의 행동은 서브타입에 자동으로 상속된다. 타입 타입은 추상화이다. 타입은 동적인 상태 변경을 단순화하는 정적 객체 특징에 집중한다. 클래스는 타입을 구현하는 도구이다. 추상화를 통해 다양한 객체들이 조립되어 역할을 수행할 수 있다면 협력이 유연해지며 객체들의 재사용성이 높아진다. 메세징 메세징(요청)은 객체에게 접근할 수 있는 유일한 방법이다. 어떻게 할지는 객체 스스로가 결정하며, 메세지로는 무엇을 할지만을 요청한다. 요청을 받은 후 객체는 적절한 메서드를 선택하여(다형성) 요청을 수행할 것이다. 객체지향은 객체들이 주고받는 메세지들로 구성된다. 클래스는 객체들의 속성과 행위를 담는 틀일 뿐이며, 객체의 속성과 행위가 중심이 되어야한다. 또한 객체지향은 객체를 넘어서 객체들 간의 커뮤니케이션에 초점을 맞출 때 이루어진다. 메세징을 이용한 객체지향 객체가 책임을 완수하기 위해, 다른 객체의 도움이 필요하다고 판단되면도움 요청 메세지를 결정한다. 메세지를 결정한 후 메세지를 수행하기에 적합한 객체를 선택한다. -> 메세지가 수신자의 책임을 결정한다.

도서･객체지향･협력･역할･책임･추상화･다형성･캡슐화

0

<도서정리> 함께 자라기 - 김창준

발전하는 조직 뛰어난 인재를 뽑는 것이 끝이 아니라 뽑은 후 교육하고 성장하게 도움을 주는 것이 중요하다. 이것은 개인의 발전과 더불어 조직의 발전을 이끈다. 더 나아가서 교육만큼 중요한 것은 시스템이다. 시스템은 훌륭한 개인을 묻힐 수도 있고 보통의 개인을 뛰어날 수 있게 하는 것이 시스템이다. 실수 예방 문화보다 실수 관리 문화가 조직 개선에 도움이 된다. 실수를 예방하려고 하면 실수를 하는 사람을 처벌하거나 실수를 부정적으로 인지하게 될 수 있다. 하지만 실수를 관리한다면 그 과정에서 실수에 대해 정확히 인지하고 어떤 부분을 보완해야할지 어떻게 대응하면 좋을지 명확히 알게 되기 때문이다. (학습의 기회) 조직에서의 심리적 안전감 : 내 생각이나 질문, 의견, 걱정, 실수가 드러났을 때 처벌받거나 놀림받지 않을 것이라는 믿음 성장하는 개인 확실한 동기와 짧은 주기의 피드백이 유의미한 성장을 유도한다. (애자일 정신 - 고객에게 매일 가치를 전하라) 자신의 업무의 과정과 결과를 기록하고 점검하면서 실수한 부분과 부족한 부분을 보완하는 것이 필요하다. 자기계발은 복리로 돌아온다. 업무에 대한 바람직한 태도 1. 학습프레임과 실행프레임 - 학습프레임은 내가 얼만큼 성장할 수 있는지에 관심을 갖는 것. - 실행프레임은 내가 성과를 낼 수 있는지 다음 단계로 갈 수 있는지. 실행프레임은 경쟁으로 시야가 좁혀지며 성장과 학습의 기회를 놓칠 수 있다 2. 내가 하는 일이 무엇인가 남이 시키는 대로 혼자 프로그램을 만드는 것이라면 "컴퓨터가 할 수 있는 일"을 잘 하는 것이다 창의적, 사회적으로 일을 할 수 없다면 자신이 어느 정도의 실력을 가졌는지 메타인지적으로 판단이 어려우며 협력하는 방법(==차별화된 능력)도 배울 수 없다. 사회 속에서 산다는 것. 1. 전문가란 무엇인가 새로운 기술을 도입할 때에는 사회적 자본과 사회적 기술이 필요하다. 새로운 기술이 도입되지 못하는 경우는 기술에 대한 이해보다 조직과 신뢰의 문제 때문일 가능성이 높다. 이 내용과 비슷한 경험이 있었다. TDD를 도입하고 싶어했던 개발자가 있었지만 TDD를 도입하는 것은 기존의 체계를 변화시킨다는 비용과 그것이 좋은 효과를 가져올지에 대한 불가피한 불확실성이 있었다. 그렇기 때문에 상사분은 TDD를 내켜하지 않으셨으며 TDD를 도입하지 않기 위해 제대로 정착될 수 없는 기한과 환경을 제시하셨다. 개인적인 오해였을 수 있지만 상사분이 보여준 태도는 새로운 기술을 도입하지 않는 것에 대해 솔직한 의견을 제시하기보다 그 과정에서 불필요한 부정적인 감정소모를 불러일으켰다고 느껴졌다. 결론적으로 TDD가 도입되지 않은 것보다 큰 문제는, 팀원들이 상사로부터 실망감을 얻은 것, 신뢰를 잃은 부분인 것이다. 이러한 일련의 사건들은 조직에 대한 애정을 점차 낮아지게 하며 업무와 조직에 방해가 된다는 것을 몸소 경험했었다. 프로젝트에서 기술과 방법론보다 어떤 사람들이 참여하는지가 중요할 수 있다. 나는 어떤 사람인가를 되돌아볼 것. 전문가는 홀로 특정 도메인 지식이 뛰어난 사람이 아니라 그와 더불어 사회적 자본과 사회적 기술이 뛰어난 사람이다. 뛰어난 소프트웨어 개발자는 타인과의 인터렉션에 더 많은 시간을 소요하며 기술적인 조언과 더불어 사회적인 조언을 제공한다. 협력은 프로젝트 영역을 나누어 각각 업무를 진행한 후 합치는 것이 아니다. 커뮤니케이션과 협동을 통해 다른 사람의 생각을 알게 되고 그림도 그려보며 코드의 추상성을 높이는 과정은 사람만이 할 수 있는 능력이다 2. 감정과 협력 이성과 감정은 분리할 수 있는 대상이 아니며 선택에 있어서 감정을 배제할 수 없다. 의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 한다. 그렇기 때문에 남을 설득하려면 논리성과 객관성에 대한 환상을 버려야한다. 상대방의 성향과 가치관, 선호도를 파악하고 상대방에게 신뢰를 얻는 것이 중요하다. 자료와 객관성과 더불어 상대가 어떤 사람인지가 중요하다.

도서･조직･태도

0

<도서정리> 테스트 주도 개발 시작하기 - 최범균

TDD 단계: 레드 - 그린 - 리팩토링 테스트 선 작성 후 테스트를 통과시킬 만큼의 코드를 작성한다.(기능을 구현한다)마지막으로 리팩토링을 통해 코드를 다듬는다.테스트를 통해 개발의 범위가 정해진다. 테스트가 진행될수록 검증하는 범위가 넓어지면서 기능 구현이 점점 완성되어간다. TDD는 개발 과정에서 코드를 지속적으로 정리하므로 코드품질을 높이고 유지보수 비용을 낮춘다.코드 수정 후 테스트가 진행되므로 향후 올바르지 않은 코드가 배포되는 것을 방지할 수 있다. 테스트 코드 작성 순서 쉬운 경우(넓은 범위)에서 어려운 경우로 진행 예외적인 경우에서 정상인 경우로 진행 한 번에 많은 코드를 만들면, 그 사이 발생한 버그를 잡기 위해 많은 비용이 들어간다. 정해진 값 리턴 값 비교를 통해 정해진 값 리턴 다양한 경우 추가하면서 구현을 일반화 테스트를 먼저 작성하고 return 상수로 테스트 통과시킨 후에 비즈니스 로직 하나씩 추가하면서 테스트 매번 실행 대역 MockitomemoryRepository implements 리포지토리 인터페이스 - Map 사용하기@TempDir 기능명세 테스트할 기능을 생성하면서 클래스, 메서드, 파라미터 구성결과 검증하면서 리턴값 구성-> 테스트하면서 설계까지 진행됨클래스, 메서드, 변수명은 주석보다 코드 이해에 효과적이게 구성하기필요한만큼만 설계하기예외적인 상황, 복잡한 상황은 최대한 많이 기획자와 상의하고 대비하는 것이 효율적이고 완성도 높은 개발을 이끌어냄 리팩토링 기능 개발을 다 끝낸 후에 리팩토링하기또는 커밋 후에 리팩토링하기리팩토링은 클래스 분리, 메서드 추출, or문, count 로직 등 이용...파라미터 개수가 3개 이상이면 객체화하기 꿀팁 Assert 메서드를 테스트 클래스에 별도 생성해서 응용도 가능하다.로직을 중복 호출하지 않고, Assert 메서드에 로직을 넣어버려서 검증만 진행하도록 할 수도 있다. 중간에 예외처리를 하면, 조건문 중복 등 코드가 복잡해지기 때문에초반에 예외처리를 하는 것이 시스템 운영 중에 NPE를 만나지 않는 방법이다. before setUp으로 데이터를 미리 생성해놓는 것은 중복이 제거되는 듯이 보이지만,각 테스트마다 필요한 데이터가 항상 일정하지 않을 수 있음으로 각 테스트에서 데이터 생성하는 것을 추천한다. 검증 시 굳이 변수나 필드명으로 검증하는 것보다 기댓값을 실제값으로 넣는 것도 좋다.테스트에서는 직관적으로 확인할 수 있는 것이 좋기 때문이다. given으로 파라미터를 넘길 때는 값보다 타입으로 넘겨주자.(범용성) update와 같은 내부구현 검증이 필수적일 때는 내부구현 검증이 필요하다.하지만 웬만하면 실행결과 검증 중심으로 진행할 것.테스트 실패의 경우를 줄이기 위해서 검증해야할 부분을 명확히 하기 위해서이다.

TDD･test･최범균･junit･도서

0

<도서정리> 프로그래머처럼 생각하라, 프로그래머의 뇌

프로그래머처럼 생각하라 모델 기반 사고 - 프로그래머는 사물을 단순하게 생각한다 모델 : 사물의 특성과 사물과 사물 간의 관계를 나타낸 것 장점 전체적인 그림을 파악할 수 있어 이해도가 높아지고, 누락 또는 중복을 줄일 수 있다. 논리적 비약 : 새로운 요소를 추가, 기존 요소를 제거, 관계 확장 등 모델링을 지속적으로 활용 및 개선시킬 수 있다. 모델 형성 단계1. 필수 요소 명사 열거2. 선으로 요소 간 관계 표시3. 논리적 배치 모델링은 목적에 맞는 관점으로 설계하는 것이 중요 관점에 따라 모델링이 달라지기 때문에 목적을 명확히 할 것 모델링은 핵심 위주로 단순하게, 전달 가능할 정도의 구체성을 가져야한다. 명명에 대한 정확성 모델링은 구체적 사례를 통해 일반화를 이끌어내야한다. 본질을 중요시 사례에 대한 구체성 모델링은 기승전결의 구조로 어떤 곳에서도 응용 가능 무엇인가를 파악하거나 전달하고자할 때 단순 -> 구체 -> 일반화 가능 추상적이고 논리적인 도식화로 흐름 파악 용이 프로그래머의 뇌 코딩을 할 때 오는 혼란의 세 가지 원인 1. 지식의 부족 -> 언어를 모를 때 2. 정보의 부족 -> 언어는 알지만 특정 메서드의 동작 과정을 모를 때(캡슐화 등) 3. 처리 능력의 부족 -> 유추할 수 있지만 단계적인 결과값을 따라가지 못할 때 위 세가지 원인은 뇌의 다음과 같은 영역과 관련있음 1. 장기기억공간; 하드디스크, 저장 2. 단기기억공간; 메모리, 저장 3. 작업기억공간; cpu, 처리 코드를 신속하게 이해하는 법 묶음(chunk)을 활용 -> 이 과정에서는 이미 내가 기존에 기억하고 있는 장기기억을 활용하여 처리 즉, 기억하는 대상이 중요한 것이 아니라 기억하는 방식이 중요하다 장기기억 프로그래밍을 하다보면 막히는 부분이 일어나 업무중단이 빈번하게 일어난다.이 때 프로그래밍의 목적이 상실될 수 있는 위험성이 있다.그렇기 때문에 어느 정도의 암기는 프로그래밍에 유용하다. 장기기억 또한 시간이 지나면 사라지기 때문에 간격을 두고 반복하여 기억을 강화하는 작업이 필요하다. 장기기억을 가져오는 두 가지 기제 저장강도 인출강도 저장강도는 시간이 흐를수록 증가하지만 인출강도는 시간이 흐를수록 감소한다. 알고 있는 것을 기억해내고 실제로 꺼낼수록 인출강도는 강화된다. 즉, 많이 보아서 장기기억에 저장되어 있는 코드일지라도 인출강도가 약하면 해당 코드가 필요할 때 사용할 수 없을 것이다.저장은 반복을 통해 가능하지만 인출 또한 반복해야한다.-> 능동적 사고를 통한 인출강도 강화; 능동적으로 기억하려고 노력할 때 저장과 인출 모두 효과가 좋다 기억을 강화하기 위해서는 정교화하는 것이 도움이 된다. 연관기억을 활용하여 새로운 기억을 저장하는 방식이다. 공통점, 패턴을 활용. 장기기억은 긍정적 전이, 부정적 전이(오개념)가 일어난다. 오개념을 방지하기 위해 알고 있는 개념일지라도 명확히 할 필요가 있다. 장기기억은 암시적 기억과 명시적 기억으로 분류할 수 있다. 암시적 기억은 근육 기억으로 터치 타이핑처럼 아무 생각없이 실행할 수 있는 작업이다. 명시적 기억은 for 루프 문법처럼 능동적으로 불러와야하는 기억이다. 명시적 기억을 강화하려면 기존 코드, 코드 설계 방법에 대한 설명(해설)이 포함된 코드를 연구하면 좋다. 변수 변수는 표식이 되어 코드 이해에 도움이 된다. 코드를 이해하기 위해서는 코드를 작성한 목적에 집중하는 것이 필요하다. 코드의 핵심에 초점을 맞추고 연관 코드들을 이해하는 것으로 방향을 확장시킨다. 코드를 읽고 이해하는 데 많은 시간을 소요하기 때문에 언어능력을 향상시키는 것도 필요하다. 명명을 잘하는 방법 일관성, 명확성 변수길이, 음절길이, 스네이크 케이스, 카멜 케이스 명명 방법 3단계 : 표현할 개념 정의 -> 단어 선택 -> 단어 결합

도서

0