From ae6088e0e76e05678e220a63841d964e70c5b287 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B9=80=EC=A0=95=EC=9C=A4?= Date: Sun, 19 Dec 2021 10:44:34 +0900 Subject: [PATCH 1/5] =?UTF-8?q?create:=20[OS]=20=ED=94=84=EB=A1=9C?= =?UTF-8?q?=EA=B7=B8=EB=9E=A8=20vs=20=ED=94=84=EB=A1=9C=EC=84=B8=EC=8A=A4?= =?UTF-8?q?=20vs=20=EC=8A=A4=EB=A0=88=EB=93=9C=20(#9)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...s \354\212\244\353\240\210\353\223\234.md" | 147 ++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 "OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" diff --git "a/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" "b/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" new file mode 100644 index 0000000..68a1160 --- /dev/null +++ "b/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" @@ -0,0 +1,147 @@ +# 프로그램, 프로세스, 스레드 + +## 프로그램(Programe)이란? + +- **특정 작업을 수행하기 위해** 작성된 일련의 지침을 포함하는 **실행 파일** + +- 컴퓨터의 주 메모리에 저장되지 않고, 디스크 또는 컴퓨터의 **보조 메모리에 저장**된다. + +- 프로그램은 주 메모리에서 읽고 커널에 의해 실행된다 + + ex) chrome.exe (웹 페이지 보기), notepad.exe (텍스트 파일 편집) + +- **특징** + - **수동적(정적) 개체(passive entity)**. 실행할 명령어 그룹 저장. + - 수동으로 **삭제할 때까지 메모리에 저장**된다. + - 프로그램은 **실행 없이 어떤 작업도 수행 불가능.** + +## 프로세스(Process)란? + +> program is in execution (실행 중인 프로그램) + +- 메모리에 올라와 **실행되고 있는 프로그램의 인스턴스(독립적인 개체)** + +- 프로그램이 실행되는 실행 단위 + +- 프로그램 실행 중에 생성되어 **주 메모리에 load**된다. + + ex) google 크롬 아이콘을 더블 클릭하면 크롬 프로그램을 실행하는 프로세스가 시작된다. + +- **특징** + + - **능동적(동적) 개체(active entity)**. 응용 프로그램의 목적을 수행함 + - **수명이 매우 제한적**. 작업이 완료되면 종료된다. + - 프로세스에는 파일 디스크립터(file descriptors), 네트워크 포트와 같은 **시스템 자원이 할당**된다. + - 여러 프로세스가 동일한 프로그램과 관련될 수 있다.
ex) 메모장 프로그램의 여러 인스턴스 실행 가능 (각 인스턴스 = 프로세스) + - 프로세스에 대한 정보는 **PCB(Process Control Block)**에 저장된다. + +### PCB(Process Control Block) + +> 특정 프로세스에 대한 중요한 정보를 저장하고 있는 운영체제의 자료구조 + +- 사용자가 프로세스를 생성할 때마다 운영체제는 해당 프로세스에 해당하는 PCB를 생성한다. + +- **[PCB]에 저장되는 정보** + +| 이름 | 정의 | +| -------------------------------------- | ------------------------------------------------------------ | +| 프로세스 식별자 (Process-Id, PID) | 프로세스 식별 번호 | +| 프로세스 상태 (Process state) | new, ready, running, waiting, terminated 등의 상태를 저장 | +| 프로세스 우선순위 (Process Priority) | 수명, 소비한 자원 등으로 우선순위 나눔
숫자 값이 작을수록 해당 프로세스의 우선 순위 증가 | +| 회계정보 (Accounting Information) | 사용된 CPU 양과 시간, 시간 제한, 계정 번호 등 제공 | +| 프로그램 카운터 (Program Counter, PC) | 프로세스가 다음에 실행할 명령어의 주소 저장 | +| CPU 레지스터 (CPU Registers) | 인터럽트 발생 or 프로세스 간 문맥 교환 발생 시 임시 정보 저장. | +| PCB 포인터 (PCB Pointers) | 프로세스 상태가 ready인 다음 PCB 주소 저장 | +| 열린 파일 목록 (List of Open Files) | 프로그램이 실행되는 동안 필요한 모든 파일 정보 저장 | +| I/O 상태 정보 (I/O status Information) | 프로세스에 할당된 입출력 장치 목록 저장 | + +## 프로세스 상태 (Process State) + +![프로세스_상태도](https://github.com/KJY97/Note/blob/main/img/OS/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4_%EC%83%81%ED%83%9C%EB%8F%84.png?raw=true) + +- **New** : 프로세스가 생성중인 상태 + +- **Running** : CPU를 잡고 명령어(instruction)를 수행중인 상태 +- **Ready** : CPU를 기다리는 상태 (다른 조건을 다 만족하고 CPU만 얻으면 되는 상태를 의미) +- **Blocked(wait, sleep)** : CPU를 주어도 당장 명령어(instruction)을 수행할 수 없는 상태 + - Process 자신이 요청한 event(예: I/O)가 즉시 만족되지 않아 이를 기다리는 상태 + - ex) 디스크에서 file을 읽어와야 하는 경우 +- **Terminated** : 수행(execution)이 끝난 상태 + +## 프로그램과 프로세스 차이점 + +| | 프로그램 | 프로세스 | +| --------- | ------------------------------------------------ | -------------------------------- | +| 정의 | 프로그래밍 목표를 달성하기 위해 정렬된 작업 그룹 | 프로그램이 실행 중 | +| 상주 위치 | 디스크 or 보조 메모리 | 주 메모리 | +| 개체 유형 | 정적, 수동적 개체(passive entity) | 동적, 능동적 개체(active entity) | +| 자원 관리 | 명령어 저장을 위한 메모리만 필요 | 리소스 요구사항이 매우 높음 | +| 수명 | 수명이 길다. (삭제 전까지 저장됨) | 수명이 짧고 매우 제한적 | + + + +## 스레드(Thread) + +> 프로세스 내의 실행 흐름 + +![스레드](https://i0.wp.com/javaconceptoftheday.com/wp-content/uploads/2014/11/ThreadsAndProcesses.png?w=1200) + +- 프로세스의 **실행 가능한 가장 작은 단위** + +- 프로세스는 동시에 실행되는 여러 스레드를 가질 수 있다. + + - 이러한 프로세스를 경량 프로세스(Lightweight Process) 라고도 부른다. + +- **분류** + + | User Threads | Kernal Threads | + | ----------------------- | --------------------- | + | 사용자에 의해 구현 | OS에 의해 구현 | + | 구현이 쉬움 | 구현 복잡 | + | 종속 스레드로 설계 | 독립 스레드로 설계 | + | 문맥 교환 시간이 짧음 | 문맥 교환 시간이 길다 | + | 하드웨어 지원 필요 없음 | 하드웨어 지원 필요 | + +### 멀티 스레딩 + +**하나의 프로세스를 다수의 실행 단위로 구분**하여 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 **수행 능력을 향상시키는 것** + +- 즉, 하나의 프로그램에 동시에 여러개의 일을 수행할수 있도록 해주는 것 +- 하나의 프로세스 내 **메모리와 자원을 공유**한다. +- 메모리의 **code, data, heap 영역은 공유**하고, **stack과 PC 레지스터는 따로 할당**받는다. + - **각 스레드는 독립적으로 수행**되어야 하기 때문. +- **장점** + - **응답시간 단축** : 여러 스레드로 분할되면 하나의 스레드가 실행을 완료될 때 즉시 출력 반환 가능 + - **빠른 통신** : 동일한 메모리 영역을 공유해서 여러 쓰레드 간 통신이 원활함 + - **빠른 문맥 교환** : 프로세스에 비해 캐시 메모리를 비울 필요가 없기 때문. + - **시스템 처리량 향상** : 각 스레드 기능을 하나의 작업으로 간주하면서 단위 시간당 완료되는 작업 수 증가함 +- **문제점** + - **동기화 문제** + - 공유하는 자원에 동시에 접근하는 경우, 프로세스와 달리 **데이터와 힙 영역**을 공유하기 때문에 어떤 쓰레드가 다른 쓰레드에서 사용중인 변수나 자료 구조에 접근하여 엉뚱한 값을 읽어오거나 수정할 수 있다. 따라서 동기화가 필요! + - 동기화를 통해 작업 처리 순서와 공유 자원에 대한 접근을 컨트롤할 수 있다. 그러나 불필요한 부분까지 동기화를 하면 과도한 lock으로 인해 병목 현상이 병목 현상이 발생해 성능 저하 가능성 높다. + - 구현이 어려움 + - 테스트, 디버깅하기 어려움 + - 하나의 스레드의 문제가 발생하면 전체 프로세스에 영향을 끼침 + +## 프로세스와 스레드 차이점 + +| | 프로세스 | 스레드 | +| -------------- | ------------------ | -------------------------------------- | +| 정의 | 프로그램이 실행 중 | 프로세스의 세그먼트 | +| 프로세스 타입 | 중량 프로세스 | 경량 프로세스 | +| 종료 시간 | 많은 시간 소요 | 적은 시간 소요 | +| 생성 시간 | 많은 시간 소요 | 적은 시간 소요 | +| 문맥 교환 시간 | 많은 시간 소요 | 적은 시간 소요 | +| 메모리 공유 | 비공유 | 공유. 단, stack과 PC 레지스터는 비공유 | + + + +## Reference + +- https://javaconceptoftheday.com/differences-between-program-vs-process-vs-threads/ +- https://www.guru99.com/program-vs-process-difference.html#3 +- https://binaryterms.com/process-control-block-pcb.html +- https://www.geeksforgeeks.org/thread-in-operating-system/?ref=lbp +- https://www.guru99.com/difference-between-process-and-thread.html +- https://goodgid.github.io/What-is-Multi-Thread/ + From 9f9cd023f3b10e0576a5a89a54e187e6440c732e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B9=80=EC=A0=95=EC=9C=A4?= Date: Sun, 26 Dec 2021 17:28:01 +0900 Subject: [PATCH 2/5] =?UTF-8?q?update:=20[OS]=20=ED=94=84=EB=A1=9C?= =?UTF-8?q?=EA=B7=B8=EB=9E=A8vs=ED=94=84=EB=A1=9C=EC=84=B8=EC=8A=A4vs?= =?UTF-8?q?=EC=8A=A4=EB=A0=88=EB=93=9C=20(#9)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...44 vs \354\212\244\353\240\210\353\223\234.md" | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git "a/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" "b/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" index 68a1160..e627822 100644 --- "a/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" +++ "b/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" @@ -1,5 +1,10 @@ # 프로그램, 프로세스, 스레드 +> - 프로그램이란 특정 작업을 수행하기 위한 실행파일이다. 실행파일을 클릭했을 때 메모리 할당이 이루어지고, 이 메모리공간으로 코드가 올라간다. 이 순간부터 프로세스이다. +> - 프로세스는 OS로부터 자원을 할당받는 실행되고 있는 프로그램의 인스턴스이다. 각각 독립된 메모리 영역(Code, Data, Stack, Heap 구조) 등을 할당받는다. +> - 스레드는 프로세스의 가장 작은 실행단위로, 프로세스가 할당받은 자원을 이용한다. 프로세스 내에서 각각 stack과 PC 레지스터만 따로 할당받고 Code, Data, Heap 영역은 프로세스 내에 쓰레드끼리 공유하면서 실행된다. +> - 스레드를 사용하면 응답시간 단축, 빠른 통신과 비용적음, 빠른 문맥 교환, 시스템 처리량을 향상시킬 수 있지만, 스레드의 자원 공유는 동기화 문제에 신경을 써야하며 멀티스레드 프로그래밍은 구현과 디버깅이 어렵다는 문제점이 있다. + ## 프로그램(Programe)이란? - **특정 작업을 수행하기 위해** 작성된 일련의 지침을 포함하는 **실행 파일** @@ -11,7 +16,7 @@ ex) chrome.exe (웹 페이지 보기), notepad.exe (텍스트 파일 편집) - **특징** - - **수동적(정적) 개체(passive entity)**. 실행할 명령어 그룹 저장. + - **수동적(정적) 개체(passive entity)**. 실행할 명령어 그룹을 저장.
당장 실행파일을 열어보면 다양한 명령어가 적혀있는 것을 알 수 있다. 이러한 명령어를 그룹으로 모아저 저장하는 것이 프로그램! - 수동으로 **삭제할 때까지 메모리에 저장**된다. - 프로그램은 **실행 없이 어떤 작업도 수행 불가능.** @@ -31,7 +36,7 @@ - **능동적(동적) 개체(active entity)**. 응용 프로그램의 목적을 수행함 - **수명이 매우 제한적**. 작업이 완료되면 종료된다. - - 프로세스에는 파일 디스크립터(file descriptors), 네트워크 포트와 같은 **시스템 자원이 할당**된다. + - 프로세스에는 OS로부터 **실행에 필요한 자원을 할당**받는다.
ex) 파일 디스크립터(file descriptors), 네트워크 포트, cpu시간, 메모리 영역(Code, Data, Stack, Heap 구조) - 여러 프로세스가 동일한 프로그램과 관련될 수 있다.
ex) 메모장 프로그램의 여러 인스턴스 실행 가능 (각 인스턴스 = 프로세스) - 프로세스에 대한 정보는 **PCB(Process Control Block)**에 저장된다. @@ -72,7 +77,7 @@ | | 프로그램 | 프로세스 | | --------- | ------------------------------------------------ | -------------------------------- | -| 정의 | 프로그래밍 목표를 달성하기 위해 정렬된 작업 그룹 | 프로그램이 실행 중 | +| 정의 | 프로그래밍 목표를 달성하기 위해 정렬된 작업 그룹 | 실행 중인 프로그램 | | 상주 위치 | 디스크 or 보조 메모리 | 주 메모리 | | 개체 유형 | 정적, 수동적 개체(passive entity) | 동적, 능동적 개체(active entity) | | 자원 관리 | 명령어 저장을 위한 메모리만 필요 | 리소스 요구사항이 매우 높음 | @@ -122,6 +127,10 @@ - 구현이 어려움 - 테스트, 디버깅하기 어려움 - 하나의 스레드의 문제가 발생하면 전체 프로세스에 영향을 끼침 +- 사용 사례 + - 영상통신 : 영상을 받아 화면에 출력하는 작업과 영상을 생성하여 보여주는 작업이 동시에 발생 + - 웹 브라우저 : UI를 처리하는 작업과 표시할 데이터를 가져오는 작업이 동시에 발생 + - 게임 : 그래픽을 실행하는 작업과 UI를 그리는 서버통신을 담당하는 소켓 작업이 동시에 발생 ## 프로세스와 스레드 차이점 From a8caea476eafea9fd3c29ff13590e9835597c7ab Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B9=80=EC=A0=95=EC=9C=A4?= Date: Sun, 6 Feb 2022 18:55:45 +0900 Subject: [PATCH 3/5] =?UTF-8?q?create:=20[ETC]=20CI/CD=EB=9E=80=20(#53)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "ETC/CI, CD\353\236\200.md" | 62 +++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 "ETC/CI, CD\353\236\200.md" diff --git "a/ETC/CI, CD\353\236\200.md" "b/ETC/CI, CD\353\236\200.md" new file mode 100644 index 0000000..1f556c6 --- /dev/null +++ "b/ETC/CI, CD\353\236\200.md" @@ -0,0 +1,62 @@ +# CI/CD란 + +## 요약 + +> 애플리케이션의 개발 단계를 자동화하여 짧은 주기로 고객에게 애플리케이션을 제공하는 방법 + +## CI/CD가 나온 배경 + +- 모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기위해 나타난 개념 +- 분업과 협업의 과정에서 코드의 Merge 과정은 까다롭고, 테스트하는데 큰 자원을 소비되게 된다. 이 문제를 해결하기 위해 도입 +- 개발 브랜치가 일정 기간 이상 이용되면, 통합의 어려움은 커지고 충돌 해결에 들어가는 시간이 길어지고 오류 발생 위험이 커진다.
이러한 단점을 극복하고자 변동 내용의 반영 빈도를 늘리는 **자동화**가 등장 + +## CI의 정의 + +- **지속적인 통합(Continuous Integration)** +- 어플리케이션의 **새로운 코드 변경 사항**이 정기적으로 **빌드 및 자동 테스트** 되어 공유 레포지토리에 **통합(병합)**하는 것 +- 개발자를 위한 자동화 프로세스(여러명의 개발자간의 코드 충돌을 방지하기 위한 목적) +- 자동화된 테스트에서 **동작을 확인**하고 변경으로 인해 문제가 생기는 부분이 발견되면 CI를 통해 빠르게 수정 가능 +- 버그를 신속히 찾아 해결하고 소프트웨어 품질 개선, 새로운 업데이트의 검증 및 릴리즈 시간 단축시키는 것이 핵심 목표 + +### CI를 만드는 데 필요한 4가지 규칙 + +- 모든 소스 코드가 있고 누구나 현재 소스(및 이전 버전)를 얻을 수 있는 단일 장소 유지할 것 +- 누구나 단일 명령을 사용하여 소스에서 시스템을 빌드할 수 있도록 빌드 프로세스를 자동화 할 것 + +- 단일 명령으로 언제든지 시스템에서 우수한 테스트 모음을 실행할 수 있도록 테스트 자동화할 것 +- 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것 + +> 이 중 가장 중요한 것이 **테스팅 자동화**!!
지속적인 통합을 하기 위해서는 무엇보다 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있어야만 한다. + +## CD의 정의 + +- **지속적인 서비스제공(Continuous Delivery)** or **지속적인 배포(Continuous Deployment)** + - **지속적인 서비스제공(Continuous Delivery)** + - 공유 레포지토리로 자동으로 Release 하는 것 + - 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포 가능 (**수동적 배포**) + - 프로덕션 환경으로 배포할 준비가 되어 있는 **코드베이스를 확보**하는 것이 목표 + - **지속적인 배포(Continuous Deployment)** + - 프로덱션 레벨까지 자동으로 deploy 하는 것 + - 애플리케이션을 프로덕션으로 릴리스하는 작업을 **자동화** + - 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 애플리케이션을 **자동으로 실행**할 수 있는 것을 의미 +- 간단히 말하면 **배포 자동화 과정** +- 서버가 많을 경우 개발자가 일일이 배포를 진행하지 않아도 되므로, 리소스가 낭비되지 않는다. + +![CI/CD flow](https://www.redhat.com/cms/managed-files/styles/wysiwyg_full_width/s3/ci-cd-flow-desktop_edited_0.png?itok=TzgJwj6p) + +## CI/CD 종류 + +- Jenkins +- CircleCI +- TravisCI +- Github Actions + +등.. + +## 참고 + +- https://www.youtube.com/watch?v=0Emq5FypiMM&t=10s + +- https://www.redhat.com/ko/topics/devops/what-is-ci-cd +- https://devuna.tistory.com/56 +- https://www.martinfowler.com/articles/originalContinuousIntegration.html \ No newline at end of file From 4613c11e1ec45194b6f9708439df1201af98b315 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B9=80=EC=A0=95=EC=9C=A4?= Date: Sun, 17 Apr 2022 19:54:25 +0900 Subject: [PATCH 4/5] =?UTF-8?q?create:=20[ETC]=20TDD=20=EB=B0=A9=EB=B2=95?= =?UTF-8?q?=EB=A1=A0=20(#95)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...D \353\260\251\353\262\225\353\241\240.md" | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 "ETC/TDD \353\260\251\353\262\225\353\241\240.md" diff --git "a/ETC/TDD \353\260\251\353\262\225\353\241\240.md" "b/ETC/TDD \353\260\251\353\262\225\353\241\240.md" new file mode 100644 index 0000000..4ecc2e3 --- /dev/null +++ "b/ETC/TDD \353\260\251\353\262\225\353\241\240.md" @@ -0,0 +1,96 @@ +# TDD 방법론 + +## TDD란? + +- **테스트 주도 개발**(Test Driven Development : TDD)은 반복 테스트를 이용한 소프트웨어 방법론 중 하나 +- 선 개발 후 테스트 방식이 아닌 **선 테스트 후 개발 방식의 프로그래밍 방법** +- 다시 말해 자동화된 **작은 단위**의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 **반복**하여 구현한다. (ex. **JUnit**) +- **짧은 개발 주기의 반복**에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 단순한 설계를 중요시한다. + +> ❓ eXtream Programming(XP) 이란? +> +> - 미래에 대한 예측을 최대한 하지 않고, 지속적으로 프로토타입을 완성하는 애자일 방법론 중 하나 +> - 추가 요구사항이 생기더라도, 실시간 반영 가능 + +## TDD 개발 프로세스 + +TDD의 개발 방식을 알기 전 일반 개발 방식에 대해 알아보자 + +### 일반 개발 방식 + +``` +요구사항 분석 -→ 설계 및 디자인 -→ 코드개발 -→ 테스트 -→ 배포 + ↑______________________| +``` + +이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다. + +- 소비자의 요구사항이 처음부터 명확하지 않을 수 있다. 따라서 처음부터 완벽한 설계는 어렵다. + - 당연히 어느 프로젝트든 초기 설계가 완벽하다고 말할 수 없다. 재설계를 통해 점진적으로 완벽한 설계로 나아간다. + - 그러나 이 방식의 경우 재설계로 인해 삽입, 수정, 삭제 하는 과정에서 불필요한 코드가 남거나 중복처리 될 가능성이 크다. +- 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다. + - 작은 부분의 기능 수정에도 모든 부분을 테스트해야 한다. (**전체적인 버그 검출이 어려워짐**) + - 어디서 버그가 발생할지 모르기 때문에 잘못된 크드도 고치지 않으려 하는 현상이 나타난다. +- 자체 테스트 비용이 증가할 수 있다. + +📌 **즉, 결론적으로 재사용이 어렵고 관리가 어려워져 유지보수가 어렵다.** + +### TDD 개발 방식 + +``` + ┌---리팩토링----┐ + ↓ | +요구사항 분석 -→ 설계 및 디자인 -→ 테스트 코드 -→ 코드개발 -→ 배포 + ↑______________| +``` + +아래 그림은 개발 주기를 나타낸 것이다. + +- RED : 실패하는 테스트 코드 작성 + - 실패 이유는 테스트 코드의 문제가 아닌 **운영 코드가 아직 변경되지 않았기 때문**이어야 한다. +- GREAN : 테스트 코드를 통과하기 위한 실제 코드 작성 +- REFACTOR : 리팩토링 수행 (불필요한 코드 제거, 일반화 등) + +![TDD-개발주기](https://i0.wp.com/hanamon.kr/wp-content/uploads/2021/04/TDD-%E1%84%80%E1%85%A2%E1%84%87%E1%85%A1%E1%86%AF%E1%84%8C%E1%85%AE%E1%84%80%E1%85%B5.png?fit=1024%2C680&ssl=1) + +**📌 POINT!!** + +- 실패하는 테스트 코드를 작성할 때까지 실제 코드 작성하지 않아야 한다 +- 실패하는 테스트를 통과할 정도의 **최소 실제 코드**를 작성해야 한다 +- 이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다. + +## TDD 장점 + +1. 객체 지향적 코드 개발 가능 + - TDD는 코드의 재사용을 보장해서 TDD를 통한 소프트웨어 개발 시 기능별 모듈화가 이루어짐 + - 이는 의존성과 종속성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 함 + - 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향 X +2. 설계 수정시간의 단축 + - 테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발 시작 +3. 유지보수의 용이성 + - 단위 테스트 기반의 테스트 코드를 작성하므로 추후 문제가 발생했을 때 각각의 모듈별로 테스트 진행 가능 +4. 테스트 문서의 대체 가능 + - 일반 개발 방식에서의 테스트 정의서는 단순 통합 테스트 문서에 지나지 않는다. + - 하지만 TDD를 하게 된다면 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다. + +## TDD 단점 + +1. 사전준비 기간 + - 사전에 필요한 지식을 습득하고 개발 환경 구축해야 함 + - 효과적으로 사용할 수준이 되는데 보통 1 ~ 6개월의 시간이 필요 +2. 생산성 저하 + - 2개의 코드를 작성해야 하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문에 일반 개발 방식에 비해 **개발 시간이 10~30% 증가** + - SI 프로젝트와 같이 품질보다 납기일 준수가 훨씬 중요한 경우 TDD를 잘 사용하지 않는다. + +> ❓ 실제로 TDD가 많이 쓰일까? +> +> - TDD 사용에 대해서는 아직도 많은 논쟁이 있다. 특히 많이 고민하는 문제가 바로 **생산성 저하** +> +> - TDD는 비용적인 측면에서 고민해야 한다. 테스트 코드를 짜는 것 또한 엄연한 개발이기 때문에 시간 투자 대비 이익이 있어야 한다. 너무 과도하게 테스트에 몰입해버린다면 시간 낭비나 다름없다. +> - 즉, 적당한 TDD는 개발에 있어 능률 상승을 가져오지만 과도한 테스트는 오히려 해롭다. + +## Ref + +- https://wooaoe.tistory.com/33 +- [http://www.incodom.kr/테스트-주도-개발](http://www.incodom.kr/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C) +- [TDD는 항상 옳지 않다(비용의 문제)](https://architecture101.blog/2014/04/25/tdd-isnot-always-true/) \ No newline at end of file From 2827883c429e81f2ce04372c3c39b3967792b92a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B9=80=EC=A0=95=EC=9C=A4?= Date: Sun, 17 Apr 2022 22:54:04 +0900 Subject: [PATCH 5/5] =?UTF-8?q?update:=20[ETC]=20TDD=20=EB=B0=A9=EB=B2=95?= =?UTF-8?q?=EB=A1=A0=20(#95)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "ETC/TDD \353\260\251\353\262\225\353\241\240.md" | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git "a/ETC/TDD \353\260\251\353\262\225\353\241\240.md" "b/ETC/TDD \353\260\251\353\262\225\353\241\240.md" index 4ecc2e3..162450f 100644 --- "a/ETC/TDD \353\260\251\353\262\225\353\241\240.md" +++ "b/ETC/TDD \353\260\251\353\262\225\353\241\240.md" @@ -30,7 +30,7 @@ TDD의 개발 방식을 알기 전 일반 개발 방식에 대해 알아보자 - 그러나 이 방식의 경우 재설계로 인해 삽입, 수정, 삭제 하는 과정에서 불필요한 코드가 남거나 중복처리 될 가능성이 크다. - 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다. - 작은 부분의 기능 수정에도 모든 부분을 테스트해야 한다. (**전체적인 버그 검출이 어려워짐**) - - 어디서 버그가 발생할지 모르기 때문에 잘못된 크드도 고치지 않으려 하는 현상이 나타난다. + - 어디서 버그가 발생할지 모르기 때문에 잘못된 코드도 고치지 않으려 하는 현상이 나타난다. - 자체 테스트 비용이 증가할 수 있다. 📌 **즉, 결론적으로 재사용이 어렵고 관리가 어려워져 유지보수가 어렵다.**