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

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

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

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

창발성 창발성 : 하위 계층(구성 요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상. 창발적 설계로 깔끔한 코드를 구현하자 켄트 백은 다음 규칙을 따르면 설계는 단순하다고 말한다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위 목록은 중요도 순임. 단순한 설계 규칙 1: 모든 테스트를 실행하라 테스트가 없으면 시스템이 의도한 대로 돌아가는지 검증이 불가능하다. 또한 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 높아진다. => 테스트가 쉽게 코드를 작성하게 되어, 크기가 작고 목적 하나만 수행하는 클래스가 나오게 됨. 테스트 케이스를 만들고 계속 돌리라는 규칙을 따르면, 시스템은 낮은 결합도와..

순수 자바 AOP 프레임워크 순수 자바 관점을 구현하는 여러 자바 프레임워크는 내부적으로 프록시를 사용 프로그래머가 설정 파일이나 API를 사용해 필수적인 애플리케이션 기반 구조를 구현하면, 프레임워크는 사용자 모르게 프록시나 바이트코드 라이브러리를 사용해 이를 구현함 => 애플리케이션은 사실상 프록시 라이브러리와 독립적이게 되며, 복잡한 프록시 논리 없이 단순한 구현이 가능함 => 코드가 깨끗해지고, 테스트하기 쉬워짐 AspectJ 관점 관심사를 관점으로 분리하는 가장 강력한 도구 : AspectJ 언어 AspectJ : 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장. 풍부한 도구 집합을 제공하지만, 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야 한다는 단점이 있음 => 최근에 나..

의존성 주입 사용과 제작을 분리하는 강력한 메커니즘 중 하나. 제어 역전 기법을 의존성 관리에 적용 -> 한 객체가 맡은 보조 책임을 새로운 객체에 전부 떠넘기는 기법 -> 책임을 다른 메커니즘(주로 main 루틴이나 특수 컨테이너)에 전담해 넘김으로써 제어를 역전 +클래스가 의존성을 해결하지 않고 설정자 메서드나 생성자 인수를 제공해 의존성을 주입할 수 있음 확장 처음부터 올바르게 시스템을 만들 수는 없다. -> 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현하되, 계속해서 시스템을 조정하고 확장해야 함 => 반복적이고 점진적인 애자일 방식의 핵심. 테스트 주도 개발, 리팩터링은 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만듦 시스템 아키텍처는 관심사를 적절히 분리해 관리하면 점진적인 발전이 가능 ..

변경으로부터 격리 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. => 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리할 수 있음 시스템 시스템 수준과 같은 높은 추상화 수준에서 깨끗함을 유지하는 방법을 살펴보자. 시스템 제작과 시스템 사용을 분리하라 시스템을 제작하는 단계(시작 단계)와 사용하는 단계를 분리하여 코드를 설계하는 것이 좋다. 만일 생성 로직과 실행 로직이 뒤섞여 있으면(ex: 초기화 지연 기법), 실행 메서드에서 생성자 인수에 의존하게 되고, 테스트 시에도 적절한 테스트 전용 객체와 실행 경로 등을 신경써야 하는 복잡성이 생긴다. 또한 실행 로직과 뒤섞인 생성 로직에서 생성하는 객체는 모든 문맥에 적합하기 어렵다. 설정 논리는 일반 실행 논리와 분리해..

변경하기 쉬운 클래스 변경을 하고 싶을 때 이미 존재하는 클래스 코드에 손대어야만 수정할 수 있는 코드는 바람직하지 않다. => 클래스에 손대면 다른 코드를 망가뜨릴 잠정적인 위험이 존재함. 위의 경우, 클래스를 분리하면 기존 클래스를 변경하지 않고도 기능을 추가할 수 있도록 리팩토링할 수 있다. => SRP(단일 책임 원칙), OCP(확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙)의 관점에서 바람직함. 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.

클래스 깨끗한 클래스가 깨끗한 코드를 만든다. 클래스 체계 표준 자바 관례에 따르면, 정적 공개 상수 정적 비공개 변수 비공개 인스턴스 변수 공개 함수 비공개 함수(자신을 호출하는 공개 함수 직후에 등장) 순으로 정의되며 클래스를 구성한다. => 추상화 단계가 순차적으로 내려가 신문 기사처럼 읽힌다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫다. 클래스는 작아야 한다! 클래스는 작게 만드는 것이 기본 규칙 -> 하나의 클래스는 하나의 책임만 맡아야 한다. 클래스 이름은 해당 클래스 책임을 기술해야 한다. (클래스 이름이 모호하다면 클래스 책임이 너무 많아서일 확률 높음. Processor, Manager, Super 등과 같은 단어들) 클래스 설명은 만일(if), 그리고(and), 또한..