자라나기

생성자 대신 정적 팩터리 메서드를 고려하라. 장점 이름을 가질 수 있다. 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다. 반환 타입의 하위 타입 객체를 반환할 수 있다. (반환할 객체의 클래스를 자유롭게 선택할 수 있다.) 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다. (인터페이스를 반환해도 된다.) 단점 상속을 하려면 public이나 protected 생성자가 필요해서, 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다. 클래스를 인스턴스화 하는 방법을 API 문서에 잘 써놓아야 한다. 흔히 사용되는 명명 방식: from, of, valueOf, instance, getInstance, create, ..

@EventListener @Transactional public void publishEvent(String message) { repository.save(message); // 롤백 됨 MyEvent myEvent = new MyEvent(message); eventPublisher.publishEvent(myEvent); // 에러 발생 System.out.println("after event"); // 출력되지 않음 } @EventListener public void handleEvent(MyEvent myEvent) { // 에러 발생 } @EventListener + @Async @Transactional public void publishEvent(String message) { repos..

테스트 > 테스트를 통과할 만큼의 코딩 > 리팩토링 > 테스트 테스트를 통과시킬 만큼의 기능을 구현한다. 아직 추가하지 않은 테스트를 고려해서 구현하지 않는다. 첫 번째 테스트는 가장 쉽거나 가장 예외적인 상황을 선택한다. 첫 번째 테스트로 만들어야 할 코드가 길어지면 구현을 다 하고 테스트를 하는 방식과 다르지 않다. 테스트 코드도 코드이기 때문에 유지보수를 해야 한다. 각 테스트 메서드에서 발생하는 중복을 알맞게 제거하거나 의미가 잘 드러나도록 수정한다. 중복을 제거한 뒤에 오히려 테스트 코드 관리가 어려워진다면 제거했던 중복을 되돌려야 한다. TDD를 시작할 때 테스트할 목록을 미리 정리하면 좋다. 그 중 어느 테스트가 구현이 쉬울지, 또는 어느 테스트가 예외적인지 생각해본다. 범위가 큰 리팩토링은..

사용자를 위한 API 디자인하기 프로바이더가 아닌 컨슈머의 입장에서 디자인한다. 데이터 모델을 그대로 노출하지 않는다. e.g. 테이블이 2개라고 api를 2개 제공하거나, 이해하기 어려운 데이터 이름을 그대로 사용하기 No! 비즈니스 로직을 그대로 노출하지 않는다. e.g. 고객 주소를 가져와서, 주소를 수정하고, 새주소 추가 api들을 제공하는 대신(이는 비즈니스 로직을 컨슈머에게 위임하는 것이며, 컨슈머가 api 사용을 깜빡할시 치명적 문제가 될 수 있다), 고객 주소 수정 api 하나만 제공하기 소프트웨어 아키텍처를 그대로 노출하지 않는다. e.g. 상품 정보와 상품 가격이 다른 시스템에서 처리된다고 상품 검색, 상품 가격 조회 api 2개를 제공하기 No! API를 디자인할 때 질문하기 누가 사..

박상철 외 8인 지음 어떤 일을 시작할 때면 그 일을 해야 할 개인적인 의미를 찾아 가능한 강한 내적 동기를 가지고 일하려고 의식적으로 노력했다. 정 동기가 찾아지지 않으면 일부러 내가 하고 싶은 일을 그 과제에 섞어넣기도 했다. 오류가 발생하면 소스 코드 레벨에서 이해하자. 해당 오류를 스택오버플로우에서 검색하면 대부분은 손쉽게 해결책을 얻을 수 있다. 여기서 끝내버리면 깊은 지식을 얻기 어렵다. 해당 툴의 소스 코드를 확인하면 어떻게 해야하는지 깊은 지식을 얻을 수 있고, 파생되거나 비슷한 문제를 예방할 수도 있게 된다. 좋은 정보를 뇌에 입력하는 것도 좋지만, 제대로 이해하고 있는지 확인받는 것도 중요하다. 아예 모르는 것보다 잘못 아는 것이 위험하다. 가급적이면 결과물을 공개해 다른 사람의 조언을..

sideInput() sideInput()은 파이프라인의 한 단계에서 처리되는 메인 입력 PCollection 외에 추가적인 입력 데이터를 제공하는 방식이다. 파이프라인은 PCollection을 처리해 결과 데이터를 다시 PCollection으로 반환한다. 그런데 PCollection 처리 과정에서 다른 데이터를 참고해야 하는 경우가 있다. 예를 들어, 주문 정보를 처리하며 할인 정보를 참고하는 경우가 있을 수 있다. 추가적인 입력 데이터를 파이프라인 처리 전에 묶어서 새로운 타입의 input을 만들 수도 있겠지만, 각 데이터 처리에서 공용으로 접근해서 참고할 불변의 데이터라면 sideInput을 사용하는 게 낫다. sideinput은 메모리에 한 번만 로드하면 되기에 더 효율적이다. sideInput(..

Electron Electron은 웹 기술(HTML, CSS, JavaScript)을 사용하여 데스크톱 애플리케이션을 만들기 위한 오픈 소스 프레임워크다. Chromium 브라우저와 Node.js 런타임 환경을 내장하고 있어서 웹 개발자들이 친숙하게 데스크톱 애플리케이션을 개발할 수 있다. Main Process Electron에는 Main Process와 Renderer Process라는 두 개의 별도의 프로세스가 있다. Main Process는 전체 Electron 애플리케이션에서 단 하나만 존재한다. Main Process는 Node.js 환경에서 동작하며, Electron의 주요 모듈과 네이티브 API를 사용할 수 있다. 주요 기능은 앱의 라이프사이클을 관리하고, 각종 네이티브 API를 노출시켜 ..

쿠버네티스란? 가장 대표적인 컨테이너 오케스트레이션 시스템으로, 사실상 표준이다. 구글에서 사용하던 배포시스템 borg를 기반으로 재작성해 2014년에 오픈소스로 공개하였다. 심심하면 아래 문서를 읽자. Concepts Production-Grade Container Orchestration kubernetes.io 컨테이너 오케스트레이션 시스템이란? 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하는 기술 Docker, Docker Compose는 하나의 머신에서 컨테이너를 관리하기 위한 기술이다. 컨테이너 오케스트레이션 시스템은 여러 머신으로 구성된 클러스터 상에서 컨테이너를 효율적으로 관리하기 위한 시스템이다. 쿠버네티스 외에 Rancher, Apache MESOS, Nomad, Docker Sw..

컨테이너 기술의 발전 Traditional Deployment: Hardware - Operating System - App(Libs & Frameworks) 문제점: 서비스가 점점 커지면서 한 서버에서 운영하는 서비스가 여러 개가 되면, 각각의 서비스에 필요한 라이브러리에 대해 의존성 충돌이 생길 수 있다. 관리가 어려워지고 서비스의 확장성이 낮아진다. Virtualized Deployment Hardware - Operating System - Hypervisor - Virtual Machines (Operating System - App(Libs & Frameworks)) 운영체제 상의 Hypervisor 컴포넌트를 통해 게스트OS(별도의 CPU, RAM, HDD 등)를 만든다. 하나의 Virtua..

주문이 한꺼번에 몰리는 한정판 판매를 구현할 때, 재고 수량의 정합성을 어떻게 보장할 수 있을까?! 문제점 아래는 Spring Framework, JPA를 사용한 재고 시스템 코드이다. 주문 시에 재고(Stock) 엔티티의 quantity의 값이 차감되어, 0이 되면 더이상 주문이 불가능하다. 이 코드에는 문제가 있다. package com.example.domain; @Entity @Getter public class Stock { @Id @GeneratedValue(strategy = GeneratedType.Identity) private Long id; private Long productId; private Long quantity; public Stock(Long productId, Long ..