리팩토링 후 새로운 인수 유형을 추가하기 쉬워짐 -> 새 테스트 케이스를 추가하고, 새 Marshaler 클래스를 작성하고, 새 에러 코드와 get함수를 추가하면 됨 리팩터링 - 예외 처리 분리 예외 클래스를 모두 모아 ArgsException으로 통일 => 잡다한 오류 지원 코드를 ArgsException이라는 독자적인 모듈 안으로 옮겨올 수 있게 됨 => Args 모듈에서 예외/오류 처리 코드를 분리

setArgument 함수에서 유형을 일일이 확인하는 방식에서 set 함수를 적절한 파생 클래스로 내려 호출을 간단하게 만드는 과정 if-else 연쇄문에서 오류 코드를 꺼냄 setBooleanArg 함수부터 모든 책임을 BooleanArgumentMarshaler로 전가하는 식으로 리팩토링 ArgumentMarshaler에 set 메서드 추가 setBooleanArg 제거 -> set함수는 이제 BooleanArgumentMarshaler가 관리 String과 Integer 인수를 다루는 Arg 함수들도 같은 방식으로 변경 인수 유형을 일일이 확인하던 코드 제거 모든 과정은 테스트 코드와 함께하며, 각 단계마다 테스트 케이스들이 정상적으로 통과되는지 확인하며 진행

첫 번째 리팩터링을 끝냈으나, 여전히 지저분한 코드 첫머리의 변수들이 지저분하게 남아 있음 setArgument의 유형을 일일이 확인하는 코드 모든 set 함수 및 이곳저곳에 중복으로 존재하는 오류 처리 코드 -> setArgument 함수에서 유형을 일일이 확인하는 코드를 없애고 ArgumentMarshaler.set만 호출하면 되도록 리팩토링.

String 인수 먼저 각 인수 유형을 처리하는 코드를 모두 ArgumentMarshaler 클래스에 넣고 나서 파생 클래스를 만들어 코드를 분리함. => 프로그램 구조를 조금씩 변경하는 동안에도 시스템의 정상 동작을 유지하기 쉬워지기 때문 테스트 케이스를 통과하는지 지켜보면서 점진적으로 코드를 옮기고, 바꾼 코드로 테스트를 통과하면 기존 코드를 제거하는 행위를 반복한다.

어떻게 짰느냐고? 한 번에 깨끗하고 우아한 프로그램을 내놓는 것은 불가능하다. -> 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다. 코드가 돌아가는 것에 만족하지 않고 점진적인 개선을 해야 한다. Args: 1차 초안 코드는 돌아가지만 엉망이다. boolean 인수만 지원하던 첫 버전은 괜찮았으나, 지원하는 타입을 추가하면서 코드가 복잡하고 엉망이 되어갔다. -> 초기 코드에서 새 인수 유형을 추가하려면 주요 지점 세 곳에다 코드를 추가해야 했기 때문 따라서 기능을 추가하는 것을 멈추고 리팩토링을 시작했다. -> 인수 유형을 다양하지만 모두가 유사한 메서드를 제공하므로 ArgumentMarshaler 클래스를 탄생시켰다. 점진적으로 개선하다 개선이라는 이름 아래 구조를 크게 뒤집는 행..

점진적인 개선 Args 유틸리티를 구현하고 점진적으로 개선한 사례를 보인다. Args는 명령행 인수의 구문 분석을 위한 유틸리티이며 두 개의 매개변수를 받는다. 첫째 매개변수는 형식 또는 스키마를 지정하는 문자열이다. 둘째 매개변수는 구문 분석을 할 명령행 인수 배열이다. 형식 문자열이나 명령행 인수에 문제가 있을 경우 ArgsException이 발생한다. Args 구현 세부 로직을 이름을 붙여 별도의 모듈로 분리했고, 위에서 아래로 읽히도록 호출한 코드 아래에 모듈 코드를 배치했다. 스키마를 parse하는 메서드와 인자값을 parse하는 메서드를 명시적으로 나누었고 각각 호출한다. 인자를 다루는 로직은 인자의 타입별로 ArgumentMarshaler를 파생한 별개의 클래스를 만들어 처리한다. => 새로..

스레드 코드 테스트하기 말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라 스레드 코드의 버그는 실패를 재현하기가 어려워, 일회성 문제로 치부되곤 함 -> 시스템 실패를 일회성이라 치부하지 말 것. 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자 스레드 환경 밖에서 코드가 제대로 도는지 먼저 확인하기 -> 스레드가 호출하는 POJO를 만들어서 테스트 가능 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라 다양한 설정으로 실행하기 쉽게 구현하기 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라 스레드 개수를 조율하기 쉽게 코드를 구현, 프로그램이 돌아가는 도중에 스레드 개수를 변경하는 방법이나 프로그램 스스로 스레드 개수를 조..

(참고 : https://react-ko.dev/learn/render-and-commit) 리액트의 렌더링이란? 리액트에서 컴포넌트를 호출하는 것. 컴포넌트는 언제 렌더링되는가? 처음 화면에 등장할 때(초기 렌더링) 첫 렌더링에서 리액트는 루트 컴포넌트를 호출. 컴포넌트의 state가 업데이트되었을 때 이 경우 리액트는 state 업데이트에 의해 렌더링이 발동된 함수 컴포넌트를 호출. 렌더링은 재귀적이다. 만약 렌더링되는 컴포넌트가 다른 컴포넌트를 반환할 경우, 리액트는 다음으로 해당 컴포넌트를 렌더링하며, 이는 중첩된 컴포넌트가 더 이상 없거나 리액트가 화면에 표시될 내용을 정확히 알 때까지 계속됨 부모 컴포넌트가 렌더링되면, 모든 자식 컴포넌트도 렌더링된다. 리액트의 커밋이란? 컴포넌트의 렌더링 이..

동시성 방어 원칙 동시성 코드가 일으키는 문제로부터 시스템을 방어하는 원칙과 기술을 소개한다. 단일 책임 원칙(SRP) 동시성 코드는 다른 코드와 분리하라. 따름 정리 : 자료 범위를 제한하라 공유 객체를 사용하는 코드 내 임계영역의 수를 줄여야 한다. -> 임계영역의 수가 많으면 보호 코드를 빼먹거나, 반대로 코드 확인에 많은 수고를 들이게 된다. -> 자료를 캡슐화하여 공유 자료를 최대한 줄여라. 따름 정리: 자료 사본을 사용하라 공유 자료를 줄이기 위해 스레드가 객체의 사본에서 결과를 가져오는 방법도 가능하다. 따름 정리: 스레드는 가능한 독립적으로 구현하라 다른 스레드와 자료를 공유하지 않고, 각자 클라이언트 요청 하나를 처리하는 독립적인 스레드를 만들어라. -> 동기화 문제를 예방할 수 있다. ..

동시성 동시성 : 여러 스레드를 동시에 돌리는 것 동시성을 구현한 코드를 깨끗하게 짜는 것은 어렵고 복잡하다. 동시성이 필요한 이유 동시성은 무엇과 언제를 분리하는 전략. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하지만, 이를 분리하면 프로그램을 작은 협력 프로그램 여럿으로 나눌 수 있다. => 구조/효율 개선 가능. 또한 응답 시간과 작업 처리량 개선을 위해 동시성 구현을 꼭 해야만 하는 경우도 있음 -> 웹 사이트의 정보 수집기. 미신과 오해 동시성과 관련된 일반적인 미신과 오해는 다음과 같다. 동시성은 항상 성능을 높여준다. -> X, 동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많..