전체 글

Cache 액션을 사용하면 GitHub Actions에서 workflow가 실행될 때, 잘 바뀌지 않는 파일들을 깃허브 캐시에 올려놓고 CI 서버로 내려받을 수 있음 즉, workflow 성능 최적화에 도움이 됨 의존하고 있는 라이브러리들을 매번 네트워크(원격 저장소)에서 받아 오는 것이 아닌 캐시에 저장해두고 활용 실습 react 프로젝트를 하나 생성하여 package.json에 있는 라이브러리들을 캐싱해보자 1. 테스트용 react-app 생성 $npx create-react-app actions-cache 2. Cache 적용 전 Actions 실행 cache.yml name: cache workflow on: push jobs: cache: runs-on: ubuntu-latest steps: -..

Workflow GitHub Actions의 상위 개념 자동화 해놓은 작업 과정이며 repository내에 .github/workflows폴더 아래 yaml 파일로 설정 가능 여러 개의 워크폴로우 설정 가능 2가지 속성 정의 필요 on : 워크플로우가 언제 실행되는지 정의 jobs : 워크플로우가 구체적으로 어떤 일을 해야하는지 명시 on: push: branches: - master - dev pull_request: branches: - dev jobs: # ... master, dev 브랜치에 push이벤트가 발생할 때 마다 workflow를 실행해라. dev 브랜치에 PR이벤트가 발생할 때 마다 workflow를 실행해라. Jobs 독립된 가상 머신 또는 컨테이너에서 돌아가는 하나의 처리 단위 의..

상속은 굉장히 강력한 기능인 만큼 여러 가지 문제를 발생시킬 수 있다. 따라서 단순하게 코드 추출 또는 재사용을 위해 상속을 한다면 신중하게 생각해봐야 한다. 간단한 행위 재사용 슈퍼 클래스를 만들어서 공통 행위를 추출한 경우 abstract class LoaderWithProgess { fun load() { // 프로그레스 바 보여줌 innerLoad() // 프로그레스 바 숨김 } abstract fun innerLoad() } class ProfileLoader: LoaderWithProgress() { override fun innerLoad() { // 프로파일 읽어 들임 } } class ImageLoader: LoaderWithProgress() { override fun innerLoad..

SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는 데 있다. 변경에 유연하다. 이해하기 쉽다. 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다. 중간 수준? - 모듈 수준에서 작업할 때 적용할 수 있음. 즉, 코드 수준보다는 조금 상위에서 적용되며 모듈과 컴포넌트 내부에서 사용되는 소프트웨어 구조를 정의하는데 도움을 줌 단일 책임 원칙 (SRP - Single Responsibility Principle) 하나의 모듈(단일 모듈)은 변경의 이유가 오직 하나뿐이어야 한다. 하나의 모듈은 하나의 액터에 대해서만 책임져야 한다. 액터? 해당 변경을 요청하는 집단을 뜻함 모듈이 단 하나의 일만 해야 한다라는 뜻이 아니다. 단 하나의 일만 해야하는 원칙은 함수다. 함수는..

1. JobBuilder Job과 Step을 쉽게 생성/설정할 수 있도록 util 성격의 빌더 클래스 JobBuilderFactory JobBuilder를 생성하는 팩토리 클래스 - get(name: String) jobBuilderFactory.get("jobName") "jobName"은 스프링 배치가 Job을 실행시킬 때 참조하는 Job의 이름 메타 테이블에 해당 이름으로 Job이 관리됨 JobBuilder Job 구성 설정 조건에 따라 두 개의 하위 빌더 클래스를 생성하고 실제 Job생성을 위임함 SimpleJobBuilder SimpleJob을 생성하는 Builder 클래스 FlowJobBuilder FlowJob을 생성하는 Builder 클래스 2. SimpleJob Step을 실행시키는 Jo..

1. JobLauncherApplicatinRunner Spring Batch 작업을 시작하는 ApplicationRunner 로서 BatchAutoConfiguration에서 생성됨 스프링 부트에서 제공하는 ApplicatinRunner의 구현체이며 애플리케이션이 구동되지 마자 실행됨 기본적으로 빈으로 등록된 모든 Job을 샐행하며, 설정으로 특정 Job만 실행하도록 변경할 수 있음 BatchAutoConfiguration.class JobLauncherApplicationRunner를 bean으로 등록 custom bean을 등록해도 상관 없음 @Bean @ConditionalOnMissingBean @ConditionalOnProperty( prefix = "spring.batch.job", nam..

객체 지향 프로그래밍 1966년 등장 알골(ALGOL)언어의 함수 호출 스택 프레임(stack frame)을 힙(heap)으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견 이러한 함수가 클래스의 생성자, 지역 변수는 인스턴스 변수, 중첩 함수는 메소드가 되었음 객체 지향(Object-Oriented)란 무엇일까? 데이터와 함수의 조합? 그다지 만족스러운 대답은 아님, OOP 등장 이전에도 프로그래머는 데이터 구조를 함수에 전달해 왔다. 실제 세계를 모델링하는 새로운 방법? "실제 세계를 모델링한다"라는 말은 무엇을 의미하는 걸까? 왜 우리는 그 방향을 추구해야하는가? OO는 현실 세계와 의미적으로 가깝기 때문에 OO를 사용하면 소프트웨어를 좀 더 쉽게..

소프트웨어 개발자는 행위(behavior), 구조(structure)이 두 가지 가치를 반드시 높게 유지해야 하는 책임을 가진다. 행위에만 집중하게 된다면 소프트웨어 시스템은 쓸모없게 된다. 행위, 동작(Behavior) 프로그래머는 이해관계자나 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다. 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성한다. 많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각하지만(버그 수정 및 기능 개발), 이 것은 틀렸다. 아키텍처(Architecture) 소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 부드러워야 한다. 다시 말해 변경하기 쉬어야 한다. 이해관계자가 기능에 대한 생각을 바꾸면, 변경사항을 간단하고 쉽게 적용할..

설계(design)와 아키텍처(architecture) 설계와 아키텍처에는 아무런 차이가 없다. 단지.. 아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬때 흔히 사용되며 설계는 저수준의 구조 또는 결정사항 등을 의미할 때 많이 사용된다. 좋은 소프트웨어 설계의 목표? 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는데 있다. 좋은 아키텍처? 좋은 소프트웨어? 왜 좋은 소프트웨어를 만들어야 하는가?라는 질문이 거창한 대답을 요구할 것 같지만 결론은 유지보수 비용을 줄이기 위함이다. 아무리 복잡한 프로젝트여도 말이다. 생각해봐야 할 점 소프트웨어 제품이 잘 팔린다 -> 엔지니어링 직원 수를 뽑아 제품을 개발한다 -> 시간이 지날수록 코드 라인당 비..

CQRS(Command Query Responsibility Segragation)은 상태를 변경하는 명령(Command)모델과 조회(Query)를 위한 모델을 분리하는 패턴이다. CQRS를 적용하면 어떤 장점이 있을까? 단일 모델의 단점 주문 내역 조회기능을 구현하려면 여러 애그리거트에서 데이터를 가져와야 한다. Order: 주문 정보 Product: 상품 이름 Member: 회원 이름, ID 여러 애그리거트의 데이터가 필요한데 어떻게 구현해야할까? 식별자를 이용하여 애그리거트를 참조하는 방식 즉시 로딩(eager loading)과 같은 JPA 쿼리 최적화 기능을 사용할 수 없음 한 번의 SELECT 쿼리로 조회 화면에 필요한 데이터를 구할 수 없음(성능상 문제 발생) 직접 애그리거트를 참조하는 방식 ..