CS

CPU 스케줄링이란? 프로세스는 생성된 후 여러 상태를 거침 (생성, 준비, 실행, 완료, 대기 상태) 이때, 운영체제의 CPU 스케줄러는 준비 상태의 프로세스 중에서 어떤 프로세스에게 CPU를 할당할지 결정해야함! 이 과정을 CPU 스케줄링이라 함 ➡️ CPU 스케줄링 알고리즘에 따라서 프로세스에서 해야 하는 일을 스레드 단위로 CPU에 할당 CPU 스케줄링 알고리즘의 목표 : CPU 이용률은 높게, 주어진 시간에 많은 일을 하게, 준비 큐에 있는 프로세스는 적게, 응답시간은 짧게 설정하는 것 CPU 스케줄링 알고리즘의 종류 CPU 스케줄러는 언제 스케줄링을 결정할까? 1) 실행상태에서 대기상태로 전환될 때 2) 실행상태에서 준비상태로 전환될 때 3) 대기상태에서 준비상태로 전환될 때 4) 종료될 때 ..

MVC 패턴 : 모델(Model), 뷰(view), 컨트롤러(Controller)로 이루어진 디자인 패턴 → 애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있음 장점: 재사용성과 확정성이 용이함 단점: 애플리케이션이 복잡해질수록 모델과 뷰의 관계도 복잡해짐 모델 : 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻함 💡 ex) 사각형 모양의 박스 안에 글자가 들어 있다면 그 사각형 모양의 박스 위치 정보, 글자 내용, 글자 위치, 글자 포맷에 관한 정보를 모두 가지고 있어야 함. → 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신함 뷰 : 모델을 기반으로 사용자가 볼 수 있는 화면(UI)을 뜻함 → inp..

SOLID 란? → 객체지향 설계 시 지켜야 하는 설계 원칙 5가지를 줄여서 부름 시간이 지나도 유지보수와 확장이 용이한 시스템을 만들고자 할 때 적용하는 원칙 장점: 유연성, 재사용성, 유지보수성이 높아짐 1) 단일 책임 원칙 SRP : 한 클래스는 하나의 책임만 가져야 하고 클래스를 변경하는 이유도 단 하나여야 한다. 지키지 않을 시, 한 책임의 변경에 의해서 다른 책임과 관련된 코드에 영향을 미칠 수 있음 유지보수가 매우 비효율적이게 됨 책임 = 기능 한 클래스가 수행할 수 있는 기능이 여러 개라면, 클래스 내부의 함수에서 결합도가 높아짐 응집도는 높고 결합도는 낮은 프로그램을 설계하는 것이 객체지향 설계의 핵심 책임을 잘게 쪼개어 분리시킬 필요가 있음 ex) A 라는 메소드가 있고, A 메소드는 ..

💡 디자인 패턴이란?: 프로그램 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 규약 형태로 만들어 놓은 것을 의미한다! 싱글톤 패턴 : 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다. 하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스를 만들 수 있지만, 그렇게 하지 않고 하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 이를 기반으로 로직을 만드는 데 쓰이며, 보통 데이터베이스 연결 모듈에 많이 사용된다! 장점 하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 생성할 때 비용이 적게 즘 단점 모듈 간 결합을 강하게 만들기 때문에 의존성(종속성)이 높아짐 TDD를 할 때 걸림돌이 됨 단위 테스트는 테스트가 서로..

모듈화 : 소프트웨어를 각 기능별로 나눈 것 목적에 맞는 기능들로 모듈화하여 나누는 것이 좋은 모듈화! 모듈 : 모듈화로 나눠진 각각의 기능을 가진 것 모듈의 기능은 독립적으로 수행되어야 하고, 다른 모듈과는 연관도가 적어야지 좋은 것 응집도는 높게, 결합도는 낮게 결합도 : 서로 다른 모듈 간에 연관된 관계, 간단할 일만 주고 받기 Java에서는 class 간에 결합도가 높다 = 연관도가 높다 로 판단. 해당 class를 변경하면 연관된 class도 변경하기. 변경하지 않으면 다른 class에서도 재사용하기 힘듬 응집도 : 한 모듈 내부 안 처리 요소들 간에 관계, 응집도가 낮으면 재사용과 이해가 힘듬

TDD: 켄트백 테스트 케이스 -> 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하며 구현하는 방식 Test Driven 개발 실패하는 테스트를 만든다 실패를 제거한다 리팩토링 개발 순서 Red 단계에서는 실패하는 테스트 코드를 먼저 작성한다. Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다. 최대한 빠르게 작업 작업시간이 10분이 넘지 말아야 함 5분 추천 꼼수를 써도 됨 Blue 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다. 다시 1단계 부터 반복

자바 진영의 대표적인 테스트자동화 도구 : JUNIT 앱A 회원(가입, 이메일인증,로그인,로그아웃, 정보수정) 글(글CRUD,댓글CRUD, 좋아요, 알림) 1 관리(관리자페이지) 가입, 가입테스트 이메일인증, 가입테스트, 이메일인증테스트 로그인, 가입테스트, 이메일인증테스트, 로그인테스트 로그아웃, 가입테스트, 이메일인증테스트, 로그인테스트, 로그아웃테스트 * 1시간(스트레스 많음, 자신감하락), 2~3초(스트레스 제로, 자신감) 테스트케이스 => 사람이 아니라 기계가 테스트한다. 테스트 자동화