rkaehdaos in the purpleland

[Clean Code] 다 읽었다~

Sat, 19 Feb 2022 02:31:22 GMT

클린 코드 회고

책 하나를 이렇게 깊게 파고든 것은 토비의 스프링 이후 거의 10년만에 처음이지 않나 싶습니다.

사실 공부하다 궁금한 점이 있으면 검색을 해가며
다른 블로거 몇몇의 클린코드 정리 한 포스팅을 보았는데
전부 책내용을 복사 붙이기가 태반이라 전혀 궁금증이 해소되지 않았습니다.

그래서 검색하다가 그냥 지쳐서.. 그냥 전부 해보기로 했습니다
그냥 책만 보고 쭉 넘어가는게 아니라 깃헙 저장소 만들고
책에 나온 예제는 진짜 100% 전부 실행해 보느라 진행이 굉장히 오래 걸렸습니다.

사실 대다수의 코드는 전부 깃헙 저장소에 넣어놨으며
잊어먹을때쯤 한번씩 공부하는 것도 나쁘진 않을 것 같습니다

왜 많은 사람들이 추천했는지 알 것 같습니다

필독서, 명서 이런 타이틀이 붙은 책들은 약간 고전이란 생각이 먼저 들어서
크게 도움이 될까 하는 생각이 들었지만 역시 명불허전..

요새 나오는 책들은 좋은 책들이 많아서
이런 필독서나 명서들의 필수 에센셜한 내용들이 추가가 되어 있어서
사실 보는 내용들은 처음 보는 내용들은 아니었지만

흘러가는 게 아니라 클린 코드라는 컨셉 내에서 여러 내용을 다루다보니
머리 속에서도 그동안 알았던 내용들이 클린 코드의 컨셉으로 정리가 되면서
훨씬 직관적으로 정리가 되었습니다.

이 책을 읽으면서 느낀점은
이책이야 말로 같은 책을 읽어도 얻어가는 것은 사람마다 다를 거라는 생각이 들었습니다

후임 주니어와 같이 일정을 잡고 책을 보고 챕터를 볼때마다
리뷰를 했는데 전혀 이해를 못하더라고요. 그냥 다 알고 있는 내용이라고
대충 넘어가던데. 다 아는데 왜 읽기 전과 후가 코드 상태가 그대로인지 ㅠ

역시 이번에도 책에서 오류 발견.
개인적으로는 대충 flow로 흐르지 않고 찬찬히 읽는 버릇이 있다보니
오타나 오류를 잘 발견하곤 합니다.
엄청나게 많이 읽힌 책이고 벌써 3판인데도 오류가 있더라고요
정오표에도 없는 오류라서 인사이트에 신고하니
다음쇄에 반영하겠다며 감사하다고 답메일이 왔습니다
뿌듯합니다.

[Clean Code] XVII. 냄새와 휴리스틱

Wed, 09 Feb 2022 01:57:47 GMT

XVII. 냄새와 휴리스틱

냄새

마틴파울러가 말한 나쁜 코드의 조짐
리팩토링 책에서는 켄트백이 당시 애기 키우면서 기저귀 냄새때문에 그렇게 표현했다고 읽은것 같음

전체 리스트

주석 - Comment

C1(부적절한 정보)

주석은 코드,설계에 기술적인 설명만 부연
변경이력, 기록등은 주석말고 형상관리에 적어라.

C2(쓸모 없는 주석)

오래된 주석, 엉뚱한 주석, 잘못된 주석
최대한 빨리 삭제 하자

C3(중복된 주석)

코드 설명 충분한데 구구절절 설명하는 주석
중복된 주석 예시
1
i++; //i 증가
서명만 있는 Javadoc도 마찬가지

C4(성의없는 주석)

작성할 가치가 있는 주석은 잘 작성할 가치가 있도록 정성껏 신중하게 선택한 단어로 작성
주절대지 않고 당연한소리 반복없이 간결, 명료하게 올바른 문법으로 작성하도록 한다

C5(주석 처리된 코드)

얼마나 오래된 코드인지, 중요한 코드인지 알 수가 없음
또한 삭제도 함부로 할 수 없게 됨(다른 사람 히스토리를 모르므로)
낡아간다.나중에 다른 코드들이 변경 된후에 주석을 풀면 에러덩어리
필요하면 이전 버전을 가져오면 되므로 즉각 삭제하라!

환경 - Environment

E1(여러 단계로 빌드)

빌드는 간단히 한단계의 명령어로 전체를 체크하웃해서 빌드 할 수 있도록

E2(여러 단계로 테스트)

모든 단위 테스트는 한 명령으로 돌려야 한다.
IDE의 버튼 하나, 쉘의 명령 하나 등

함수 - Function

F1(너무 많은 인수)

함수에서 인수개수는 작을수록 좋다 . 없으면 더 좋다
넷 이상은 가치가 의심스러우므로 최대한 회피

F2(출력인수)

일반적으로 읽는 이는 인수를 입력으로 간주한다.
따라서 출력인수는 일반적인 직관을 정면 위배
상태 변경이 필요하다면 출력 인수 사용 대신 함수가 속한 객체의 상태를 변경하라

F3(플래그 인수)

Flag Boolean은 함수가 여러 기능을 수행하는 명백한 증거
다른 함수로 쪼개고 네이밍 제대로

F4(죽은 함수)

아무도 호출하지 않는 함수
낭비. 삭제!

일반 - General

G1(한 소스파일에 여러 언어)

어떤 jsp : HTML, JAVA, tag Library, English comment, Javadoc, XML, JavaScript
이상적으로는 파일 하나에 언어 하나!
현실적으로 불가피하지만 최대한 줄이도록 노력 필요!

G2(당연한 동작을 구현하지 않는다)

최소 놀람의 원칙(The Principle of Least Surprise)
당연하게 여길만한 동작과 기능이 올바르게 제공되어야 한다.
그러지 않으면 신뢰할 수 없게 되고 직관적으로 예상할 수 없음

G3(올바로 처리되지 않은 경계)

코드는 올바로 작동 해야 →올바른 동작은 아주 복잡하다
모든 경계조건을 테스트하는 테스트 케이스를 작성하라

G4(안전절차 무시)

UUID 직접 제어, 컴파일러 경고 끄기, 실패 테스트 나중에 미루는 태도 등
위험하다

G5 중복

이 책의 가장 중요한 규칙중 하나
다른 이들의 언급
- DRY - 데이비드 토머스와 앤디 헌트 - 실용주의 프로그래머
  - Don’t Repeat Yourself(반복하지 마라)
  - 계방 폐쇄 원칙은 DRY 원칙이 적용되어야만 적용되는 원칙
  - 단일 책임 원칙도 DRY에 의존한다
- ONCE, AND ONLY ONCE
  - 매 행동 각기 모두 한번만, 딱 한번만 소스에 나타나야 한다
  - 검색에 따라선 DRY 원칙의 subset이라고 표현된 곳도 있다.
  - KENT BACK : XP 핵심 규칙중 하나다!
  - 론 제프리스(XP 창시자중 하나, 최근 The Nature of Software Development을 쓴) : “모든 테스트를 통과한다”는 규칙 다음으로 중요하다
중복을 발견할 떄마다 추사화할 기회로 간주!
- 추상화로 중복 정리 → 설계 언어 어휘 증가 → 다른이들도 어휘 사용이 쉬워짐 → 높은 추상화 → 구현이 빨라지고 오류가 적어짐
패턴
- 뻔한 패턴 : 똑같은 코드(copy&paste처럼) → 간단한 함수로 교체
- 미묘한 패턴 : 여러 모듈에서 switch,if/else로 같은 조건 거듭 확인하는 중복 → 다형성으로 대체
- 더더욱 미묘한 패턴 : 유사 알고리즘인데 코드가 다른 중복 → 중복은 중복 →템플릿 메서드 패턴, 전략 패턴 사용으로 중복 제거
최근 15년의 디자인 패턴 대다수는 중복을 잘 제거하는 방법에 불과
- BCNF: DB 스키마에서 중복 제거 전략
- ∞ : 역시 모듈 정리, 중복 제거 전략
- 구조적 프로그래밍도 마찬가지
결론 : 무조건 중복을 발견하면 없애라!

G6(올바르지 못한 추상화 수준)

추상화 : 저차원 상세 개념에서 고차원 일반 개념을 분리한다
추상화 수행 : (고차원 일반 개념 표현의)추상 클래스와 (저차원 상세 개념)을 표현하는 파생 클래스 생성
추상화 분리는 철저히 : 모든 저차원 개념은 파생 클래스, 모든 고차원 개념은 추상 클래스
- ex) 세부구현 관련 상수, 변수, 유틸리티 : 추상은 구현 정보에 무지해야 하므로 파생에 넣어야 한다
소스파일, 컴포넌트 모듈도 마찬가지
- 좋은 SA : 개념을 다양한 차원으로 분리 → 다른 컨테이너에 넣는다
- 떄로는 기초 클래스 + 파생 클래스 분리, 때로는 소스파일, 모듈, 컴포넌트로 분리
잘못된 추상화는 꼼수나 임시로 해결이 불가 : 가장 개발자에게 어려운 작업 중 하나가 추상화

G7(기초 클래스가 파생 클래스에 의존)

앞 G6에서 봤던 부분 다시 생각해보자.
개념을 기초+파생으로 나누는 이유
- 고차원 기초 클래스 개념을 파생 클래스 개념으로부터 분리
- 독립성을 보장하기 위해서
따라서 기초가 파생에 의존하면 문제가 있음
예외
- 파생 클래스 개수가 확실히 고정되어있다면 기초 클래스에서 파생 클래스를 선택하는 코드가 들어간다
- 책의 FSM 구현 : 기초 클래스+파생 클래스 굉장히 밀접하며 언제나 같은 JAR 파일로 배포
- 일반적으로는 기초와 파생클래스를 다른 JAR로 배포하는 것이 좋다
  - 이렇게 배포시 (기초에서 파생 JAR를 전혀 모른다면) 독립적인 개별 컴포넌트 단위로 시스템 배치가 가능
  - 컴포넌트 변경시 해당 컴포넌트만 다시 배치 가능
  - 변경 영향이 작아서 현장에서 시스템 유지보수가 수월함

G8(과도한 정보)

높은 응집도, 낮은 결합도
- 잘 정의된 모듈은 인터페이스가 아주 작고 함수가 적으며 많은 동작이 가능
- 부실한 모듈은 간단한 동작에 온갖 인터페이스와 꼭 호출해야하는 온갖 함수 → 높은 결합도 유발
잘하는 개발
- 클래스/모듈 인터페이스에 노출할 함수 제한
- 클래스가 제공 메서드 수는 작을 수록
- 함수가 아닌 변수 수도 작을수록
- 클래스의 인스턴스 변수 수도 작을수록 좋다.
이렇게 하여라
- 숨겨라: data, 유틸리티 함수, 상수, 임시 변수
- 피하라 : 메서드나 인스턴스 변수가 넘쳐나는 클래스는 피하라
- 마구 만들지 마라 : 하위에서 필요하다고 protected 변수 함수를 마구 생성하지 말아라
- 인터페이스를 매우 작게! 깐깐하게 만들고! 정보를 제한해서 결합도를 낮춰라

G9(죽은 코드)

죽은 코드 : 실행되지 않는 코드
죽은 코드의 예
- 불가능한 조건을 확인하는 if문
- throw문이 없는 try문의 catch 블럭
- 아무도 호출하지 않는 유틸리티 함수
- switch/case에서 불가능한 case 조건
죽은 코드를 제거하라
- 시간이 지날수록 악취가 심해진다(설계가 변해도 제대로 수정이 안되므로)

G10(수직 분리된 경우)

변수 함수는 사용되는 위치에 최대한 수직으로 분리되지 않고 가깝게 정의

지역변수: 처음으로 사용하기 직전에 선언, 수직으로 가까운 곳에 위치
비공개 함수 : 처음으로 호출한 직후 정의(클래스 scope여도 그래도 호출 부위와 가깝도록 유지)

G11(일관성 부족)

어떤 개념을 특정 방식으로 구현했다면 유사한 개념도 같은 방식으로 구현한다.
최소놀람의 원칙에도 부합
신중하게 선택한 표기법을 신중하게 따른다
예를들어 response변수에 HttpServletResponse 인스턴스를 저장했으면
HttpServletResponse를 사용하는 다른 함수에서도 일관성 있도록 동일한 변수 사용
착실히 적용하면 이리 간단한 일관성 만으로 코드가 읽고 수정이 쉬워진다.

G12(잡동사니)

비어있는 기본 생성자
아무도 사용하지 않는 변수
아무도 호출하지 않는 함수
정보를 제공하지 못하는 주석

G13(인위적 결합)

서로 무관한 개념을 인위적으로 결합하지 않는다.
예) 일반적 enum은 특정 클래스에 속할 이유가 없다
- enum이 A클래스에 속한다면? enum을 사용하는 B 클래스가 A클래스를 알아야 한다
- 범용 static함수도 마찬가지로 특정 클래스에 속할 이유가 없다
인위적 결합 : 직접 상호작용이 없는 두 모듈 사이에서 일어난다
- 뚜렷한 목적없이 변수/상수/함수를 당장 편한 위치에 넣어버린 결과
변수/상수/함수를 선언할때는 시간을 들여 올바른 위치를 고민한다

G14(기능 욕심)

마틴 파울러가 말하는 코드 냄새중 하나
클래스 메서드는 자기 클래스의 변수와 함수에 관심을 가져야지 다른 클래스의 변수와 함수에 가져서는 안된다.
메서드가 다른 객체의 메서드를 이용해 객체 내용 조작? 메서드가 그 객체 클래스의 범위를 욕심 내는 탓
자신이 그 클래스에 속해 그 클래스의 변수를 직접 조작 원한다는 뜻
기능 욕심은 한 클래스의 속사정을 다른 클래스에 노출하므로 별다른 문제가 없으면 제거가 좋다

어쩔 수 없는 경우 예시

public class HoulyEmployeeReport{
  private HourlyEmployee employee;
  public HoulyEmployeeReport(HourlyEmployee employee){
    this.employee=employee;
  }
  String reportHours(){
    return String.format(
      "NAME: %s\tHours:%d.%1d\n",
      employee.getName(),
      employee.getTenthsWorked()/10,
      employee.getTenthsWorked()%10
    );
  }
}

HoulyEmployeeReport클래스의 reportHours()메서드는 HourlyEmployee클래스를 욕심낸다
그렇다고 HourlyEmployee클래스가 보고서 형식을 알 필요는 없다.
만약 예외를 두지 않고 함수를 HourlyEmployee로 옮기면 여러 원칙 위반(특히 SRP, OCP, CCP위반)
- HourlyEmployee가 보고서 형식과 결합 → 보고서 형식이 바뀌면 클래스가 바뀌게 되어버림

G15(선택자 인수)

인수에 따라 다른 동작 - F3(flag 인수)과도 유사한 부분이 있음
selector 인수 : 목적 기억도 어렵, 각 선택자 인수가 여러 함수를 하나로 조합
큰 함수를 쪼개지 않으려는 게으름 소산
함수 동작을 제어하려는 인수는 바람직하지 않다. 새로운 함수를 만들자.

G16(모호한 의도)

행을 바꾸지 않고 표현한 수식, 헝가리식 표기법, 매직 넘버 : 작성자 의도를 흐린게한다
의도를 최대한 분명히 밝힌다(시간을 투자해서라도)

G17(잘못 지운 책임)

개발자가 내리는 가장 중요한 결정 : 코드 배치 위치
예) PI 상수는? 삼각함수를 선언한 클래스에 선언된다 → 독자가 자연스럽게 기대할 위치
여기서도 최소 놀람의 원칙이 적용되는 것을 알 수 있다.
다른 예시
직원이 근무한 총 시간을 보고서로 출력하는 함수의 위치는 둘중 어디가 맞을까?
1. 보고서를 출력하는 함수에서 총계를 계산
2. 근무 시간을 입력받는 코드에서 총계를 계산
결정을 내리는 방법
1. 이 함수이름을 살펴본다 : 예로 getTotalHours()
2. 이름만 보았을때 어디에서 총계를 계산하는게 나은가?
답은 1번일 것

성능 때문에 2번답이 좋다고 판단된다면?

이런 사실을 반영해서 네이밍 제대로 해야함
위의 경우에는 2번의 모듈에 computeRunningTotalOfHours()의 이름

G18(부적절한 Static 함수)

좋은 static 예 : Math.max(double a, double b)

특정 인스턴스 관련 기능이 아니다
max 메서드가 사용하는 정보는 2개의 인자가 전부.
메서드 소유한 객체에서 가져오는 정보가 거의 없음
(결정적) override할 가능성이 전혀 없음

static으로 정의하면 안되는 함수

1	HourlyPayCalculator.calculatePay(employee, overtimeRate);

함수를 재정의할 가능성 존재 : 수당 계산 알고리즘이 여러개 일 수도
따라서 static으로 하면 안되고 Employee클래스에 속하는 인스턴스 함수여야 한다
일반적으로 static함수보다 인스턴스 함수가 더 좋다. 조금만 의심스럽다면 인스턴스 함수로 정의
재정의 가능성을 꼭 곰곰히 따져보고 static 정의 고려할 것

G19(서술적 변수)

kent beck이 다음의 훌륭한 책에서 지적
- Smalltalk Best Practice Patterns, 1996
- Implementation Patterns(켄트백의 구현 패턴), 2007

프로그램 가독성을 가장 높이는 효과적인 방법 : 계산을 여러 단계로 나누고 중간값으로 서술적 변수 이름 사용

FitNesse 예시

Matcher match = headerPattern.matcher(line);
if(match.find()){
  String key = match.group(1);
  String value = match.group(2);
  headers.put(key.toLowerCase(), value);
}

서술적 이름 사용 때문에 첫번째 그룹이 key, 2번째 그룹이 value라는 사실이 들어난다
서술적이름은 많이 써도 괜찮다. 일반적으로는 많을 수록 더 좋다
계산을 몇 단계로 나누고 중간값에 좋은 변수 이름만 부텽도 해독하기 어렵던 모듈이
순식간에 읽기 좋은 모듈로 바뀐다

G20(이름과 기능이 일치하는 함수)

date.add(5); → 5일? 5주? 5시간? date인스턴스 변경인가, 아니면 새로운 Date를 리턴하는 함수인가?
코드를 봐서 알 수가 없음
기존 인스턴스 변경 : addDaysTo, increaseByDays 등의 이름이 좋다
새로운 객체 반환 : daysLater, daysSince등의 이름이 좋다
이름으로 분명치 않다면? 좋은 이름으로 바꾸거나, 좋은 이름을 붙이기 쉽게 기능을 정리하거나

G21(알고리즘을 이해하라)

알고리즘의 충분한 이해없이 여기저기 if와 flag를 삽입하며 돌려서 결과를 만드는데 성공한 코드들
테스트를 모두 통과한다는 것만으로 부족 → 알고리즘이 올바르다는 사실을 알아야 한다
알고리즘의 올바름을 확인/이해하려면? 기능이 뻔히 보일정도로 깔끔하고 명확하게 함수를 재구성 하는 것이 최고의 방법

G22(논리적 의존성은 물리적으로 드러내라)

모듈이 다른 모듈에 의존한다면 논리적 의존성으로는 부족하며 물리적인 의존성도 있어야 한다
책의 예시
HourlyReporter 클래스의 generateReport()는 PAGE_SIZE라는 상수를 이용해 돌아간다
논리적 의존성 : 55의 값으로 선언된 PAGE_SIZE라는 상수 →
페이지 크기는 HourlyReporter가 아닌 HourlyReportFormatter가 책임질 정보
앞서 설명한 [G17]에 해당한 실수
논리적 의존성 : HourlyReporter클래스는 HourlyReportFormatter가 55 페이지 크기를 처리할 줄 안다는 사실에 의존 → 이 페이지 크기를 알거라고 가정한 자체가 논리적 의존성
가정이 틀리면 오류가 되어버림
해결책 : 논리적 의존성을 물리적 의존성으로
- HourlyReportFormatter에 getMaxPageSize()메서드를 추가
- HourlyReporter클래스는 PAGE_SIZE 상수 대신 getMaxPageSize()호출

G23 if/else, Switch/Case 대신 다형성 사용

3장에서 밥 아저씨 : “새 유형보다 새 함수를 추가할 확율이 높은 코드는 switch가 더 적합하다”
1. 대다수 개발자 swit문 선택 이유 : 올바른 선택이 아니라 손쉬운 선택이기 때문
  그러므로 Switch 선택 전에 다형성 먼저 고려하라는 의
2. 유형보다 함수가 더 쉽게 변하는 경우는 극히 드물다 → 그러므로 모든 switch문을 의심하라
밥아저씨가 따르는 ‘one switch” 규칙
- 선택 유형 하나에는 switch문을 한 번만 사용
- 같은 선택을 수행하는 다른 코드에는 다형성 객체를 생성해 switch문을 대신한다

G24(표준 표기법)

팀은 업계 표준에 기반한 구현 표준을 따라야 한다
팀이 정한 표준은 팀원들 모두가 따라야 한다
밥아저씨가 따르는 표기법 : p512 목록 B-7 ~ B-14

G25(매직 숫자는 명명된 상수로 교체)

SW개발 에서 가장 오래된 규칙 : 일반적으로 코드에서 숫자를 사용하지 말라는 규칙
상수가 너무 미해가 쉽고 자명하다면 숨길 필요는 없음: 하루는 24시간, 1분은 60초 등
원주율: 자명하지만 숫자가 길고 근사값 사용시 오류 발생 : 다행히 Math.PI를 사용하면 된다
매직숫자는 단순히 숫자만 의미하느넥 아니라 의미가 분명하지 않은 토큰 모두를 말한다

G26(정확하라)

정확하지 않은 행동

검색결과 중 첫 번째 결과만 유일한 결과로 간주 → 순진
부동 소수점으로 통화 표현 → 범죄
갱신할 가능성이 희박하다고 잠금/트랜잭션 관리를 건더뛰는 것 → 게으름
List로 선언할 변수를 ArrayList로 선언 → 지나친 제약
모든 변수를 protected로 선언 → 무절제
코드에서 무언가를 결정할때는 정확하게 결정한다
- 결정을 내리는 이유와 예외를 처리할 방법을 분명히 알아야 한다. 대충하면 안된다.
- 호출하는 함수가 null 반환할지 모른다 → 반드시 null 점검
- 검색 결과가 하나뿐이라고 짐작 → 하나인지 확실히 확인
- 통화를 다룬다면 정수를 사용하고 반올림을 올바로 처리한다(아니면 Money클래스 사용)
- concurrent 특성으로 동시 갱신 가능성 존재? → 적절한 잠금 매커니즘

G27(관례보다 구조 사용)

설계 결정 강제시 규칙보다 관례를 사용
예시
Enum변수가 멋진 Switch/case <<<< 추상 메서드가 있는 기초 클래스
Switch/case를 매번 똑같이 구현하게 강제하기는 어렵다
파생 클래스는 추상 메서드를 모두 구현하지 않으면 안되므로

G28(조건을 캡슐화)

부울논리는 (if,while에 넣어 생각하지 않아도) 이해가 오래걸림
조건의 의도를 분명히 밝히는 함수
예를 들어 if(timer.hasExpired() && !timer.isRecurrent())보다는
if (shouldBeDeleted(timer))라는 코드가 좋다

G29(부정조건은 피하라)

부정 조건은 긍정보다 이해를 어렵게 하므로 가능한 긍정 조건으로 표현

G30(함수는 한 가지만)

함수는 단일 입무만.

//밑의 함수는 한 가지만 수행하는 함수가 아니다.
public void pay() {
  for (Employee e : employees) {
    if (e.isPayday()){
      Money pay = e. calculatePay();
      e.deliverPay(pay);
    }
  }
}

여러 단락을 하는 함수는 작은 함수 여럿으로 나눠야 마땅하다

이제 각 함수는 한가지 임무만 수행

public void pay() {
  for (Employee e : employees) {
    payIfNecessary(e);
  }
}

private void payIfNecessary(Employee e) {
  if (e.isPayday())
    calculateAndDeliveryPay(e);
}

private calculateAndDeliveryPay(Employee e) {
  Money pay = e. calculatePay();
  e.deliverPay(pay);
}

G31(숨겨진 시간적 결합)

때론 시간적 결합이 필요하지만 이를 숨겨서는 안된다

함수를 짤 때는 함수 인수를 적절히 배치해 함수 호출 순서를 명백히 드러내야 한다

시간적 결합이 필요한 함수

public class MoogDiver {
  Gradient gradient;
  List splines;

  public void dive(String reason) {
    //밑의 3가지 함수는 실행되는 순서가 중요하다. 하지만 시간적 결합을 강제하지 않는다.
    saturateGradient();
    reticulateSplines();
    diveForMoog(reason);
  }
}

더 좋은 코드

public class MoogDiver {
  Gradient gradient;
  List splines;

  public void dive(String reason) {
    Gradient gradient = saturateGradient();
    List splines = reticulateSplines(gradient);
    diveForMoog(splines, reason);
  }
}

설명

강제로 인자를 연결 소자로 만들어 시간적 결합을 노출

각 함수의 결과는 다음 함수에 필요하므로 순서를 바꿔서 호출할 수가 없다

함수가 복잡해졌다

의도적으로 추가한 구문적인 복잡성이 원래 있던 시간의 복잡성을 드러낸 것이다.

인스턴스 변수를 그대로 두었다는 사실에 주목

해당 클래스의 private메서드에 필요한 변수일지 모른다
그렇다 하더라도 제자리를 찾은 변수들이 시간적 결합을 좀 더 명백히 드러나게 해줄 것이다

G32(일관성을 유지하라)

코드 구조를 잡을 떄는 이유를 고민하고 이유를 코드 구조를 명백히 표현하라
일관성 없는 구조 → 남들이 마음대로 바꿔도 괜찮다고 생각한다.
시스템 전반에 걸쳐 일관성 있는 구조 → 남들도 따르고 보존

G33(경계 조건을 캡슐화)

경계 조건은 빼먹거나 놓치기 쉬우므로 여기저기에서 처리하지 않고 한 곳에서 별도로 처리한다

+1, -1을 흩어 놓지 말자

FIT에서 가져온 예제

if(level + 1 < tags.length>) {
  parts = new Parse(body, tags, level + 1, offset + endTag);
  body = null;
}

level + 1이 2번 나온다. 이런 경계 조건은 변수로 처리하자

경계조건 캡슐화

int nextLevel = level + 1;
if(nextLevel < tags.length>) {
  parts = new Parse(body, tags, nextLevel, offset + endTag);
  body = null;
}

G34(함수는 추상화 수준을 한 단계만 내려가야 한다)

함수 내 추상화 수준은 함수 이름이 의미하는 작업보다 한 단계만 낮아야 한다
함수 내 모든 문장은 추상화 수준이 동일해야 한다
이번 장에서 가장 이해하기 어렵고 따르기도 어려운 항목

개념은 간단하지만 인간은 추상화 수준을 뒤섞는 능력이 너무 뛰어나다

FitNess의 모듈 HruleWidget에서 가져온 Code

public String render() throws Exception {
  StringBuffer html = StringBuffer(");
  if (size > 0)
    html.append(" size=\"").append(size+1).append("\"");
  html.append(">");
  return html.toString();
}

내용

페이지를 가로지르는 수평자 html 태그 생성, 높이는 size변수로 지정하고 있다.
----처럼 4개 이상의 연이은 대시를 감지해 태그로 변환하는 코드임
추상화 수준이 최소한 2개가 섞여 있다.
1. 수평선에 크기가 있다는 개념
2. HR 태그 자체의 문법

수정 내용은 밑과 같다 → size 변수 네이밍 적용

public String render() throws Exception {
  HtmlTag hr = new HtmlTag("hr");
  if (extraDashes > 0)
    hr.addAttribute("size", hrSize(extraDashes));
  return hr.html();
}

private String hrSize(int height) {
  int hrSize= height + 1;
  return String.format("%d", hrSize);
}

render 함수는 HR 태그만 생성한다. 태그 문법은 상관하지 않음
html 문법은 HtmlTag 모듈이 알아서 처리
HtmlTag 모듈은 xhtml 표준을 준수해서 출력 - 미묘한 버그 캐치
추상화 수준 분리는 리팩터링 수행의 가장 중요한 이유중 하나이며 제대로 하기 가장 어려운 작업

G35(설정 정보는 최상위 단계)

추상화 최상위에 있어야할 기본값 상수, 설정 관련 상수를 저차원 함수에 숨겨선 안된다.
대신 고차원 함수에서 저차원 함수를 호출할 때 인수로 넘긴다.

G36(추이적 탐색을 피하라)

디미터의 법칙 :모듈은 주변 모듈을 모를 수록 좋다. 자신이 직접 사용하는 모듈만 알아야 한다

A→B→C 여도 A가 C를 알 필요는 없다
따라서 a.getB().getC().doSomething();은 바람직하지 않다.
- 여러 모듈에서 위와 같은 코드의 형태를 사용한다면?
- 설계와 아키텍처를 바꿔서 B와 C사이에 Q를 넣기 쉽지 않다
- a.getB().getC()를 전부 찾아 a.getB().getQ().getC()로 바꿔야 하기 때문
- 너무 많은 모듈이 아키텍처를 너무 많이 알게 됨 → 아키텍처가 굳어진다
디미터의 법칙은 결합도와 관련된 것이며, 객체의 내부 구조가 외부로 노출되는것에 대한 것이다
따라서 아래는 예외
- Stream API등의 여러 도트는 해당사항이 없다(동일한 스트림 변환이고 캡슐화 그대로 유지)
- DTO, 컬렉션 객체등 자료 구조 : 당연히 내부를 노출해야 함
결론 : 내가 사용하는 모듈이 내게 필요한 모든 서비스를 제공해야 하며, 객체 그래프로 탐색할 필요가 없어야 한다

자바 - JAVA

J1(긴 import 대신 wild 카드 사용)

의존성 문제

명시적으로 클래스를 import하면 그 클래스가 반드시 존재해야 한다
와일드 카드로 패키지 지정시 특정 클래스 존재 필요 없음
import는 단순히 검색 경로에 추가하므로 진정한 의존성이 생기지 않음 → 모듈간의 결합성이 낮아진다.

와일드 카드 사용 단점 : 때때로 이름 충돌, 모호성 초래

이름이 같거나, 패키지가 다른 클래스는 명시적 import 사용하자
번거롭지만 자주 발생하지 않음 - 여전히 와일드카드 import >>명시적 import

J2(상수는 상속하지 않는다)

하위에서 발견하면 계속 위로 거슬려서 찾아봐야한다. → 언어의 범우 규칙을 속이는 행위
대신 static import를 사용하라

상수 대 Enum

public static final int말고 ENUM을 사용하라!
enum은 메서드와 필드도 사용할 수 있는 강력한 도구다!

이름 - Name

N1(서술적인 이름 사용)

이름은 성급하지 않고 신중하게!
SW 가독성의 90%는 이름이 결정 → 시간을 들여 현명한 이름을 선택하고 적합성 유지

N2(적절한 추상화 수준에서 이름 선택)

구현을 드러내는 이름은 피하고 해당 클래스/함수가 위치하는 추상화 수준을 반영하는 이름을 선택하라

쉽지 않겠지만 안정적인 코드를 만들려면 지속적인 개선/노력이 필요하다
예시

추상화 수준을 살펴보자

public interface Modem {
  boolean dial(String phoneNumber);
  boolean disconnect();
  boolean send(char c);
  char recv();
  String getConnectedPhoneNumber();
}

얼핏 보면? 적절해 보이며, 대다수 애플리케이션엔 문제가 없음
현대의 모뎀은 전용선, 케이블, USB등을 사용하기도 → 전화번호 개념은 추상화 수준이 틀렸다
더 좋은 이름 전략
1
2
3
public interface Modem {
boolean connect(String connectionLocator);
}

N3(가능하다면 표준 명명법)

기존 명명법 사용 이름은 이해가 쉽다

Decorator 패턴 활용한다면 장식 클래스 이름에 Decorator라는 단어를 사용해야 한다.
AutoHangupModemDecorator: 세션 끝 무렵 자동으로 연결을 끊는 기능으로 Modem을 장식하는 클래스 이름에 적합
자바에서 객체를 문자열로 변환하는 함쉬: toString() 많이 씀, 가급적 관례를 따르는 편이 좋다.
팀이 특정 프로젝트에 적용할 표준 - 유비쿼터스 언어(라고 에릭 에반스는 부른다)
- 코드에는 이 언어에 속하는 용어를 열심히 사용하자
- 프로젝트에 유효한 의미가 담긴 이름을 많이 사용할 수록 독자가 코드 이해가 쉽다

N4(명확한 이름)

함수나 변수의 목적을 명확히 밝히는 이름을 선택한다

역시 FitNess 코드

private String doRename() throws Exception {
  if (refactorReferences)
    renameReferences();
  renamePage();

  pathToRename.removeNameFromEnd();
  pathToRename.addNameToEnd(newName);
  return PathParser.render(pathToRename);
}

네이밍으로 함수의 목적 파악이 분명하지 않고 광범위, 모호

doRename()안에 renamePage()함수가 들어있는데.. 이름만으로 차이점을 전혀 알 수가 없다
좋은 이름 : renamePageAndOptionallyAllReferences
- 아주 길지만 모듈에서 한번만 호출된다
- 길다는 단점을 서술성이 충분히 메꿔준다

N5(긴 범위는 긴 이름을 사용하라)

이름 길이는 범위 길이에 비례해야 한다 : 범위가 작으면 짧은 이름, 범위가 길면 긴 이름

5줄 안팎이라면 i,j등의 변수 이름도 괜찮다

볼링 예시

private void rollMany(int n, int pins) {
  for (int i = 0; i < n ; i++)
    g.roll(pins);
}

깔끔, 오히려 i를 rollCount로 쓰면 더 햇갈릴 수 있다.
범위가 길수록 이름을 정확하고 길게 짓는다

N6(인코딩을 피하라)

헝가리안 표기법 절대 쓰지마라
현대 개발 환경에서는 m_, f등의 접두어 불필요
IDE의 발전으로 이름 조작없이 모든 정보 파악 가능

N7(이름으로 부수효과를 설명하라)

함수/변수/클래스가 하는 일을 모두 기술하는 이름을 사용

이름에 부수효과를 숨기지 않는다.여러 작업을 하면 해당 작업 모두를 반영하는 네이밍이 필요

TestNG의 코드

public ObjectOutputStream getOos() throws IOException {
  if (m_oos == null) {
      m_oos = new ObjectOutputStream(m_socket.getOutputStream());
  }
  return m_oos;
}

위 함수는 단순히 “oos”만 가져오지 않고, 기존에 “oos”가 없으면 생성한다.
그러므로 createOrReturnOos()라는 이름이 더 좋다

테스트 - Test

T1(불충분한 테스트)

깨질만한 부분을 모두 테스트해야 한다
테스트 케이스가 확인하지 않는 조건이나 검증하지 않는 계산이 있다면 불완전한 테스트

T2(커버리지 도구 사용)

테스트가 불충분한 모듈 찾기가 쉬어진다. 붉은 색상으로 드러나는 IDE가 그러함

T3(사소한 테스트를 건더 뛰지 마라)

사소한 테스트는 짜기 쉽다
사소한 테스트가 제공하는 문서적 가치 >>>>>>>>>> 구현에 드는 비용

T4(무시한 테스트는 모호함을 뜻함)

불분명한 요구사항은 테스트케이스를 @Ignore처리(컴파일 불가능한 상태라면 주석 처리)

T5(경계 조건 테스트하라)

경계조건은 각별히 신경써서 테스트
알고리즘 조건은 올바로 짜놓고 경계 조건에서 실수하는 경우가 흔하다

T6(버그 주변은 철저히 테스트)

버그는 서로 모이는 경향
버그를 발견했다면 그 함수를 철저히 테스트하라 →
십중 팔구 다른 버그도 발견한다

T7(실패 패턴을 살펴라)

때로는 테스트 케이스가 실패하는 패턴으로 문제 진단
테스트 케이스를 최대한 꼼꼼히 짜라는 이유도 여기에 있음
예) 입력이 5자를 넘기는 케이스가 모두 실패, 특정인자로 음수를 넘어가는 케이스가 모두 실패~
테스트 리포트 빨간색/녹색만 보고도 꺠달음이 온다

T8(테스트 커버리지 패턴을 살펴라)

통과하는 테스트가 실행하거나 실행하지 않는 코드를 살펴라
그러면 실패하는 테스트 케이스의 원인이 들어난다

T9(테스트는 빨라야 한다)

느린 테스트는 실행하지 않게 된다

결론

이 리스트가 완전한 것은 아니다. 가치 체계를 피력할 뿐
가치 체계 자체가 클린 코드 책의 주제이자 목표
특정 규칙만 따른다고, 리스트를 익힌다고 클린코드가 얻어지거나 소프트웨어 장인이 되지 않는다
전문가, 장인 정신은 가치에서 나오며 그 가치에 기반한 규율과 절제가 필요

[Clean Code] XVI. SerialDate 리팩터링

Wed, 09 Feb 2022 00:57:08 GMT

Clean Code 3판을 읽고 정리한 글입니다

XVI. SerialDate 리팩터링

SerialDate

JCommon 라이브러리의 org.jfree.date라는 패키지 이하
https://github.com/jfree/jcommon/blob/master/src/main/java/org/jfree/date/SerialDate.java
https://github.com/jfree/jcommon/pull/6
- 아예 대놓고 클린코드 내용대로 리팩토링후 풀리퀘를 보낸 내용

Fork 저장소 : https://github.com/rkaehdaos/jcommon
Fork 실제 작업 프로젝트 : https://github.com/rkaehdaos/jcommon/projects/2

첫째, 돌려보자

https://github.com/rkaehdaos/jcommon/issues/2
테스트가 이렇게 중요하다.

둘째, 고쳐보자

https://github.com/rkaehdaos/jcommon/issues/5
변경 이력 삭제
전략패턴+팩토리 메서드 패턴으로 다형성으로 커버 안되는 부분 처리부분

결론

테스트 내용에서 일단 충격
개인적으로는 되는 부분은 하나만 테스트하고 경계만 테스트했었는데..
반성 반성

[Clean Code] XV. JUnit 들여다보기

Wed, 09 Feb 2022 00:56:49 GMT

XV. JUnit 들여다보기

Junit

에릭감마, 켄트백이 3시간만에 Junit 기초 구현

JUnit 프레임워크

책에 있는 ComparisonCompactor.java 따라해보기
ComparisonCompactor : https://github.com/junit-team/junit4/blob/main/src/main/java/junit/framework/ComparisonCompactor.java
ComparisonCompactorTest : https://github.com/junit-team/junit4/blob/main/src/test/java/junit/tests/framework/ComparisonCompactorTest.java
직접해보기 : https://github.com/rkaehdaos/cleancode-ch15-Junit

ComparisonCompactor.java

package me.rkaehdaos;

import junit.framework.Assert;

public class ComparisonCompactor {

    private static final String ELLIPSIS = "...";
    private static final String DELTA_END = "]";
    private static final String DELTA_START = "[";

    private int fContextLength;
    private String fExpected;
    private String fActual;
    private int fPrefix;
    private int fSuffix;

    public ComparisonCompactor(int contextLength, String expected, String actual) {
        fContextLength = contextLength;
        fExpected = expected;
        fActual = actual;
    }

    @SuppressWarnings("deprecation")
    public String compact(String message) {
        if (fExpected == null || fActual == null || areStringsEqual()) {
            return Assert.format(message, fExpected, fActual);
        }

        findCommonPrefix();
        findCommonSuffix();
        String expected = compactString(fExpected);
        String actual = compactString(fActual);
        return Assert.format(message, expected, actual);
    }

    private String compactString(String source) {
        String result = DELTA_START + source.substring(fPrefix, source.length() - fSuffix + 1) + DELTA_END;
        if (fPrefix > 0) {
            result = computeCommonPrefix() + result;
        }
        if (fSuffix > 0) {
            result = result + computeCommonSuffix();
        }
        return result;
    }

    private void findCommonPrefix() {
        fPrefix = 0;
        int end = Math.min(fExpected.length(), fActual.length());
        for (; fPrefix < end; fPrefix++) {
            if (fExpected.charAt(fPrefix) != fActual.charAt(fPrefix)) {
                break;
            }
        }
    }

    private void findCommonSuffix() {
        int expectedSuffix = fExpected.length() - 1;
        int actualSuffix = fActual.length() - 1;
        for (; actualSuffix >= fPrefix && expectedSuffix >= fPrefix; actualSuffix--, expectedSuffix--) {
            if (fExpected.charAt(expectedSuffix) != fActual.charAt(actualSuffix)) {
                break;
            }
        }
        fSuffix = fExpected.length() - expectedSuffix;
    }

    private String computeCommonPrefix() {
        return (fPrefix > fContextLength ? ELLIPSIS : "") + fExpected.substring(Math.max(0, fPrefix - fContextLength), fPrefix);
    }

    private String computeCommonSuffix() {
        int end = Math.min(fExpected.length() - fSuffix + 1 + fContextLength, fExpected.length());
        return fExpected.substring(fExpected.length() - fSuffix + 1, end) + (fExpected.length() - fSuffix + 1 < fExpected.length() - fContextLength ? ELLIPSIS : "");
    }

    private boolean areStringsEqual() {
        return fExpected.equals(fActual);
    }
}

ComparisonCompactorTest.java

package me.rkaehdaos;

import junit.framework.TestCase;

//import static org.junit.Assert.*;

public class ComparisonCompactorTest extends TestCase {

    public void testMessage() {
        String failure = new ComparisonCompactor(0, "b", "c").compact("a");
        //인텔리제이는 Equals로 단순화 추천.. 일단 원래 코드 남김
        //        assertEquals("a expected:<[b]> but was:<[c]>", failure);
        assertTrue("a expected:<[b]> but was:<[c]>".equals(failure));
    }

    public void testStartSame() {
        String failure = new ComparisonCompactor(1, "ba", "bc").compact(null);
        assertEquals("expected: but was:", failure);
    }

    public void testEndSame() {
        String failure = new ComparisonCompactor(1, "ab", "cb").compact(null);
        assertEquals("expected:<[a]b> but was:<[c]b>", failure);
    }

    public void testSame() {
        String failure = new ComparisonCompactor(1, "ab", "ab").compact(null);
        assertEquals("expected: but was:", failure);
    }

    public void testNoContextStartAndEndSame() {
        String failure = new ComparisonCompactor(0, "abc", "adc").compact(null);
        assertEquals("expected:<...[b]...> but was:<...[d]...>", failure);
    }

    public void testStartAndEndContext() {
        String failure = new ComparisonCompactor(1, "abc", "adc").compact(null);
        assertEquals("expected: but was:", failure);
    }

    public void testStartAndEndContextWithEllipses() {
        String failure = new ComparisonCompactor(1, "abcde", "abfde").compact(null);
        assertEquals("expected:<...b[c]d...> but was:<...b[f]d...>", failure);
    }

    public void testComparisonErrorStartSameComplete() {
        String failure = new ComparisonCompactor(2, "ab", "abc").compact(null);
        assertEquals("expected: but was:", failure);
    }

    public void testComparisonErrorEndSameComplete() {
        String failure = new ComparisonCompactor(0, "bc", "abc").compact(null);
        assertEquals("expected:<[]...> but was:<[a]...>", failure);
    }

    public void testComparisonErrorEndSameCompleteContext() {
        String failure = new ComparisonCompactor(2, "bc", "abc").compact(null);
        assertEquals("expected:<[]bc> but was:<[a]bc>", failure);
    }

    public void testComparisonErrorOverlappingMatches() {
        String failure = new ComparisonCompactor(0, "abc", "abbc").compact(null);
        assertEquals("expected:<...[]...> but was:<...[b]...>", failure);
    }

    public void testComparisonErrorOverlappingMatchesContext() {
        String failure = new ComparisonCompactor(2, "abc", "abbc").compact(null);
        assertEquals("expected: but was:", failure);
    }

    public void testComparisonErrorOverlappingMatches2() {
        String failure = new ComparisonCompactor(0, "abcdde", "abcde").compact(null);
        assertEquals("expected:<...[d]...> but was:<...[]...>", failure);
    }

    public void testComparisonErrorOverlappingMatches2Context() {
        String failure = new ComparisonCompactor(2, "abcdde", "abcde").compact(null);
        assertEquals("expected:<...cd[d]e> but was:<...cd[]e>", failure);
    }

    public void testComparisonErrorWithActualNull() {
        String failure = new ComparisonCompactor(0, "a", null).compact(null);
        assertEquals("expected: but was:", failure);
    }

    public void testComparisonErrorWithActualNullContext() {
        String failure = new ComparisonCompactor(2, "a", null).compact(null);
        assertEquals("expected: but was:", failure);
    }

    public void testComparisonErrorWithExpectedNull() {
        String failure = new ComparisonCompactor(0, null, "a").compact(null);
        assertEquals("expected: but was:", failure);
    }

    public void testComparisonErrorWithExpectedNullContext() {
        String failure = new ComparisonCompactor(2, null, "a").compact(null);
        assertEquals("expected: but was:", failure);
    }

    public void testBug609972() {
        String failure = new ComparisonCompactor(10, "S&P500", "0").compact(null);
        assertEquals("expected:<[S&P50]0> but was:<[]0>", failure);
    }
}

직접 테스트

code : https://github.com/rkaehdaos/cleancode-ch15-Junit
project : https://github.com/rkaehdaos/cleancode-ch15-Junit/projects/1
들여다보기 부분 : https://github.com/rkaehdaos/cleancode-ch15-Junit/issues/1
고쳐보자 부분 : https://github.com/rkaehdaos/cleancode-ch15-Junit/issues/2

결론

처음으로 본 제대로 된 코드
리팩터링 책의 예제보다 훨씬 깔끔해보임
테스트도 합리적..이고 양도 좀 많긴 함
이왕이면 위험 부분과 경계 영역 테스트가 좀 더 많아야 하지 않을까 하고 생각.

[Clean Code] XIV. 점진적 개선(SUCCESSIVE REFINEMENT)

Wed, 09 Feb 2022 00:56:22 GMT

Clean Code 3판을 읽고 정리한 글입니다

SUCCESSIVE REFINEMENT : 연속적인 정제

해당 챕터는 점진적인 개선을 보여주는 사례 연구
우선, 출발은 좋았으나 확장성이 부족했던 모듈을 소개
그런 다음, 모듈을 개선하고 정리하는 단계를 살펴본다

예시

프로그램을 짜다 보면 종종 명령행 인수의 구문을 분석할 필요가 생긴다
편리한 유틸리티가 없다면 main 함수로 넘어오는 문자열 배열을 직접 분석하게 된다
내 사정에 딱 맞는 유틸리티가 없다면? 물론 직접 짜겠다고 결심한다. 새로 짠 유틸리티를 Args라 부르겠다

간단한 Args 사용법

public static void main(String[] args) {
  try {
    Args arg = new Args("l,p#,d*", args);
    boolean logging = arg.getBoolean('l');
    int port = arg.getInt('p');
    String directory = arg.getString('d');
    executeApplication(logging, port, directory);
  } catch (ArgsException e) {
    System.out.print("Argument error: %s\n", e.errorMessage());
  }
}

설명

명령어 인수 구문 분석기
Args는 사용법이 간단하다
Args 생성자에 (입력 파라미터로 들어온) 인수 문자열과 형식 문자열을 넘겨 Args 인스턴스를 생성
- 첫 파라미터 : 형식 또는 스키마를 지정, 예시에서는 부울인수, 정수 인수, 문자열인수
- 두번째 파라미터 : main으로 넘어온 명령행 인수배열 자체
명령행 인수 구문 분석 시도
- 성공? → 정상적으로 인스턴스 생성 → 그 후 Args 인스턴스에다 인수 값을 질의(getter메서드)
- 실패? → ArgsException 발생 → 형식 문자열이나 명령행 인수 자체에 문제

Args 구현

14-2 Args.java 대체로 깔끔한 구조에 잘짜인

package com.objectmentor.utilities.args;

import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; 
import java.util.*;

public class Args {
  private Map marshalers;
  private Set argsFound;
  private ListIterator currentArgument;
  
  public Args(String schema, String[] args) throws ArgsException { 
    marshalers = new HashMap(); 
    argsFound = new HashSet();
    
    parseSchema(schema);
    parseArgumentStrings(Arrays.asList(args)); 
  }
  
  private void parseSchema(String schema) throws ArgsException { 
    for (String element : schema.split(","))
      if (element.length() > 0) 
        parseSchemaElement(element.trim());
  }
  
  private void parseSchemaElement(String element) throws ArgsException { 
    char elementId = element.charAt(0);
    String elementTail = element.substring(1);
    validateSchemaElementId(elementId);
    if (elementTail.length() == 0)
      marshalers.put(elementId, new BooleanArgumentMarshaler());
    else if (elementTail.equals("*")) 
      marshalers.put(elementId, new StringArgumentMarshaler());
    else if (elementTail.equals("#"))
      marshalers.put(elementId, new IntegerArgumentMarshaler());
    else if (elementTail.equals("##")) 
      marshalers.put(elementId, new DoubleArgumentMarshaler());
    else if (elementTail.equals("[*]"))
      marshalers.put(elementId, new StringArrayArgumentMarshaler());
    else
      throw new ArgsException(INVALID_ARGUMENT_FORMAT, elementId, elementTail);
  }
  
  private void validateSchemaElementId(char elementId) throws ArgsException { 
    if (!Character.isLetter(elementId))
      throw new ArgsException(INVALID_ARGUMENT_NAME, elementId, null); 
  }
  
  private void parseArgumentStrings(List argsList) throws ArgsException {
    for (currentArgument = argsList.listIterator(); currentArgument.hasNext();) {
      String argString = currentArgument.next(); 
      if (argString.startsWith("-")) {
        parseArgumentCharacters(argString.substring(1)); 
      } else {
        currentArgument.previous();
        break; 
      }
    } 
  }
  
  private void parseArgumentCharacters(String argChars) throws ArgsException { 
    for (int i = 0; i < argChars.length(); i++)
      parseArgumentCharacter(argChars.charAt(i)); 
  }
  
  private void parseArgumentCharacter(char argChar) throws ArgsException { 
    ArgumentMarshaler m = marshalers.get(argChar);
    if (m == null) {
      throw new ArgsException(UNEXPECTED_ARGUMENT, argChar, null); 
    } else {
      argsFound.add(argChar); 
      try {
        m.set(currentArgument); 
      } catch (ArgsException e) {
        e.setErrorArgumentId(argChar);
        throw e; 
      }
    } 
  }
  
  public boolean has(char arg) { 
    return argsFound.contains(arg);
  }
  
  public int nextArgument() {
    return currentArgument.nextIndex();
  }
  
  public boolean getBoolean(char arg) {
    return BooleanArgumentMarshaler.getValue(marshalers.get(arg));
  }
  
  public String getString(char arg) {
    return StringArgumentMarshaler.getValue(marshalers.get(arg));
  }
  
  public int getInt(char arg) {
    return IntegerArgumentMarshaler.getValue(marshalers.get(arg));
  }
  
  public double getDouble(char arg) {
    return DoubleArgumentMarshaler.getValue(marshalers.get(arg));
  }
  
  public String[] getStringArray(char arg) {
    return StringArrayArgumentMarshaler.getValue(marshalers.get(arg));
  } 
}

특징 : 코드가 아래로 읽힌다

잘 읽었으면 ArgumentMarshaler 인터페이스와 파생 클래스의 기능을 이해했을 것

14-3 ArgumentMarshaler.java

1
2
3

public interface ArgumentMarshaler {
  void set(Iterator currentArgument) throws ArgsException;
}

14-4 BooleanArgumentMarshaler.java

public class BooleanArgumentMarshaler implements ArgumentMarshaler { 
  private boolean booleanValue = false;
  
  public void set(Iterator currentArgument) throws ArgsException { 
    booleanValue = true;
  }
  
  public static boolean getValue(ArgumentMarshaler am) {
    if (am != null && am instanceof BooleanArgumentMarshaler)
      return ((BooleanArgumentMarshaler) am).booleanValue; 
    else
      return false; 
  }
}

StringArgumentMarshaler.java

import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*;

public class StringArgumentMarshaler implements ArgumentMarshaler { 
  private String stringValue = "";
  
  public void set(Iterator currentArgument) throws ArgsException { 
    try {
      stringValue = currentArgument.next(); 
    } catch (NoSuchElementException e) {
      throw new ArgsException(MISSING_STRING); 
    }
  }
  
  public static String getValue(ArgumentMarshaler am) {
    if (am != null && am instanceof StringArgumentMarshaler)
      return ((StringArgumentMarshaler) am).stringValue; 
    else
      return ""; 
  }
}

IntegerArgumentMarshaler.java

import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*;

public class IntegerArgumentMarshaler implements ArgumentMarshaler { 
  private int intValue = 0;
  
  public void set(Iterator currentArgument) throws ArgsException { 
    String parameter = null;
    try {
      parameter = currentArgument.next();
      intValue = Integer.parseInt(parameter);
    } catch (NoSuchElementException e) {
      throw new ArgsException(MISSING_INTEGER);
    } catch (NumberFormatException e) {
      throw new ArgsException(INVALID_INTEGER, parameter); 
    }
  }
  
  public static int getValue(ArgumentMarshaler am) {
    if (am != null && am instanceof IntegerArgumentMarshaler)
      return ((IntegerArgumentMarshaler) am).intValue; 
    else
    return 0; 
  }
}

DoubleArgumentMarshaler, StringArrayArgumentMarshaler는 생략, 연습문제

ArgsException.java 오류 코드 상수 정의

import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*;

public class ArgsException extends Exception { 
  private char errorArgumentId = '\0'; 
  private String errorParameter = null; 
  private ErrorCode errorCode = OK;
  
  public ArgsException() {}
  
  public ArgsException(String message) {super(message);}
  
  public ArgsException(ErrorCode errorCode) { 
    this.errorCode = errorCode;
  }
  
  public ArgsException(ErrorCode errorCode, String errorParameter) { 
    this.errorCode = errorCode;
    this.errorParameter = errorParameter;
  }
  
  public ArgsException(ErrorCode errorCode, char errorArgumentId, String errorParameter) {
    this.errorCode = errorCode; 
    this.errorParameter = errorParameter; 
    this.errorArgumentId = errorArgumentId;
  }
  
  public char getErrorArgumentId() { 
    return errorArgumentId;
  }
  
  public void setErrorArgumentId(char errorArgumentId) { 
    this.errorArgumentId = errorArgumentId;
  }
  
  public String getErrorParameter() { 
    return errorParameter;
  }
  
  public void setErrorParameter(String errorParameter) { 
    this.errorParameter = errorParameter;
  }
  
  public ErrorCode getErrorCode() { 
    return errorCode;
  }
  
  public void setErrorCode(ErrorCode errorCode) { 
    this.errorCode = errorCode;
  }
  
  public String errorMessage() { 
    switch (errorCode) {
      case OK:
        return "TILT: Should not get here.";
      case UNEXPECTED_ARGUMENT:
        return String.format("Argument -%c unexpected.", errorArgumentId);
      case MISSING_STRING:
        return String.format("Could not find string parameter for -%c.", errorArgumentId);
      case INVALID_INTEGER:
        return String.format("Argument -%c expects an integer but was '%s'.", errorArgumentId, errorParameter);
      case MISSING_INTEGER:
        return String.format("Could not find integer parameter for -%c.", errorArgumentId);
      case INVALID_DOUBLE:
        return String.format("Argument -%c expects a double but was '%s'.", errorArgumentId, errorParameter);
      case MISSING_DOUBLE:
        return String.format("Could not find double parameter for -%c.", errorArgumentId); 
      case INVALID_ARGUMENT_NAME:
        return String.format("'%c' is not a valid argument name.", errorArgumentId);
      case INVALID_ARGUMENT_FORMAT:
        return String.format("'%s' is not a valid argument format.", errorParameter);
    }
    return ""; 
  }
  
  public enum ErrorCode {
    OK, INVALID_ARGUMENT_FORMAT, UNEXPECTED_ARGUMENT, INVALID_ARGUMENT_NAME, 
    MISSING_STRING, MISSING_INTEGER, INVALID_INTEGER, MISSING_DOUBLE, INVALID_DOUBLE
  }
}

단순 개념 구현에 너무 많은 코드

장환한 언어 자바 → 정적 타입 언어 → 타입 시스템 만족을 위해 많은 단어 필요
네이밍, 함수 크기, 형식에 주목 → 전반적으로 깔끔하고 잘짜인 프로그램

예) 날짜 인수, 복소수 인수 등 새로운 인스타입 추가

ArgumentMarshaler에서 새 클래스를 파생해 getXXX 함수를 추가
parseSchemaElement 함수에 새 case 문만 추가하면 끝
필요시 ArgsException.ErrorCode를 만들고 새 오류 메시지를 추가

어떻게 짰느냐고?

한번에 뚝딱 나온 것이 아님

수십 년의 교훈 : 프로그래밍은 과학보다 공예(craft)에 가깝다
깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미
작문도 1차 초안, 2차 초안 최종안을 만든다
대부분 신참은 대다수의 초딩처럼 이 충고를 따르지않음
- 무조건 돌아가는 프로그램 목표 → 일단 ‘돌아가면’ 다음 업무 → ‘돌아가는’ 프로그램은 상태가 어떻든 LET IT BE → 자살 행위

Args: 1차 초안

Args.java 1차 초안

import java.text.ParseException; 
import java.util.*;

public class Args {
  private String schema;
  private String[] args;
  private boolean valid = true;
  private Set unexpectedArguments = new TreeSet(); 
  private Map booleanArgs = new HashMap();
  private Map stringArgs = new HashMap(); 
  private Map intArgs = new HashMap(); 
  private Set argsFound = new HashSet();
  private int currentArgument;
  private char errorArgumentId = '\0';
  private String errorParameter = "TILT";
  private ErrorCode errorCode = ErrorCode.OK;
  
  private enum ErrorCode {
    OK, MISSING_STRING, MISSING_INTEGER, INVALID_INTEGER, UNEXPECTED_ARGUMENT}
    
  public Args(String schema, String[] args) throws ParseException { 
    this.schema = schema;
    this.args = args;
    valid = parse();
  }
  
  private boolean parse() throws ParseException { 
    if (schema.length() == 0 && args.length == 0)
      return true; 
    parseSchema(); 
    try {
      parseArguments();
    } catch (ArgsException e) {
    }
    return valid;
  }
  
  private boolean parseSchema() throws ParseException { 
    for (String element : schema.split(",")) {
      if (element.length() > 0) {
        String trimmedElement = element.trim(); 
        parseSchemaElement(trimmedElement);
      } 
    }
    return true; 
  }
  
  private void parseSchemaElement(String element) throws ParseException { 
    char elementId = element.charAt(0);
    String elementTail = element.substring(1); 
    validateSchemaElementId(elementId);
    if (isBooleanSchemaElement(elementTail)) 
      parseBooleanSchemaElement(elementId);
    else if (isStringSchemaElement(elementTail)) 
      parseStringSchemaElement(elementId);
    else if (isIntegerSchemaElement(elementTail)) 
      parseIntegerSchemaElement(elementId);
    else
      throw new ParseException(String.format("Argument: %c has invalid format: %s.", 
        elementId, elementTail), 0);
    } 
  }
    
  private void validateSchemaElementId(char elementId) throws ParseException { 
    if (!Character.isLetter(elementId)) {
      throw new ParseException("Bad character:" + elementId + "in Args format: " + schema, 0);
    }
  }
  
  private void parseBooleanSchemaElement(char elementId) { 
    booleanArgs.put(elementId, false);
  }
  
  private void parseIntegerSchemaElement(char elementId) { 
    intArgs.put(elementId, 0);
  }
  
  private void parseStringSchemaElement(char elementId) { 
    stringArgs.put(elementId, "");
  }
  
  private boolean isStringSchemaElement(String elementTail) { 
    return elementTail.equals("*");
  }
  
  private boolean isBooleanSchemaElement(String elementTail) { 
    return elementTail.length() == 0;
  }
  
  private boolean isIntegerSchemaElement(String elementTail) { 
    return elementTail.equals("#");
  }
  
  private boolean parseArguments() throws ArgsException {
    for (currentArgument = 0; currentArgument < args.length; currentArgument++) {
      String arg = args[currentArgument];
      parseArgument(arg); 
    }
    return true; 
  }
  
  private void parseArgument(String arg) throws ArgsException { 
    if (arg.startsWith("-"))
      parseElements(arg); 
  }
  
  private void parseElements(String arg) throws ArgsException { 
    for (int i = 1; i < arg.length(); i++)
      parseElement(arg.charAt(i)); 
  }
  
  private void parseElement(char argChar) throws ArgsException { 
    if (setArgument(argChar))
      argsFound.add(argChar); 
    else 
      unexpectedArguments.add(argChar); 
      errorCode = ErrorCode.UNEXPECTED_ARGUMENT; 
      valid = false;
  }
  
  private boolean setArgument(char argChar) throws ArgsException { 
    if (isBooleanArg(argChar))
      setBooleanArg(argChar, true); 
    else if (isStringArg(argChar))
      setStringArg(argChar); 
    else if (isIntArg(argChar))
      setIntArg(argChar); 
    else
      return false;
    
    return true; 
  }
  
  private boolean isIntArg(char argChar) {
    return intArgs.containsKey(argChar);
  }
  
  private void setIntArg(char argChar) throws ArgsException { 
    currentArgument++;
    String parameter = null;
    try {
      parameter = args[currentArgument];
      intArgs.put(argChar, new Integer(parameter)); 
    } catch (ArrayIndexOutOfBoundsException e) {
      valid = false;
      errorArgumentId = argChar;
      errorCode = ErrorCode.MISSING_INTEGER;
      throw new ArgsException();
    } catch (NumberFormatException e) {
      valid = false;
      errorArgumentId = argChar; 
      errorParameter = parameter;
      errorCode = ErrorCode.INVALID_INTEGER; 
      throw new ArgsException();
    } 
  }
  
  private void setStringArg(char argChar) throws ArgsException { 
    currentArgument++;
    try {
      stringArgs.put(argChar, args[currentArgument]); 
    } catch (ArrayIndexOutOfBoundsException e) {
      valid = false;
      errorArgumentId = argChar;
      errorCode = ErrorCode.MISSING_STRING; 
      throw new ArgsException();
    } 
  }
  
  private boolean isStringArg(char argChar) { 
    return stringArgs.containsKey(argChar);
  }
  
  private void setBooleanArg(char argChar, boolean value) { 
    booleanArgs.put(argChar, value);
  }
  
  private boolean isBooleanArg(char argChar) { 
    return booleanArgs.containsKey(argChar);
  }
  
  public int cardinality() { 
    return argsFound.size();
  }
  
  public String usage() { 
    if (schema.length() > 0)
      return "-[" + schema + "]"; 
    else
      return ""; 
  }
  
  public String errorMessage() throws Exception { 
    switch (errorCode) {
      case OK:
        throw new Exception("TILT: Should not get here.");
      case UNEXPECTED_ARGUMENT:
        return unexpectedArgumentMessage();
      case MISSING_STRING:
        return String.format("Could not find string parameter for -%c.", errorArgumentId);
      case INVALID_INTEGER:
        return String.format("Argument -%c expects an integer but was '%s'.", errorArgumentId, errorParameter);
      case MISSING_INTEGER:
        return String.format("Could not find integer parameter for -%c.", errorArgumentId);
    }
    return ""; 
  }
  
  private String unexpectedArgumentMessage() {
    StringBuffer message = new StringBuffer("Argument(s) -"); 
    for (char c : unexpectedArguments) {
      message.append(c); 
    }
    message.append(" unexpected.");
    
    return message.toString(); 
  }
  
  private boolean falseIfNull(Boolean b) { 
    return b != null && b;
  }
  
  private int zeroIfNull(Integer i) { 
    return i == null ? 0 : i;
  }
  
  private String blankIfNull(String s) { 
    return s == null ? "" : s;
  }
  
  public String getString(char arg) { 
    return blankIfNull(stringArgs.get(arg));
  }
  
  public int getInt(char arg) {
    return zeroIfNull(intArgs.get(arg));
  }
  
  public boolean getBoolean(char arg) { 
    return falseIfNull(booleanArgs.get(arg));
  }
  
  public boolean has(char arg) { 
    return argsFound.contains(arg);
  }
  
  public boolean isValid() { 
    return valid;
  }
  
  private class ArgsException extends Exception {
  } 
}

사실상 초안도 아닌 미완성

함수 이름, 변수이름, 나름의 구조 → 나름의 노력의 증거
하지만 결과는 엉망
책에서는 초안 이전의 그나마 나았던 코드에서 엉망이 되어가는 부분을 보여주고 있음

그래서 멈췄다

완성을 멈추다

추가할 인수 유형이 적어도 2개 → 더 나쁜 코드가 되는 자명한 사실
코드 리팩터링의 적기를 지금으로 판단

전체 리팩터링 진행

결론

나쁜 일정은 다시 짜면 된다. 나쁜 요구사항은 다시 정의하면 된다. 나쁜 팀 역학은 복구하면 된다.
하지만 나쁜 코드는 썩어 문드러진다. 점점 무게가 늘어나 팀의 발목을 잡는다
서두르다 영원히 자신의 운명을 지배할 악성 코드라는 굴레를 짊어진다
그저 돌아가는 코드만으로는 부족하다. 돌아가는 코드가 심하게 망가지는 사례는 흔하다. 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다.
나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다
물론 나쁜 코드도 깨끗한 코드로 개선할 수 있다. 하지만 비용이 엄청나게 많이 든다
- 코드가 썩어가며 모듈은 서로서로 얽히고설켜 뒤엉키고 숨겨진 의존성이 수도 없이 생긴다
- 오래된 의존성을 찾아내 깨려면 상당한 시간과 인내심이 필요하다
반면 처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽다
- 아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다
- 더욱이 5분 전에 엉망으로 만든 코드는 지금 당장 정리하기 아주 쉽다
그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리하자. 절대로 썩어가게 방치하면 안 된다.

진짜 테스트 코드는 여기 있었네;; 반성

프로그램을 망치는 가장 좋은 방법 중 하나 ? 개선이라는 이름 아래 구조를 크게 뒤집는 행위

[Clean Code] XIII. 동시성

Wed, 09 Feb 2022 00:56:00 GMT

Clean Code 3판을 읽고 정리한 글입니다

XIII. 동시성(Concurrency)

“Objects are abstractions of processing. Threads are abstractions of schedule.”
객체는 처리의 추상화. 스레드는 일정의 추상화.
James O. Coplien밥아저씨 지인

동시성과 클린 코드의 양립은 아주 어렵다

단일 스레드에서 동작하는 코드는 작성하기 쉽다
잘 동작하는 “것 처럼” 보이는 멀티 스레드 코드를 작성하기도 쉽다
부하를 받기 전까지 멀쩡하게 돌아간다

동시성(Concurrency)이 필요한 이유?

동시성 = what과 when을 분리하는 전략

동시성은 coupling을 없애는 전략 : what과 when
스레드가 하나인 프로그램 : what과 when이 강하게 결합되어 있고 밀접
- 단일 스레드 디버깅: breakpoint 정한 후 어느 정지점에 걸렸는가 시스템 파악

what when의 분리 → 어플리케이션의 구조와 효율의 극적 개선

구조관점 : 거대한 loop가 아닌 작은 여러개의 협력 프로그램으로 보임 → 시스템 이해가 쉽고 문제 분리도 쉬움
- 예시 ) 서블릿
  - 서블릿은 서블릿 컨테이너 안에서 돌아감 → 컨테이너가 동시성을 ‘부분적으로’ 관리
  - 웹 요청시 마다 웹 서버는 비동기식으로 서블릿 실행
  - (이론적으로) 서블릿 개발자는 들어오는 모든 웹 요청 관리가 필요없음
  - (원칙적으로) 각 서블릿 스레드는 다른 서블릿 스레드와 무관하게 자신만의 세상에서 돌아간다

동시성이 이렇게 간단하면 이번 챕터가 필요 없었을 것

서블릿이 제공하는 의존성 해소는 완벽하지 않음
웹 컨테이너의 deCoupling → 완벽과 거리가 아주 멀다
서블릿 프로그래머는 동시성을 정확히 구현하도록 각별한 주의와 노력을 기울여야 한다.
그럼에도 서블릿 모델이 제공하는 구조적 이점은 아주 크다.

구조적 개선만을 위해 동시성을 채택하는 건 아니다

어떤 시스템은 응답 시간과 작업 처리량 (throughput) 개선이라는 요구사항으로 인해 직접적인 동시성 구현이 불가피하다
예시1) 매일 수많은 웹 사이트에서 정보를 가져와 요약하는 정보 수집기인데 단일 스레드 프로그램???
- 한 번에 한 웹 사이트를 방문해 정보를 가져오고, 이 과정에서 한 사이트를 끝내야 다음 사이트로 넘어간다
- 웹 사이트를 계속 추가하면 정보 수집하는 시간도 늘어난다
- 매일 실행하므로 24시간 안에 끝나야 하지만 24시간을 넘기게 된다
- 단일 스레드 수집기는 웹 소켓에서 입출력을 기다리는 시간이 아주 많다
- 따라서 다중 스레드 알고리즘을 사용하면 수집기 성능을 높일 수 있다.
예시 2) 한 번에 한 사용자를 처리하는 시스템: 한 사용자를 처리하는 시간은 1초
- 사용자가 소수라면 시스템이 아주 빨리 반응하지만, 사용자 수가 늘어날수록 시스템이 응답하는 속도도 늦어진다
- 150명 뒤에 줄 서려는 사용자는 없다
- 대신 많은 사용자를 동시에 처리하면 시스템 응답 시간을 높일 수 있다
예시 3) 정보를 대량으로 분석하는 시스템
- 모든 정보를 처리한 후에야 최종적인 답을 낼 수 있다
- 정보를 나눠 여러 컴퓨터에서 돌리면 어떨까? 대량의 정보를 병렬로 처리한다면?

미신과 오해

동시성은 어려우며 각별히 주의하지 않으면 난감한 상황에 빠진다

일반적인 오해와 미신

동시성은 항상 성능을 높여준다?

동시성은 항상은 아니고 때로 성능을 높여준다
대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다
일상적으로 발생하는 상황은 아니다

동시성을 구현해도 설계는 변하지 않는다?

단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다
일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다

웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다?

실제로는 컨테이너 동작 원리와 어떻게 동시 수정(concurrent update), 데드락 등과 같은 문제를 피할 수 있는지 알아야만 한다

동시성과 관련된 타당한 생각들

동시성은 다소 부하를 유발한다

성능 측면에서 부하가 걸리며, 코드도 더 짜야한다 → 성능, 코드 작성 양쪽 모두 약간의 오버헤드를 일으킴

동시성은 복잡하다

간단한 문제라도 동시성은 복잡해서 해결이 쉽지 않음

일반적으로 동시성 버그는 재현하기 어렵다]

그래서 진짜 결함으로 간주되지 않고 일회성 문제(one-off)로 여겨 무시하기 쉽다

동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다

난관 - 동시성이 구현하기 어려운 이유

public class ClassWithThreadingProblem {
    private int lastIdUsed;
    
    public ClassWithThreadingProblem(int lastIdUsed) {
        this.lastIdUsed = lastIdUsed;
    }
    
    public int getNextId() {
        return ++lastIdUsed;
    }

    public static void main(String args[]) {
        final ClassWithThreadingProblem classWithThreadingProblem = new ClassWithThreadingProblem(42);

        Runnable runnable = new Runnable() {
            public void run() {
                classWithThreadingProblem.getNextId();
            }
        };
    
        Thread t1 = new Thread(runnable);
        Thread t2 = new Thread(runnable);
        t1.start();
        t2.start();
    }
}

설명

인스턴스 ClassWithThreadingProblem를 생성하고, lastIdUsed 필드를 42로 설정한 다음, 두 스레드가 해당 인스턴스를 공유한다
이제 두 스레드가 getNextId();를 호출한다고 가정하자. 결과는 셋 중 하나다.
- 한 스레드는 43을 받는다. 다른 스레드는 44를 받는다. lastIdUsed는 44가 된다.
- 한 스레드는 44를 받는다. 다른 스레드는 43을 받는다. lastIdUsed는 44가 된다.
- 한 스레드는 43을 받는다. 다른 스레드는 43을 받는다. lastIdUsed는 43이 된다. (??)
2스레드가 실행하는 잠재적 경로(N=8,T=2)는 12,870개
극히 드물지만 위와 같이 잘못된 결과가 나오게 된다

동시성 방어 원칙

단일 책임 원칙(Single Responsibility Principle, SRP)

주어진 메서드/클래스/컴포넌트를 변경할 이유는 하나여야 한다는 원칙
동시성은 복잡성 하나만으로도 따로 분리할 이유가 충분 → 동시성 관련 코드는 다른 코드와 분리해야 한다
불행히 동시성과 관련이 없는 코드에 동시성을 곧바로 구현하는 사례가 너무도 흔함
동시성 구현시 고려사항

동시성 코드는 독자적인 개발, 변경, 조율 주기가 있다.
동시성 코드에는 독자적인 난관이 있다. 다른 코드에서 겪는 난관과 다르며 훨씬 어렵다.
잘못 구현한 동시성 코드는 별의별 방식으로 실패한다. 주변에 있는 다른 코드가 발목을 잡지 않더라도 동시성 하나만으로도 충분히 어렵다.
권장사항 : 동시성 코드는 다른 코드와 분리하라!

따름 정리(Corollary): 자료 범위를 제한하라

위 예제에서 보듯이, 객체 하나를 공유한 후 동일 필드를 수정하던 두 스레드가 서로 간섭하므로 예상치 못한 결과를 내놓는다.
이런 문제를 해결하는 방안으로 공유 객체를 사용하느 코드 내 임계 영역(critical section)을 synchronized 키워드로 보호하라고 권장한다
이런 임계영역의 수를 줄이는 기술이 중요하다.
공유 자료 수정 위치가 많아지면?
1. 보호할 임계영역을 빼먹는다. 그래서 공유 자료를 수정하는 모든 코드를 망가뜨린다
2. 모든 임계영역을 올바로 보호했는지(DRY 위반) 확인하느라 똑같은 노력과 수고를 반복한다
3. 그렇지 않아도 찾아내기 어려운 버그가 더욱 찾기 어려워진다
  권장사항 : 자료를 EnCapsulation하고 공유 자료를 최대한 줄여라~!

따름 정리: 자료 사본을 사용하라

공유 자료를 줄이는 가장 좋은 방법? → 처음부터 공유하지 않는 방법
- 어떤 경우엔 객체를 복사해 읽기 전용으로 사용하는 것이 가능
- 어떤 경우에는 객체의 복사본을 각 스레드에 전달, 작업을 수행하고 결과를 단일 스레드에서 수집해 사용하는 것도 가능
공유 객체를 피하는 방법이 있다면 코드가 문제를 일으킬 가능성도 아주 낮아진다
객체의 복사에 드는 비용(시간과 부하)은?
- 이 복사 비용이 정말 문제인지 실측할 필요가 있음
- 사본 사용으로 동기화 피할 수 있으면? → 내부 잠금이 없음 → 수행 시간 절약 → 사본생성과 가비지 컬렉션의 비용 상쇄할 가능성이 크다

따름 정리: 스레드는 가능한 독립적으로 구현하라

자신만의 세상속의 스레드를 구현한다면?

다른 스레드와 자료 공유 안함
각 스레드는 클라이언트 요청 하나 처리
모든 정보는 비공유 출처에서 가져오며 로컬 변수에 저장
→ 다른 스레드와 동기화가 필요없음 → 각 스레드는 자신만 존재하듯 돌아갈 수 있음 → 동기화 문제 없어짐

ex)HttpServlet

HttpServlet의 파생 클래스는 모든 정보를 doGet, doPost 매개변수로 받아 처리
각 서블릿은 마치 자신이 독자적인 시스템에서 동작하는 것처럼 요청 처리
지역 변수를 사용하는 한 동기화 문제는 발생하지 않는다
물론 대부분의 Servlet 어플리케이션은 결국 DB 연결과 같은 자원을 공유하는 상황에 처한다
권장사항 : 독자적인 스레드로 (가능하면 다른 프로세서에서 돌려도 괜찮도록) 자료를 독립적인 단위로 분할!

라이브러리를 이해하라

자바 5부터 동시성 측면에서 이전 버전보다 많이 개선 되었음. 5이상 버전부터 스레드 구현시 고려사항

자바5부터 제공하는 thread-safe 컬랙션을 사용한다
서로 연관없이 무관한 작업을 수행 시 executor 프레임워크를 사용
가능하면 스레드가 차단(block)되지 않는 논 블러킹 방법을 사용
일부 클래스 라이브러리들은 thread-safe하지 않음에 주의

스레드 환경에 안전한 컬렉션

java.util.concurrent

자바 초창기 : Doug Lea, Concurrent Programming in Java
해당 책에서 스레드에서 안전한 컬렉션 몇 개를 구현 했는데 나중에 자바 패키지에 추가됨
해당 패키지의 클래스는 다중 스레드에서 안정되며, 성능도 좋음
ConcurrentHashMap은 실제로 거의 모든 상황에서 HashMap보다 빠르다
- 동시 읽기/쓰기 지원
- (보통 다중 스레드에서 문제가 생기는) 자주 사용하는 복합 연산을 안전하게 만든 메서드로 제공

좀 더 복잡한 동시성 설계를 지원하는 클래스 몇 가지

Name	Description
ReentrantLock	한 메서드에서 잠그고 다른 메서드에서 풀 수 있는 lock이다.
Semaphore	전통적인 세마포어(갯수를 셀 수 있는 lock)의 구현체.
CountDownLatch	지정한 특정 횟수의 이벤트가 발생하고 나서야 기다리는 모든 스레드들을 해제 할 수 있는 lock이다. 모든 스레드가 거의 동시에 시작될 수 있는 기회를 준다
권장사항 :

언어가 제공하는 클래스를 검토하라. 자바의 경우 다음을 익혀라
- java.util.concurrent
- java.util.concurrent.atomic
- java.util.concurrent.locks

실행 모델을 이해하라

기본용어

Name	Description
Bound Resources(한정된 자원)	Concurrent 환경에서 사용되는 고정된 크기의 자원이다. 예시로 데이터베이스 연결, 고정된 크기의 읽기/쓰기 버퍼가 있다.
Mutual Exclusion(상호 배제)	한 번에 한 스레드만 공유 자료/공유 자원을 사용할 수 있는 경우
Starvation(기아)	한 스레드 or 스레드 그룹이 긴 시간 or 영원히 자원 대기. 예를 들어, 항상 짧은 스레드에게 우선 순위를 준다면, 수행 시간이 긴 스레드는 굶게 된다(기아 상태).
Deadlock(데드락)	여러 스레드가 서로가 끝나기를 기다린다. 각 스레드는 서로가 필요로 하는 자원을 점유하고 있기 떄문에 어느 쪽도 더 이상 진행하지 못함
Livelock(라이브락)	락을 거는 단계에서 각 스레드가 서로를 방해. 스레드들이 서로 작업을 수행하려는 중 다른 스레드가 작업중인 것을 인지하고 서로 양보한다. 이러한 공명(resonance) 때문에 스레드들은 작업을 계속 수행하려 하지만 장시간 혹은 영원히 작업을 수행하지 못하게 된다.

기본 개념을 이해했으면 다중 스레드 프로그래밍에서 사용하는 실행 모델을 살펴본다

생산자-소비자(Producer-Consumer)

한 개 이상의 생산자 스레드가 정보를 생성한 후 버퍼나 큐에 넣는다
한 개 이상의 소비자 스레드가 버퍼 혹은 큐에서 정보를 가져와 사용
생산자와 소비자 사이에 있는 큐는 bound resource(한정된 자원)이다
따라서 생산자는 큐에 빈 공간이 생길 때까지, 소비자는 큐에 정보가 하나라도 생길 때까지 기다린다
대기열을 올바로 사용하기 위해 생산자/소비자는 서로에게 시그널을 보낸다
생산자는 큐에 작업물을 넣고 소비자에게 “큐가 비어있지 않다”는 신호를 보내고
소비자는 큐에서 작업물을 꺼낸 후 “큐가 가득차 있지 않다”는 신호를 보낸다 그 전까지 둘은 신호를 기다린다.
따라서 잘못하면 생산자/소비자 둘 다 진행 가능함에도 서로 시그널을 기다릴 가능성이 존재

읽기-쓰기(Readers-Writers)

예) 읽기 스레드를 위한 주된 정보원으로 사용되는 공유자원인데, 쓰기 스레드에 의해 이따금씩 갱신되는 경우
예시의 경우 처리율(throughput)이 핵심 포인트

쓰기가 갱신 중에 읽기 스레드가 멈추고, 읽기 스레드가 읽는 중엔 쓰기 스레드가 갱신을 멈춰야 한다
처리율 강조? 독자가 상대적 우선권 → starvation(기아) 현상 or 오래되고 정체된 정보로 가득
갱신 허용? : 쓰기가 상대적 우선권 → 처리율이 감소

간단한 해법 : 읽기 스레드가 없을 때까지 갱신을 원하는 쓰기 스레드가 버퍼를 기다리는 방법

읽기 스레드 계속? 쓰기가 기아 상태에 빠짐
쓰기 스레드 계속? 처리율이 떨어짐

양쪽 균형을 잡으면서 동시 갱신 문제를 피하는 해법이 필요

식사하는 철학자들(Dining Philosophers)

예시

원탁을 둘러싼 여러 명의 철학자들
각 철학자의 왼쪽에 포크가 놓여 있으며 테이블의 중앙에 큰 스파게티 한 그릇이 놓여 있다
그들은 배가 고파지기 전까지 각자 생각을 하며 시간을 보낸다
배가 고파지면 그들은 자신의 양쪽에 놓여 있는 포크 2개를 잡고 스파게티를 먹는다
철학자는 포크 2개가 있어야만 스파게티를 먹을 수 있다.
그렇지 않다면 옆 사람이 포크를 다 사용하기 전까지 기다려야 한다.
스파게티를 먹은 철학자는 다시 배가 고파질 때까지 포크를 놓고 있게 된다.
위 상황에서 철학자를 스레드로, 포크를 공유 자원으로 바꾸게 되면?
이는 자원을 놓고 경쟁하는 프로세스와 비슷한 상황
잘 설계되지 않은 시스템은 deadlock, livelock, 처리량 문제, 효율성 저하 문제에 맞닥뜨리기 쉽다

일상에서 접하는 대부분의 concurrent관련 문제들은 이 세 범주 중 하나에 속한다

이 알고리즘들을 공부하고 스스로 해법을 직접 구현해보라
그러면 나중에 실전 문제에서 해결이 쉬어진다
권장 사항 : 위에서 설명한 기본 알고리즘과 각 해법을 이해하라

동기화하는 메서드 사이에 존재하는 의존성을 이해하라

동기화된 메서드 사이에 의존성이 존재하면 동시성 코드에서 찾아내기 어려운 버그가 생김
자바는 synchronized라는 개별 메서드 보호 개념 지원
하지만 한 공유 클래스에 두 개 이상의 synchronized 메서드가 존재하면 문제를 일으킬 수도 있다.

권장 사항 : 공유 객체 하나에는 메서드 하나만 사용

권장사항 밖의 상황 : 공유 객체 하나에 여러 메서드가 필요한 경우?

Client-Based Locking(클라이언트 기반 잠금)

클라이언트에서 첫 번째 메서드를 호출하기 전에 서버를 잠근다
(공유 객체를 사용하는 코드에서 공유 객체 Lock)
마지막 메서드를 호출할 떄까지 잠금 유지
Bad
- 서버를 사용하는 모든 클라이언트 코드에서 lock이 필요
- 이는 유지보수 및 디버깅에 필요한 비용을 상승시킨다.

Server-Based Locking

서버 에다 “서버(자신)을 잠그고 모든 동작을 수행한 후 잠금을 푸는” 메서드를 구현
클라이언트는 이 메서드를 호출
(공유 객체에 새로운 메서드를 작성하고 잠금이 필요한 동작 전체를 수행하게 하는 것)
=> Good: Critical section에 접근하는 코드를 최소화

Adapted Server

잠금을 수행하는 중계자(중간 단계)를 생성
‘서버에서 잠금’ 방식과 유사하나 원래 서버는 변경하지 않음
이는 기본적으로 서버 기반 잠금이지만 기존의 서버를 변경할 수 없는 상황에 사용할 수 있는 방법
(서드 파티 라이브러리를 사용한다고 생각하면 쉬울 것이다)
=> Good: 서버 기반 잠금 방식을 사용할 수 없는 경우에 사용

동기화하는 부분을 작게 만들어라

자바의 Synchronized 키워드 사용 → 락 설정
같은 락으로 감싼 모든 코드 영역은 한 번에 한 스레드만 실행 가능
락은 스레드 지연(delay)과 부하 가중 유발(비싼 수행) → Synchronized 남발하면 안된다
반면 critical section은 꼭 보호되어야 한다.
- 임계 영역 : 동시 사용을 막아야만 프로그램이 올바로 동작하는 보호받는 코드 영역
코드를 짤 때 임계 영역수를 최대한 줄여야 한다
- 순진한 프로그래머 : 임계 영역 수를 줄이기 위해 거대한 임계 영역 하나로 구현
- 필요이상의 임계영역 크기 → 스레드 간에 경쟁이 늘어나고 프로그램 성능 감소
  권장 사항 : 동기화된 영역은 최대한 작게 만들어라.

올바른 종료 코드는 구현하기 어렵다

“영구적으로 돌아가는 시스템 구현”과 “잠시 돌다 깔끔하게 종료하는 시스템 구현”은 방법이 다르다
깔끔하게 종료하는 코드 : 올바로 구현이 어려움
- 가장 흔한 문제 : 데드락(스레드가 절대 오지 않을 시그널 기다림)
- 예1) 부모 스레드가 자식 스레드를 여러개 만든 후 다 끝나기를 기다렸다가 자원을 해제하고 종료하는 시스템
  - 자식 스레드 하나가 데드락에 걸리면?
  - 부모 스레드는 영원히 가디라고, 시스템은 영원히 종료하지 못한다
- 예2) 유사 시스템의 종료 지시를 받고 부모가 모든 자식 스레드에게 종료 시그널 전달
  - 자식 스레드 중 2개가 생산자/소비자 관계인데 생산자가 재빨리 종료되고 소비자가 waiting이라면?
  - 생산자 메시지를 waiting하는 소비자는 blocked 상태 → 종료시그널 못받음
  - 소비자는 영원히 생산자 스레드 기다림 → 부모는 자식 스레드를 영원히 기다림
- 종종 발생하는 상황임
따라서 깔끔하게 종료하는 멀티 스레드 코드 작성하려면 시간을 투자해 올바로 구현해야 한다
권장 사항
종료 코드를 개발 초기부터 고민하고 동작하게 초기부터 구현하라
생각보다 오래 걸린다
생각보다 어려우므로 이미 나온 알고리즘을 검토하라

스레드 코드 테스트하기

스레드 1개에서 무조건 옳은 경우

코드가 올바르다고 증명은 현실적으로 불가능
테스트는 정확성을 보장하지 않으며 “코드가 제대로 작성되었는가”를 증명할 수 없다
다만 잘 작성된 충분한 테스트는 위험을 최소화할 수 있다
이는 같은 코드와 같은 자원을 사용하는 멀티 스레드 상황에서는 훨씬 더 복잡해 진다

권장 사항

문제를 노출할 만한 테스트 케이스를 작성하라
프로그램 설정, 시스템 설정, 부하를 바꿔가며 자주 수행하라
테스트가 한 번이라도 실패하면 원인을 분석하라
다시 돌렸더니 통과하더라는 이유로 넘어가면 절대 안된다

멀티 스레드 테스트 지침

말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라
다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자
다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라
다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라
프로세서 수보다 많은 스레드를 돌려보라
다른 플랫폼에서 돌려보라
코드에 보조 코드instrument를 넣어 돌려라. 강제로 실패를 일으키게 해보라

말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라

멀티 스레드 코드는 일반적으로 발생할 리 없어 보이는 문제를 발생
(저자를 포함한)대부분의 개발자는 이러한 문제를 직관적으로 이해 불가
스레드 코드의 코드는 파악하지 않으면서 때로는 수백만 번에 한번씩 매우 드물게 발생하기도 함
그래서 많은 개발자들은 이러한 문제들을 우주선(宇宙線), 하드웨어 버그, 혹은 이러한 류의 one-off로 치부
제일 안정된 방향은 one-off(일회성) 문제는 없다고 판단하는 것
이러한 one-off들이 무시될 수록 더 많은 코드들이 이미 문제가 있는 시스템에 추가되게 될 뿐

권장 사항 : 시스템 오작동을 일회성으로 치부하지 마라

다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자

당연한 소리, 스레드 환경 밖에서 코드가 제대로 동작하는지 반드시 확인
일반적으로 스레드가 호출하는 POJO작성→POJO는 스레드를 모름→스레드 환경 밖에서 테스트 가능
따라서 POJO에 넣는 코드가 많을 수록 더 좋다
권장 사항 : 먼저 스레드 환경 밖에서 코드를 올바로 돌려라
→스레드 환경 밖의 버그와 스레드 환경하에서 생기는 버그를 동시에 디버깅하려 하지 말라

다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라

한 스레드로 실행, 여러 스레드로 실행, 실행 중 스레드 수 바꿔보기
스레드 코드를 실제 환경이나 테스트 환경에서 돌려보기
빨리, 천천히 등 다양한 속도로 테스트를 돌려보기
반복 테스트가 가능하도록 테스트 케이스 작성하기
권장 사항 : 다양한 설정에서 실행할 목적으로 다른 환경에 쉽게 끼워 넣을 수 있게 코드를 구현하라

다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라

적절한 스레드 개수 파악은 상당한 시행착오를 필요
처음부터 다양한 설정으로 프로그램 성능 측정 방법 강구
실행할 스레드 갯수를 쉽게 변경할 수 있게 작성
시스템이 동작하는 도중에 스레드 개수를 변경할 수 있게 하는 것을 고려한다
처리량과 시스템 활용도를 기준으로 스스로를 조정할 수 있게 하는 것을 고민한다

프로세서 수보다 많은 스레드를 돌려보라

시스템이 스레드 스와핑 할 때돟 문제는 발생
작업 전환을 빈번히 발생하게 하기 위해 프로세서 수보다 많은 스레드를 실행해 보라
작업 전환이 잦을수록 빠뜨린 critical section이나 dead lock을 찾을 확률이 높아지게 된다

다른 플랫폼에서 돌려보라

멀티 스레드 코드는 실행 환경에 따라 다르게 동작
따라서 모든 잠재적 배포 환경에 대해 테스트를 수행해야 한다.
권장 사항 : 처음부터, 그리고 자주, 모든 타겟 플랫폼에서 코드를 돌려라

코드에 보조 코드instrument를 넣어 돌려라. 강제로 실패를 일으키게 해보라

스레드 버그는 어려움

눈으로 보이지 않고 간단한 테스트로 버그 발견 안됨
코드가 실행되는 수천 가지 경로 중에 아주 소수만 실패
오류를 자주 일으킬 수 있는 방법 : 보조 코드 추가 ▶ 직접 구현하기, 자동화 이렇게 2가지 방법

직접 구현하기

Object.wait(), Object.sleep(), Object.yield(), Object.priority()등의 메서드를 사용해 실행 경로를 변경함으로써 코드의 문제를 발견하는 방법

sleep

지정한 시간동안 작업을 일시정지 상태로 들어가는 메서드
static 메서드로 제공되며(인스턴스 메서드는 deprecated 되었다),
이 메서드를 호출한 쓰레드가 지정한 시간만큼 일시정시 상태가 된다

sleep vs wait

sleep 은 Thread클래스, wait는 object 클래스
sleep은 객체가 중단되거나 실행 완료까지 객체 락 유지, wait은 락해제, 다른객체 notify시 다시 runnable

yield

RUNNABLE 상태로 들어가면서 다른 쓰레드에게 작업을 양보하는 메서드이다

이 또한 static 메서드로 제공되며, 이 메서드를 호출한 쓰레드가 RUNNABLE 상태로 들어가게 된다

테스트를 위해 yield 추가

public synchronized String nextUrlOrNull() {
    if(hasNext()) {
        String url = urlGenerator.next();
        Thread.yield(); // inserted for testing
        updateHasNext();
        return url;
    }
    return null;
}

설명

yield() 메서드를 호출함으로써 코드의 실행 경로를 변경 가능
위 코드에서 문제가 발생한다면 이는 yield()를 추가해 생긴 문제가 아니라 이미 존재하던 문제를 명백히 만든것 뿐이다.
문제점
보조 코드를 삽입할 적정 위치를 직접 찾아야 한다.
어떤 메서드를 어디서 호출해야 좋은지 어떻게 알 것인가
제품에 이와 같은 보조 코드를 포함해 배포하는 것은 불필요하게 퍼포먼스를 저하
Shotgun approach 이기 때문에(무작위) 반드시 문제가 발생한다는 보장을 얻을 수 없다. 사실상 문제가 드러나지 않을 확율이 더 높다
(Shotgun approach: 산탄총처럼 되는대로 시도하는 방법)
→ 배포 환경이 아니라 테스트 환경에서 설정을 바꿔가며 보조코드를 실행할 방법이 필요

시스템을 최대한 POJO와 스레드 제어 클래스로 분할해야한다

보조코드를 추가할 위치를 찾기가 쉬어진다
여러 상황에서 sleep, yield등으로 POJO를 호출하게 다양한 jig 구현 가능

자동화

보조 코드 자동 추가 : AOF(Aspect-Oriented Framework), CGLIB, ASM과 같은 도구

// 메서드가 하나인 클래스

public class ThreadJigglePoint {
    public static void jiggle() { }
}

//다양한 위치에 ThreadJiglePoint.jiggle() 추가 : 무작위 sleep, yield 호출 or nop
public synchronized String nextUrlOrNull() {
    if(hasNext()) {
        ThreadJiglePoint.jiggle();
        String url = urlGenerator.next();
        ThreadJiglePoint.jiggle();
        updateHasNext();
        ThreadJiglePoint.jiggle();
        return url;
    }
    return null;
}

ThreadJiglePoint를 2가지로 구현

jiggle()을 비워두고 배포 환경에서 사용
무작위로 nop, sleep, yield등을 테스트 환경에서 수행

2번 구현으로 테스트를 수천 번 반복하면 스레드 오류가 나타날 지도
단순하나 복잡한 도구 사용이 어렵다면 합리적 대안으로 나쁘지 않음
IBM의 ConTest : 유사 작동하나 좀 더 복잡
코드 흔들기(jiggle)→스레드 다른 순서 실행→ 스레드 오류 드러날 확율 높여줌
권장 사항 : 흔들기 기법을 사용해 오류를 찾아라

결론

다중 스레드 코드는 제대로 작성하기 어렵다
다중 스레드 코드는 엄격한 기준으로 clean하게 작성하라
최우선적으로 SRP를 준수하라 : POJO를 사용 스레드 관련 코드와 非스레드 관련 코드를 분리하라
스레드 관련 코드를 테스트할 때에는 전적으로 스레드 관련 문제만 테스트하라
즉, 스레드 코드는 최대한 집약되고 작아야 한다

동시성 오류를 일으키는 잠정적 원인을 철저이 이해한다

여러 스레드가 공유 자료 조작 or 자원 풀 공유시 동시성 오류 발생
깔끔하게 종료되게 하는 문제나 반복문 탈출과 같은 경계 조건의 경우는 특히 주의
사용하는 라이브러리를 이해하고 기본적인 알고리즘을 이해하라
라이브러리가 제공하는 기능이 어떻게 문제를 해결하는지 이해하라

보호할 코드 영역을 찾는 법, 특정 코드 영역을 잠그는 방법을 이해한다

잠글 필요가 없는 코드는 잠그지 마라
잠긴 영역에서 다른 잠긴 영역 호출 X
그러려면? → 공유하는 정보와 공유하지 않는 정보를 제대로 이해 필요
공유 객체의 갯수와 공유 범위를 최소한으로 줄여라
클라이언트에게 공유 객체의 상태(잠금 등)를 관리하는 책임을 떠넘기지 않는다
필요시 객체 디자인 변경으로 클라이언트에 편의를 제공

스레드 관련 코드는 여러 설정, 환경에서 반복적이고 지속적으로 수행해야 한다

버그를 일회성으로 치부하지 않고 발견해서 고칠 수 있도록

테스트 용이성

TDD 3대규칙을 따르면 자연적으로 얻어짐
좀더 넓은 설정 범위에서 코드를 수행하기 위해 필요한 기능을 제공하는 플러그인 수준을 의미

보조코드 추가

코드를 시간을 들여 instrument하게 되면 오류가 드러날 확률은 크게 높아진다
직접 코드를 작성할 수도 있고 자동화 툴을 사용할 수도 있다
초반부터 보조 코드 고려
스레드 코드는 출시하기 전까지 최대한 오래 테스트 해야할 것
Clean한 접근 방식을 사용한다면, 코드가 올바로 돌아갈 가능성이 극적으로 높아진다

[Clean Code] Ⅻ. 창발성(創發性)

Wed, 09 Feb 2022 00:55:43 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅻ. 창발성(創發性)

비로소 창, 쏠 발, 성품 성
불시에 솟아 나는 특성, emergent property, emergence
단순한 결합이 복잡한 결과를 나타내는 것을 의미
예) 인간의 뇌 : 하나의 뉴런은 인식 능력이 없으나 수십억개가 결합하면 자기 인식 발생
명령을 내리는 조정자 없이 각 부분의 의사소통으로 자기 조직화를 이루게 되고
이러한 밑으로 부터의 힘은 예기치 못한 기능을 발현하는 힘 Ex) 집단 지성
창발적 설계 : 어떤 규칙과 원칙에 따라 설계를 하게 되면, 그것들이 모여 아주 좋은 거시적 설계가 된다는 원리?

창발적 설계로 깔끔한 코드를 구현하자

단순한 설계 규칙 4가지(4 Rules of Simple Design)

켄트백이 90년에 “Extreme Programming Explained”에서 설명
착실하게 따르기만 하면
- 우수한 설계가 나오며
- 코드 구조와 설계 파악이 쉬워지고
- 따라서 SRP, DIP같은 원칙 적용이 쉬워지며
- 우수한 설계의 창발성을 촉진한다
규칙 내용 : 이를 따르면 Design is Simple하다!(..라고 켄트백이 말했다;) 중요도 순서로 나열
1. 모든 테스트를 실행한다
2. 중복을 없앤다
3. 프로그래머 의도를 표현한다
4. 클래스와 메서드 수를 최소로 줄인다

단순한 설계 규칙 1: 모든 테스트를 실행하라

First, 설계는 의도한 대로 돌아가는 시스템을 내놓아야

문서로는 완벽히 설계했지만, 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면?
문서 작성을 위해 투자한 노력에 대한 가치는 인정받기 힘들다.

테스트가 불가능한 시스템은 검증도 불가능

테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 ‘테스트가 가능한 시스템’
테스트가 불가능한 시스템은 검증도 불가능하다
논란의 여지는 있지만, 검증이 불가능한 시스템은 절대 출시하면 안 된다

철저한 테스트가 가능한 시스템 지향 → 더 좋은 설계가 결과로

다행스럽게도, 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다
- 크기가 작고 목적 하나만 수행하는 클래스가 나온다
- SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다
- 테스트를 더 많이 작성하면 할수록 프로그래머가 더 테스트하기 간단하게 코드를 작성할 수 있게 도와준다
따라서 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어진다
자동으로 결합도도 낮아짐
- 결합도가 높으면 테스트 케이스를 작성하기 어렵다. 따라서 지금까지와 마찬가지로
- 테스트 케이스를 많이 작성할수록 개발자는 DIP와 같은 원칙을 적용하고 의존성 주입(Dependency Injection),인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춘다
- 따라서 설계 품질은 더욱 높아진다
결론
- 놀랍게도 “테스트 케이스를 만들고 계속 돌려라”라는 간단하고 단순한 규칙을 따르면
- 시스템은 낮은 결합도와 높은 응집력이라는, 객체 지향 방법론이 지향하는 목표를 저절로 달성한다
- 즉, 테스트 케이스를 작성하면 설계 품질이 높아진다.

단순한 설계 규칙 2~4: 리팩터링

걱정없이 리팩터링~

테스트 케이스를 모두 작성했다면 이제 코드와 클래스를 정리해도 괜찮다
구체적으로는 코드를 점진적으로 리팩터링 해나간다
- 코드 몇 줄을 추가할 때마다 잠시 멈추고 설계를 조감한다
새로 추가하는 코드가 설계 품질을 낮춘다면??
- 깔끔히 정리한 후 테스트를 돌려 기존 기능을 깨뜨리지 않았다는 사실을 확인
코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있으니까!

sw 설계 품질 기법 적용

리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 기법이라면 무엇이든 적용해도 괜찮다
응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 시스템 관심사를 모듈로 나누고, 함수와 클래스 크기를 줄이고, 더 나은 이름을 선택하는 등 다양한 기법을 동원한다
또한 이 단계는 단순한 설계 규칙 중 나머지 3개를 적용해서
- 중복 제거
- 프로그래머 의도 표현
- 클래스 메서드를 최소한으로 줄인다

중복을 없애라

우수한 설계에서 중복은 커다란 적이다
중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻하기 때문
중복은 여러 가지 형태로 표출된다
- 똑같은 코드 → 당연히 중복
- 비슷한 코드 → 더 비슷하게 고쳐주면 리팩터링이 쉬워진다
- 구현 중복도 중복의 한 형태
  집합 클래스에 다음 메서드가 있을 때
  1
  2
  int size() {}
  boolean isEmpty{}
  구현
각 메서드를 따로 구현하는 방법도 있다
하지만 size()가 개수를 반환하는 로직
isEmpty가 이를 이용하면 중복 구현할 필요 없음
1
2
3
boolean isEmpty() {
return 0 == size();
}

깔끔한 시스템을 만들려면 단 몇 줄이라도 중복을 제거하겠다는 의지가 필요하다
다음 코드를 살펴보자.

scaleTOOneDimension 메서드와 rotate 메서드를 살펴보면 일부 코드가 동일

public void scaleToOneDimension(float desiredDimension, float imageDimension) {
  if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
    return;
  float scalingFactor = desiredDimension / imageDimension;
  scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f);
  
  RenderedOp newImage = ImageUtilities.getScaledImage(image, scalingFactor, scalingFactor);
  image.dispose();
  System.gc();
  image = newImage;
}

public synchronized void rotate(int degrees) {
  RenderedOp newImage = ImageUtilities.getRotatedImage(image, degrees);
  image.dispose();
  System.gc();
  image = newImage;
}

중복제거 : 적은 양이지만 공통 코드를 새 메서드로

public void scaleToOneDimension(float desiredDimension, float imageDimension) {
  if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
    return;
  float scalingFactor = desiredDimension / imageDimension;
  scalingFactor = (float) Math.floor(scalingFactor * 10) * 0.01f);
  replaceImage(ImageUtilities.getScaledImage(image, scalingFactor, scalingFactor));
}

public synchronized void rotate(int degrees) {
  replaceImage(ImageUtilities.getRotatedImage(image, degrees));
}

private void replaceImage(RenderedOpnewImage) {
  image.dispose();
  System.gc();
  image = newImage;
}

리팩터링

아주 적은 양이지만 공통적인 코드를 새 메서드로
뽑고 보니 클래스가 SRP를 위반
그러므로 새로 만든 replaceImage 메서드를 다른 클래스로 옮겨도 좋겠다고 한다
그러면 새 메서드의 가시성이 높아진다
따라서 다른 팀원이 새 메서드를 좀 더 추상화해 다른 맥락에서 재사용할 기회를 포착할지도 모른다
이런 ‘소규모 재사용’은 시스템 복잡도를 극적으로 줄여준다
소규모 재사용을 제대로 익혀야 대규모 재사용이 가능하다

템플릿 메서드 패턴 : 고차원 중복을 제거할 목적으로 자주 사용하는 기법

중간의 법정일수 계산을 제외하면 두 메서드는 거의 동일

public class VacationPolicy {
  public void accrueUSDDivisionVacation() {
    // 지금까지 근무한 시간을 바탕으로 휴가 일수를 계산하는 코드
    // ...
    // 휴가 일수가 미국 최소 법정 일수를 만족하는지 확인하는 코드
    // ...
    // 휴가 일수를 급여 대장에 적용하는 코드
    // ...
  }
  
  public void accrueEUDivisionVacation() {
    // 지금까지 근무한 시간을 바탕으로 휴가 일수를 계산하는 코드
    // ...
    // 휴가 일수가 유럽연합 최소 법정 일수를 만족하는지 확인하는 코드
    // ...
    // 휴가 일수를 급여 대장에 적용하는 코드
    // ...
  }
}

템플릿 메서드 패턴 적용

abstract public class VacationPolicy {
  public void accrueVacation() {
    caculateBseVacationHours();
    alterForLegalMinimums();
    applyToPayroll();
  }
  
  private void calculateBaseVacationHours() { /* ... */ };
  abstract protected void alterForLegalMinimums();
  private void applyToPayroll() { /* ... */ };
}

public class USVacationPolicy extends VacationPolicy {
  @Override protected void alterForLegalMinimums() {
    // 미국 최소 법정 일수를 사용한다.
  }
}

public class EUVacationPolicy extends VacationPolicy {
  @Override protected void alterForLegalMinimums() {
    // 유럽연합 최소 법정 일수를 사용한다.
  }
}

하위 클래스는 중복되지 않는 정보만 제공해 accrueVacation 알고리즘에서 빠진 ‘구멍’을 메운다.

표현하라

자신만 이해하는 코드의 문제

아마 우리 대다수는 엉망인 코드를 접한 경험이 있다
아마 우리 대다수는 스스로 엉망인 코드를 내놓은 경험도 있다
자신이 이해하는 코드를 짜기는 쉽다
- 코드를 짜는 동안에는 문제에 푹 빠져 코드를 구석구석 이해하니까
하지만 나중에 코드를 유지보수할 사람이 그만큼 문제를 깊이 이해할 가능성은 희박

코드는 개발자의 의도를 분명히 표현해야 한다

소프트웨어 프로젝트 비용 중 대다수는 장기적인 SM에 들어간다
코드를 변경하면서 버그의 싹을 심지 않으려면 SM 개발자가 시스템을 제대로 이해해야 한다
하지만 시스템이 점차 복잡
- SM 개발자가 시스템 이해하느라 보내는 시간은 점점 늘어남
- 동시에 코드를 오해할 가능성도 점점 커짐
그러므로 코드는 개발자의 의도를 분명히 표현해야 한다
- 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다
- 그래야 결함이 줄어들고 유지보수 비용이 적게 든다.

How?

좋은 이름을 선택

이름과 기능이 완전히 딴판인 클래스나 함수로 개발자를 놀라게 해서는 안 된다

함수와 클래스 크기를 가능한 한 줄인다

작은 클래스와 작은 함수는 이름 짓기도 쉽고, 구현하기도 쉽고, 이해하기도 쉽다

표준 명칭을 사용

예를 들어, 디자인 패턴은 의사소통과 표현력 강화가 주요 목적
class가 COMMAND나 VISITOR등의 표준 패턴을 사용하는 경우 클래스 이름에 패턴 이름을 넣어준다
그러면 다른 개발자가 클래스 설계 의도를 이해하기 쉬워진다.

단위 테스트 케이스를 꼼꼼히 작성

테스트 케이스는 소위 ‘예제로 보여주는 문서’다
다시 말해, 잘 만든 테스트 케이스를 읽어보면 클래스 기능이 한눈에 들어온다

노력과 주의 : 표현력을 높이는 가장 중요한 방법

흔히 코드만 돌린 후 다음 문제로 직행하는 사례가 너무도 흔하다
나중에 읽을 사람을 고려해 조금이라도 읽기 쉽게 만드려는 충분한 고민은 거의 찾기 어렵다
하지만 나중에 코드를 읽을 사람은 바로 자신일 가능성이 높다는 사실을 명심하자
그러므로 자신의 작품을 조금 더 자랑하자
- 함수와 클래스에 조금 더 시간을 투자하자
- 더 나은 이름을 선택
- 큰 함수를 작은 함수 여럿으로 나누고
- 자신의 작품에 조금만 더 주의를 기울이자
- 주의는 대단한 재능이다.

클래스와 메서드 수를 최소로 줄여라

(가능한)최소의 의미

중복을 제거하고, 의도를 표현하고, SRP를 준수한다는 기본적인 개념도 극단으로 치달으면 득보다 실이 많아진다
클래스와 메서드 크기를 줄이자고 조그만 클래스와 메서드를 수없이 만드는 사례도 없지 않다
그래서 이 규칙은 함수와 클래스 수를 가능한 한 줄이라고 제안한다

독단을 멀리하고 실용성 선택

때로는 무의미하고 독단적인 정책 탓에 클래스 수와 메서드 수가 늘어나기도 한다
클래스마다 무조건 인터페이스를 생성하라고 요구하는 구현 표준이 좋은 예
자료 클래스와 동작 클래스는 무조건 분리해야 한다고 주장하는 개발자도 좋은 예
가능한 독단적인 견해는 멀리하고 실용적인 방식을 택해야 한다

해당 규칙의 목표와 우선순위에 대하여

목표는 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는 데 있다
하지만 이 규칙은 간단한 설계 규칙 네 개 중 우선순위가 가장 낮다
다시 말해, 클래스와 함수 수를 줄이는 작업도 중요하지만, 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다는 뜻

결론

경험을 대신할 단순한 개발 기법은 없음
이 책에서 소개하는 기법은 저자들이 수십 년 동안 쌓은 경험의 정수
단순한 설계 규칙을 따른다면 (오랜 경험 후에야 익힐) 우수한 기법과 원칙을 단번에 활용할 수 있다

[Clean Code] Ⅺ. 시스템

Wed, 09 Feb 2022 00:55:08 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅺ. 시스템

도시를 세운다면?

도시를 새로 세운다고 했을 때 혼자서 세부 사항까지 혼자서 관리 가능한가?

불가능, 만들어진 도시의 유지보수도 한 사람은 무리
그래도 도시가 돌아가는 이유?
1. 각 분야를 그리는 팀이 존재 : 수도 관리, 전력 관리, 교통 관리, 치안 관리, 건축물 관리 등
  → 큰 그림을 그리는 사람들도, 작은 사항에 집중하는 사람들도 있음
2. 적절한 추상화와 모듈화
  → 큰 그림을 이해하지 못해도 개인과 개인이 관리하는 ‘구성 요소’는 효율적으로 돌아간다
  SW 팀도 도시와 같다
왜 개발팀의 시스템은 비슷한 수준의 관심사 분리나 추상화를 하지 못할까?
클린코드! → 클린코드를 구현하면 낮은 추상화 수준에서 관심사 분리가 쉬워진다

시스템의 생성과 사용을 분리하라

제작(construction)과 사용(use)은 아주 다르다
- 호텔 예
  - 건축 중엔 기중기와 승강기와 철골들이 붙어 있고 작업복을 착용한 사람들만 존재
  - 건축 후엔 위의 것들이 전부 사라진 예쁜 색상의 벽과 세련된 복장의 호텔리어들만 존재
- 개발도 마찬가지 : 준비 과정과 런타임 로직을 분리해야한다 (관심사 분리)
  - 준비 과정 : 어플리케이션 객체를 제작하고 의존성을 서로 바인드 하는 과정
  - 런타임 과정 : 준비 과정 이후 실제 실행하는 과정
관심사 분리 : 우리 분야에서 가장 오래되고 가장 중요한 설계 기법 중 하나

시작 단계

모든 어플리케이션이 풀어야 하는 관심사(concern)
불행히도 대다수 어플리케이션은 이 시작단계 관심사를 분리하지 않음
준비과정 코드를 주먹구구식으로 구현한채 런타임 로직과 섞여있음

전형적인 주먹구구식 시작단계의 코드


public Service getService() {
    if (service == null)
        service = new MyServiceImpl(...); // Good enough default for most cases?
    return service;
}

Lazy Init

초기화 지연
장점 : 여러가지
- 실제로 필요할 때까지 객체를 생성X → 불필요한 객체 초기화 비용 절약 → 시작 시간 빨라짐
- 어떤 경우에도 null 포인터를 반환하지 않는다
단점
- getService 메서드의 명시적 의존성 : MyServiceImpl, (생략된) 생성자 파라미터
- 런타임 로직에서 MyServiceImpl 객체를 전혀 사용하지 않더라도 의존성을 해결하지 않으면 컴파일이 안됨
- 테스트의 어려움
  - MyServiceImpl이 무거운 객체라면 단위테스트시 테스트 더블이나 mocking 객체로 할당해야 함
  - 객체 생성 로직이 런타임에 섞여있으므로 null일떄와 null이 아닐때등 모든 실행경로 테스트해야 함
  - 책임이 둘 → 메서드가 작업을 2가지 이상 → 작게나마 SRP 위반
- MyServiceImpl이 모든 상황에 적합한 객체인지 모름
  - 가장 큰 문제
  - getService 메서드를 포함하는 클래스가 MyServiceImpl에 대한 전체 문맥을 알 필요가 있나?
  - 현실적으로 한 객체 유형이 모든 문맥에 적합할 가능성이 있는가?
많은 어플리케이션이 이처럼 좀스러운 설정 기법을 수시로 사용하는게 문제
- 한 번 정도였으면 그리 심각한 문제가 아님
- 수시 사용 → 심각
- 전반적 설정 방식이 어플리케이션 곳곳에 흩어짐
- 모듈성 저조, 중복 심각
- 생성/사용의 분산

체계적/탄탄한 시스템을 만들고 싶다면?

좀스럽고 손쉬운 기법으로 모듈성을 깨서는 절대로 안 된다
설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다
주요 의존성을 해소하기 위한 전반적이며 일관적인 방식이 필요

Main 분리

시스템 생성, 시스템 사용을 분리한 한 가지 방법
- 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮긴다
- 나머지 시스템은 모든 객체가 생성되고 모든 의존성이 연결되었다고 가정
제어흐름 따라가기가 쉬움
- main()에서 시스템 필요한 객체 생성한 후 이를 어플리케이션에 넘긴다
- 어플리케이션은 그저 객체를 사용할 뿐
화살표 방향 주목
- 모든 화살표가 main 에서 어플리케이션 방향
- 즉, 어플리케이션은 main이나 객체 생성 과정을 전혀 모른다
- 단지 모든 객체가 적절히 생성되었다고 가정하고 디자인 집중

팩토리 기법

때로는 객체가 생성되는 시점을 어플리케이션에서 결정할 필요가 있음
예시) 주문 처리 시스템에서 어플리케이션은 LineItem 인스턴스를 생성해 Order에 추가
ABSTRACT FACTORY PATTERN 사용
- Factory Method Pattern
  - 조건에 따른 객체 생성을 팩토리 클래스로 위임하여, 팩토리 클래스에서 객체를 생성하는 패턴
- 추상 팩토리 패턴
  - 서로 관련이 있는 객체들을 통째로 묶어서 팩토리 클래스로 만들고, 이들 팩토리를 조건에 따라 생성하도록 다시 팩토리를 만들어서 객체를 생성하는 패턴
LineItem 생성 시점을 어플리케이션이 결정하나 LineItem 생성 코드는 어플리케이션이 알지 못함
여기서도 모든 의존성이 main 에서 OrderProcessing 어플리케이션 방향
- 즉, OrderProcessing 어플리케이션은 LineItem이 생성되는 구체적 방법 모름
- 구체적 방법 : main에 있는 LineItemFactoryImplementation
그럼에도
- OrderProcessing 어플리케이션은 LineItem 인스턴스가 생성되는 시점을 완벽하게 통제한다
- 필요시 OrderProcessing 어플리케이션에서만 사용하는 생성자 인수도 넘길 수 있음

의존성 주입(Dependency Injection)

사용과 제작을 분리하는 강력한 매커니즘의 하나
DI: 제어 역전(IoC) 기법을 의존성 관리에 적용한 매커니즘
IoC
- 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘김
- 새로운 객체는 남겨받은 책임만 맡음 → SRP 지킴
- 객체는 의존성 자체를 인스턴스로 만드는 책임은 지지 않는다 : 의존성 관리 맥락
- 그럼 의존성 차체를 인스턴스로 만드는 책임은? → 다른 전담 매커니즘에 넘긴다 → 제어 역전
- 초기 설정은 시스템 전체에서 필요 → 책임질 매커니즘으로 main이나 특수 컨테이너 사용
JNDI 검색 : DI ‘부분적’ 구현 예시
1
MyService myService = (MyService)(jndiContext.lookup(“NameOfMyService”));
- 객체는 디렉터리 서버에 이름을 제공하고 그 이름과 일치하는 서비스를 요청
- 호츨하는 객체는 (반환 객체가 적절한 인터페이스를 구현하는 한) 반환 객체 유형 제어 안함
- 호출하는 객체는 의존성을 능동적으로 해결 - 절반의 DI
진정한 DI : 한걸음 더 나아감 → 클래스가 의존성을 해결하려 시도하지 않는다
- 클래스 : 완전 수동적
- 의존성을 주입하는 방법 : setter, 생성자 인수 (혹은 둘 다 가능)
- DI Container
  - (대개 요청이 들어올 떄마다)필요한 객체의 인스턴스 생성후 위에서 말한 주입 방법의 메서드로 의존성 설정
  - 실제 생성되는 객체 유형 : 설정파일에서 지정하거나 특수 생성 모듈에서 코드로 명시
  - 스프링: 가장 널리 알려진 DI 컨테이너 제공
DI와 초기화 지연
- DI를 사용해도 때로 초기화 지연이 유용하다
- 많은 DI 컨테이너는 필요할 때까지 객체 생성 X, 계산지연이나 비슷한 최적화 활용한 방법 제공
- 팩토리 호출이라던지, 프록시를 생성하는 방법을 제공한다던지

확장 (scaling)

촌락은 마을로, 마을은 도시로 성장한다
그러면서 전력, 상수도, 인터넷 등의 서비스도 생겨난다
성장의 고통
- 꽉 막힌 도로에서 왜 처음부터 넓게 만들지 않았는가 불평
- 하지만 누가 마을의 성장을 고려해 미리 6차선 고속도로를 지으려 할까?
처음부터 시스템을 제대로 제대로 만든다는 것은 미신일 뿐이다.
- 우리는 오늘 필요한 것을 주어진 요청사항과 사용자 스토리에 맞춰 구현할 뿐이다
- 내일은 내일 주어질 새로운 스토리에 맞춰 시스템을 조정/확장하면 된다
- 이것이 Agile의 핵심 : 반복적, 점진적

시스템 수준의 아키텍처

코드레벨의 시스템 조정/확장 쉽게? TDD, Refactoring, 그리고 이 둘의 산물인 clean Code가 역할
시스템 수준에서는?
단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 수 없다는 현실?
- sw 시스템은 물리적 시스템과 다르다
- Concern들을 적절히 분리할 수 있다면, sw 시스템은 물리적인 시스템과는 다르게 점진적으로 커질 수 있다.

Concern들을 적절히 분리하지 못하는 아키텍처 예 : EJB1, EJB2

클라이언트가 사용할 (프로세스 내)의 지역 인터페이스나 (다른 JVM)의 원격 인터페이스 정의 필요

BANK EJB 지역 인터페이스

package com.example.banking;
import java.util.Collections;
import javax.ejb.*;
// 열거 속성: 은행 주소, 은행이 소유하는 계좌
// 각 계좌 정보는 Account EJB로 처리
public interface BankLocal extends java.ejb.EJBLocalObject {
    String getStreetAddr1() throws EJBException;
    String getStreetAddr2() throws EJBException;
    String getCity() throws EJBException;
    String getState() throws EJBException;
    String getZipCode() throws EJBException;
    void setStreetAddr1(String street1) throws EJBException;
    void setStreetAddr2(String street2) throws EJBException;
    void setCity(String city) throws EJBException;
    void setState(String state) throws EJBException;
    void setZipCode(String zip) throws EJBException;
    Collection getAccounts() throws EJBException;
    void setAccounts(Collection accounts) throws EJBException;
    void addAccount(AccountDTO accountDTO) throws EJBException;
}

상응하는 EJB2 엔티티빈 구현

// 위 소스의 인터페이스를 구현한 BANK bean 구현 클래스

package com.example.banking;
import java.util.Collections;
import javax.ejb.*;

public abstract class Bank implements javax.ejb.EntityBean {
    // 비지니스 로직
    public abstract String getStreetAddr1();
    public abstract String getStreetAddr2();
    public abstract String getCity();
    public abstract String getState();
    public abstract String getZipCode();
    public abstract void setStreetAddr1(String street1);
    public abstract void setStreetAddr2(String street2);
    public abstract void setCity(String city);
    public abstract void setState(String state);
    public abstract void setZipCode(String zip);
    public abstract Collection getAccounts();
    public abstract void setAccounts(Collection accounts);
    
    public void addAccount(AccountDTO accountDTO) {
        InitialContext context = new InitialContext();
        AccountHomeLocal accountHome = context.lookup("AccountHomeLocal");
        AccountLocal account = accountHome.create(accountDTO);
        Collection accounts = getAccounts();
        accounts.add(account);
    }
    
    // EJB 컨테이너 로직
    public abstract void setId(Integer id);
    public abstract Integer getId();
    public Integer ejbCreate(Integer id) { ... }
    public void ejbPostCreate(Integer id) { ... }
    
    // 나머지도 구현해야 하지만 일반적으로 이렇게 비어있다.
    public void setEntityContext(EntityContext ctx) {}
    public void unsetEntityContext() {}
    public void ejbActivate() {}
    public void ejbPassivate() {}
    public void ejbLoad() {}
    public void ejbStore() {}
    public void ejbRemove() {}
}

특징

객체 생성 팩토리인 LocalHome 인터페이스 : 생략
기타 BANK의 탐색(query) 메서드 : 생략
마지막으로 XML deployment descriptors 작성 필요
- 영구 저장소에서 객체와 관계형 자료가 매핑되는 방식
- 원하는 트랜잭션 동작 방식
- 보안 제약 조건등
비지니스 논리가 EJB2 어플리케이션 ‘컨테이너’에 강하게 결합됨
- 클래스 생성시 컨테이너에서 subclass해야 한다
- 컨테이너가 요구하는 다양한 lifecycle 메서드 구현해야 함
so?
- 독자적 단위 테스트 어려움
  - 많은 시간을 낭비하며 EJB와 테스트를 실제 서버에 배치해야함
  - 컨테이너 흉내도 쉽지 않음
  - EJB2 코드는 프레임워크 밖에서 재사용이 사실상 불가능
OOP라는 개념조차 뿌리가 흔들림
상속 불가능
쓸데 없는 DTO 작성 요구

Cross-Cutting Concerns(횡단 관심 분야)

보안, 영속성등의 concern: 어플리케이션의 자연스러운 객체 경계를 넘나드는 특성

EJB2 아키텍처는 소스 코드가 아니라 배치 기술자에 해당 부분 정의 → 사실상 AOP 예견
모든 객체가 전반적으로 동일한 방식을 이용하게 만들어야 한다
원론적으로는 모듈화/캡슐화된 방식으로 영속성 방식 구상
현실적으로는 온갖 객체로 흩어지게된다.

횡단 관심사

영속성 프레임워크, 도메인 논리 모듈화 가능하지만 두 영역이 세밀하게 겹친다

AOP

aspect-oriented programming
트랜잭션, 로깅등의 횡단 관심사의 모듈성을 되살림
“코드의 어떤 부분에 어떤 추가적 기능을 삽입할까?” → 해당 정의를 aspect로 제공
Aspect라는 모듈 구성 개념
- “특정 관심사 지원을 위해선 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야 한다”라고 명시

자바에서 사용하는 관점 혹은 유사한 매커니즘 3가지

자바 프록시

단순 상황 적합, 좋은 예시 : 개별 객체, 클래스에서 메서드 호출 wraaping하는 경우
JDK의 Dynamic Proxy는 인터페이스만 지원
- class 프록시 사용하려면 bytecode 처리 라이브러리 필요 : CGLIB, ASM, Javassist등

JDK 프록시를 사용해서 영속성을 지원하는 예제

// Bank.java (패키지 이름을 감춘다)
import java.utils.*;

// 은행 추상화
public interface Bank {
    Collection getAccounts();
    void setAccounts(Collection accounts);
}

// BankImpl.java
import java.utils.*;

// 추상화를 위한 POJO 구현
public class BankImpl implements Bank {
    private List accounts;

    public Collection getAccounts() {
        return accounts;
    }
    
    public void setAccounts(Collection accounts) {
        this.accounts = new ArrayList();
        for (Account account: accounts) {
            this.accounts.add(account);
        }
    }
}
// BankProxyHandler.java
import java.lang.reflect.*;
import java.util.*;

// “InvocationHandler” required by the proxy API.
public class BankProxyHandler implements InvocationHandler {
    private Bank bank;
    
    public BankProxyHandler(Bank bank) {
        this.bank = bank;
    }
    
    // InvocationHandler 내부 정의 메서드 
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        String methodName = method.getName();
        if (methodName.equals("getAccounts")) {
            bank.setAccounts(getAccountsFromDatabase());
            
            return bank.getAccounts();
        } else if (methodName.equals("setAccounts")) {
            bank.setAccounts((Collection) args[0]);
            setAccountsToDatabase(bank.getAccounts());
            
            return null;
        } else {
            ...
        }
    }
    
    // 세부사항..
    protected Collection getAccountsFromDatabase() { ... }
    protected void setAccountsToDatabase(Collection accounts) { ... }
}

// 다른 곳에 위치하는 코드
Bank bank = (Bank) Proxy.newProxyInstance(
    Bank.class.getClassLoader(),
    new Class[] { Bank.class },
    new BankProxyHandler(new BankImpl())
);

설명

리플렉션 API 사용
- 직접 다이나믹 프록시 구현시 인터페이스 구현을 해야하고 프록시 클래스 내부에 중복 발생
- 첫 번째 인자: 프록시를 만들 클래스 로더
- 두 번째 인자: 어떤 인터페이스에 대해 프록시를 만들 것인지 명시
- 세 번째 인자: InvocationHandler 인터페이스의 구현체
- 리턴 값: 동적으로 만든 프록시 객체
Java Proxy API를 위한 Bank 인터페이스를 작성한다.
위에서 작성한 Bank 인터페이스를 사용한 BankImpl(POJO aka Plane Old Java Object)를 구현한다.
- 여기에는 순수한 데이터만 들어가며 비지니스 로직은 포함되지 않는다.(모델과 로직의 분리)
InvocationHandler를 구현하는 BankProxyHandler를 작성한다.
- 이 핸들러는 Java Reflection API를 이용해 Bank 인터페이스를 구현하는
  객체들의 메서드콜을 가로챌 수 있으며 추가적인 로직을 삽입할 수 있다.
- 본 예제에서 비지니스 로직(persistant stack logic)은 이 곳에 들어간다.
마지막으로 코드의 마지막 블럭과 같이 BankImpl 객체를 BankProxyHandler에 할당한다
- Bank 인터페이스를 사용해 프록시된 인터페이스를 사용해 모델과 로직이 분리된 코드를 작성가능
- 이로써 모델과 로직의 분리를 이뤄낸 코드를 작성할 수 있게 되었다.

단점 : 코드의 양과 크기 → 클린 코드 작성하기 어렵다

단순 예제인데도 코드가 상당히 많으며 복잡하다
바이트 조작 라이브러리 사용해도 어렵
프록시는 (진정한 AOP해법에 필요한) 시스템 단위로 실행’지점’을 명시하는 매커니즘도 제공 X

순수 자바 AOP 프레임워크

대두분의 프록시 코드 → 틀에 박힌 판박이 → 도구로 자동화 가능
Spring AOP, JBoss AOP등 → 내부적으로는 프록시 사용
스프링 : 비지니스 논리를 POJO로 구현
- POJO
  - 순수하게 도메인 초점
  - 프레임워크나 다른 도메인에도 의존하지 않음 → 테스트가 더 쉽고 간단
  - 상대적 단순 → 사용자 스토리를 올바로 구현 쉬움 → 유지보수도 좋음
어플리케이션 기반 구조 : 프로그래머가 설정파일이나 API 사용
- 영속성, 트랜잭션, 보안, 캐시, 장애조치등의 횡단 관심사
- 사용자가 모르게 프록시나 bytecode 라이브러리로 구현

전형적인 스프링 2.x 설정 파일


    ...
    "appDataSource"
        class="org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close"
        p:driverClassName="com.mysql.jdbc.Driver"
        p:url="jdbc:mysql://localhost:3306/mydb"
        p:username="me"/>
    
    "bankDataAccessObject"
        class="com.example.banking.persistence.BankDataAccessObject"
        p:dataSource-ref="appDataSource"/>
    
    "bank"
        class="com.example.banking.model.Bank"
        p:dataAccessObject-ref="bankDataAccessObject"/>
    ...

Bank 도메인 객체는 BankDataAccessObject(DAO)로 프록시
DAO(자료 접근자 객체)는 JDBC 드라이버 자료 소스로 프록시
클라이언트는 Bank 객체의 getAccount()에 접근하고 있다고 생각하지만
Bank POJO 기본 동작을 확장한 중첩 decorator 객체 집합의 가장 외각과 통신

필요시 트랜잭션, 캐싱등에 데코레이터 추가 가능

실제 BANK 객체 요청 코드

1 2	XmlBeanFactory bf = new XmlBeanFactory(new ClassPathResource("app.xml", getClass())); Bank bank = (Bank) bf.getBean("bank");

스프링 관련 자바 코드 거의 없음 → 사실상 스프링과 독립적 → EJB2의 tight-coupling 해결
XML : 장황, 읽기 어려움 → 그럼에도 정책이 겉으로 보이지 않게 자동 생서된 프록시, 관점 논리보다는 단순
이런 매력적인 아키텍처 → EJB3를 완전히 뜯어 고치게 됨

EJB3 : 스프링 모델 따라한다 (XML 설정파일, 자바 어노테이션 사용)

EJB3 Bank EJB

/* Code 3-4(Listing 11-5): An EBJ3 Bank EJB */

package com.example.banking.model;

import javax.persistence.*;
import java.util.ArrayList;
import java.util.Collection;

@Entity
@Table(name = "BANKS")
public class Bank implements java.io.Serializable {
    @Id @GeneratedValue(strategy=GenerationType.AUTO)
    private int id;
    
    @Embeddable // An object “inlined” in Bank’s DB row
    public class Address {
        protected String streetAddr1;
        protected String streetAddr2;
        protected String city;
        protected String state;
        protected String zipCode;
    }
    
    @Embedded
    private Address address;
    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy="bank")
    private Collection accounts = new ArrayList();
    public int getId() {
        return id;
    }
    
    public void setId(int id) {
        this.id = id;
    }
    
    public void addAccount(Account account) {
        account.setBank(this);
        accounts.add(account);
    }
    
    public Collection getAccounts() {
        return accounts;
    }
    
    public void setAccounts(Collection accounts) {
        this.accounts = accounts;
    }
}

설명

깔끔한 코드 → 테스트하고 유지 보수가 쉬어짐
일부 어노테이션의 영속성 정보 존재
- 필요하면 XML 기술자로 옮겨도 된다
- 그러면 진짜 순수 POJO만 남는다

AspectJ 관점

분심사를 관점으로 분리하는 가장 강력한 도구 : AspectJ
언어 차원에서 관점 모듈화 구성 지원하는 자바 언어 확장
스프링AOP, JBoss AOP의 순수 자바 방식은 관점 필요한 상황의 80-90% 충분
장점 : 강력한 기능
단점 : 새 도구 사용, 새 언어 문법, 새로운 사용법
‘애너테이션 폼’ : 자바5 애너테이션 사용 관점 정의
스프링을 사용 : AspectJ에 미숙한 팀이 애너테이션 기반 관점 쉽게 사용하도록 지원

테스트 주도 시스템 아키텍처 구축(Test Drive the System Architecture)

횡단 관심사 분리 방식의 위력:
→ 어플리케이션 도메인의 논리를 POJO로 작성 가능
→ 코드 수준에서 아키텍처 관심사 분리 가능
→ 진정한 테스트 주도 아키텍처 구축 가능
→ 필요시 새로운 기술을 채택히 단순 아키텍처를 복잡한 아키텍처로 키우는게 가능
→ BDUF(구현 시작전에 앞으로 벌어질 모든 사항을 설계하는 기법)을 추구할 필요가 없음

디테일 말고 전체 시스템은 한번에 설계가 되어야 한다고 추구하는 기법의 반대
BDUF는 심지어 해롭다
- 처음에 쏟아 부은 노력을 버리지 않으려는 심리적 저항
- 처음 아키텍처가 향후 사고방식에 미치는 영향 → 변경을 쉽사리 수용 못함

건축과 다르다

건축가는 BDUF : 일단 지으면 극적인 변화가 불가능
SW도 나름 형체가 존재는 한다(Software physics)
하지만 sw구조가 관점을 효과적으로 분리한다면, 극적인 변화가 경제적으로 가능
‘아주 단순한’ 아키텍처로 진행한 후 조금씩 확장이 가능하다는 이야기
그렇다고 ‘아무 방향없이’ 프로젝트 뛰어들면 되는게 아님
- 프로젝트 시작시 일반적인 범위, 목표, 일정, 결과 시스템의 일반적 구조도 고려해야 함
- 하지만 변하는 환경 대처하여 진로를 변경할 능력도 반드시 유지 필요

과유 불급

초창기 EJB : 기술을 너무 많이 넣음 → 관심사 제대로 분리 X
아주 멋진 설계의 API도 정말 필요하지 않으면 과유불급
좋은 API는 걸리적 거리지 않는다
→ 그래야 팀이 창의적 노력을 사용자 스토리에 집중
→ 그렇지 않으면 아키텍처에 발이 묶임 → 고객에게 최적의 가치를 효율적으로 제공 X

최선의 시스템 아키텍처는 각각 POJO 객체로 구현되는 모듈화된 관심사 영역(modularized domains of concern)(도메인)으로 구성된다. 이렇게 서로 다른 영역은 영역 코드 간섭을 최소화하는 Aspect나 유사 도구를 사용해 통합한다. 이러한 아키텍쳐는 코드와 마찬가지로 test-driven될 수 있다.

의사 결정을 최적화하라

도시든 sw시스템이든 아주 큰 시스템에서는 한 사람이 모든 결정을 내리기 어렵다
모듈화, 관심사 분리 → 지엽적 관리/결정 가능
가장 적합한 사람에게 책임을 맡겨라
때때로 가능한 한 마지막 순간까지 결정을 미루는 방법이 최선
- 게으르거나 무책임해서가 아님
- 최대한 정보를 모아 최선의 결정을 내리기 위해서
- 성급한 결정 → 불충분한 지식을 기반으로 내린 결정
- 너무 이른 결정 → 국민 피드백 더 모으고, 프로젝트를 더 고민하고, 구현 방안을 더 탐험할 기회가 사라짐

관심사를 모듈로 분리한 POJO 시스템은 기민함을 제공
이런 기민함(민첩성)은 가장 최신의 정보에 기반하여 최선의 시점에 최적의 결정을 내리기 쉽게 해줌
결정에 필요한 복잡도 또한 경감

명백한 가치가 있을 떄 표준을 현명하게 사용하라

현대 건축현장 : 엄청난 설계, 엄청난 속도, 엄청난 최적화된 표준
EJB2의 사례

단지 표준이라는 이유만으로 많은 팀이 사용
가볍고 간단한 설계로 충분한 프로젝트도 EJB2 사용
과장되게 포장된 표준에 집착하여 고객 가치가 뒷전으로 밀려난 사례
“고객을 위한 가치 창출”이라는 목표를 표준에 심취해 잃어버림

표준은 아이디어와 컴포넌트의 재사용, 관련 전문가 채용, 좋은 아이디어의 캡슐화, 컴포넌트들의 연결을 쉽게 도와 준다. 하지만 때로는 표준을 만드는 데에 드는 시간이 너무 오래 걸려 납품 기한을 맞추기 어렵게 만들고, 혹은 어떤 표준은 최초에 제공하려던 목적과 가치를 제공하지 못한 표준도 있다

시스템에는 DSL(도메인 영역 언어)이 필요하다

DSL

간단한 스크립트 언어나 표준 언어로 구현한 API
DSL 코드는 도메인 전문가가 작성한 구조적인 산문처럼 읽힌다
의사소통 간극을 줄인다
- 좋은 DSL은 도메인 개념과 그 개념을 구현한 코드 사이에 존재하는 ‘의사 소통 간극’을 줄인다
- Agile 기법이 팀과 프로젝트 이해 관계자 사이의 소통 간극을 줄이듯이
- 모메인 전문가가 사용하는 언오로 도메인 논리 구현 → 도메인 잘못 구현할 가능성 감소
효과적으로 사용한다면?
- 추상화 수준을 코드 관용구나 디자인 패턴으로 올릴 수 있음
- 개발자가 적절한 추상화 수준에서 코드 의도를 표현 가능해짐

DSL을 사용시 코차원 정책부터 저차원의 세부사항까지 모든 추상화 수준과 모든 도메인을 POJO로 표현 가능

결론

(코드뿐만이 아니라) 시스템 역시 깨끗해야 한다
클린하지 못한 침략적인(invasive) 아키텍쳐는 도메인 논리를 흐리며 기민성을 떨어뜨림
도메인 논리 흐려지면 ? 제품 품질이 떨어지고, 버그는 숨기 쉬워지고 기능 구현은 어려워 진다
기민성이 떨어지면 침해되면 생산성이 저해되고 TDD가 제공하는 장점이 사라짐
모든 추상화 단계에서 의도는 명확히 표현해야 한다 그러려면
- POJO를 작성하고
- aspect나 유사한 매커니즘을 사용해 각 구현 관심사를 분리해야 한다
시스템을 설계하든, 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다

[Clean Code] Ⅹ. 클래스

Wed, 09 Feb 2022 00:54:31 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅹ. 클래스

앞서 코드 행과 코드 블록을 올바로 작성하는 방법, 함수를 올바로 구현하는 방법과 함수가 서로 관련을 맺는 방법 공부
위의 내용과 더불어 더 높은 단계까지 신경을 써야만 깨끗한 코드를 얻을 수 있음

클래스 체계

표준 자바 관례

가장 먼저 변수 목록
- static, public 상수가 있을 경우 맨 처음에 나온다
- 그다음 정적 비공개, 이어서 비공개 인스턴스 변수
- (공개 변수가 필요한 경우는 거의 없음)
공개 함수
비공개 함수
왜 이렇게 ?
- 가독성 좋게
- 추상화 단계가 순차적으로 내려간다
- 프로그램은 신문 기사처럼 읽힌다

캡슐화

변수/유틸리티

변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 하는 것은 아니다.
protected로 선언해서 접근을 허용하기도 한다.
- 예) 테스트
- 우리에게 테스트는 중요하다
- 같은 패키지안에서 테스트 코드가 함수 호출하거나 변수를 사용시
- 해당 함수나 변수를 protected로 선언하거나 패키지 전체로 공개
캡슐화를 풀어주는 결정은 언제나 최후의 수단 : 비공개 상태를 유지할 온갖 방법을 강구

클래스는 작아야 한다

함수장에서 했던 이야기의 되풀이가 아님 : 함수와 마찬가지로 “작게”가 기본 규칙이라는 의미

얼마나 작아야 하나?

너무 많은 책임

// 어마어마하게 큰 슈퍼 만능 클래스

public class SuperDashboard extends JFrame implements MetaDataUser {
  public String getCustomizerLanguagePath()
  public void setSystemConfigPath(String systemConfigPath) 
  public String getSystemConfigDocument()
  public void setSystemConfigDocument(String systemConfigDocument) 
  public boolean getGuruState()
  public boolean getNoviceState()
  public boolean getOpenSourceState()
  public void showObject(MetaObject object) 
  public void showProgress(String s)
  public boolean isMetadataDirty()
  public void setIsMetadataDirty(boolean isMetadataDirty)
  public Component getLastFocusedComponent()
  public void setLastFocused(Component lastFocused)
  public void setMouseSelectState(boolean isMouseSelected) 
  public boolean isMouseSelected()
  public LanguageManager getLanguageManager()
  public Project getProject()
  public Project getFirstProject()
  public Project getLastProject()
  public String getNewProjectName()
  public void setComponentSizes(Dimension dim)
  public String getCurrentDir()
  public void setCurrentDir(String newDir)
  public void updateStatus(int dotPos, int markPos)
  public Class[] getDataBaseClasses()
  public MetadataFeeder getMetadataFeeder()
  public void addProject(Project project)
  public boolean setCurrentProject(Project project)
  public boolean removeProject(Project project)
  public MetaProjectHeader getProgramMetadata()
  public void resetDashboard()
  public Project loadProject(String fileName, String projectName)
  public void setCanSaveMetadata(boolean canSave)
  public MetaObject getSelectedObject()
  public void deselectObjects()
  public void setProject(Project project)
  public void editorAction(String actionName, ActionEvent event) 
  public void setMode(int mode)
  public FileManager getFileManager()
  public void setFileManager(FileManager fileManager)
  public ConfigManager getConfigManager()
  public void setConfigManager(ConfigManager configManager) 
  public ClassLoader getClassLoader()
  public void setClassLoader(ClassLoader classLoader)
  public Properties getProps()
  public String getUserHome()
  public String getBaseDir()
  public int getMajorVersionNumber()
  public int getMinorVersionNumber()
  public int getBuildNumber()
  public MetaObject pasting(MetaObject target, MetaObject pasted, MetaProject project)
  public void processMenuItems(MetaObject metaObject)
  public void processMenuSeparators(MetaObject metaObject) 
  public void processTabPages(MetaObject metaObject)
  public void processPlacement(MetaObject object)
  public void processCreateLayout(MetaObject object)
  public void updateDisplayLayer(MetaObject object, int layerIndex) 
  public void propertyEditedRepaint(MetaObject object)
  public void processDeleteObject(MetaObject object)
  public boolean getAttachedToDesigner()
  public void processProjectChangedState(boolean hasProjectChanged) 
  public void processObjectNameChanged(MetaObject object)
  public void runProject()
  public void setAçowDragging(boolean allowDragging) 
  public boolean allowDragging()
  public boolean isCustomizing()
  public void setTitle(String title)
  public IdeMenuBar getIdeMenuBar()
  public void showHelper(MetaObject metaObject, String propertyName) 
  
  // ... 많은 비공개 메서드가 계속 이어짐...
}

메서드가 5개라면?

// 메서드 수가 작아도 책임이 너무 많다
public class SuperDashboard extends JFrame implements MetaDataUser {
  public Component getLastFocusedComponent()
  public void setLastFocused(Component lastFocused)
  public int getMajorVersionNumber()
  public int getMinorVersionNumber()
  public int getBuildNumber() 
}

클래스 이름은 해당 클래스 책임을 기술해야

작명은 클래스 크기를 줄이는 첫번째 관문
간결한 이름이 떠오르지 않는다면? 클래스 책임이 너무 많아서!
클래스 이름에 Manager, Processor, Super등 모호한 단어(ch2언급)가 있다면 여러 책임을 떠안긴 것
클래스 설명은 “if”, “and”, “or”, “but”을 사용하지 않고 25 단어 내외로 가능해야
위의 SuperDashboard를 설명하면?
- “SuperDashboard는 마지막으로 포커스를 얻었던 컴포넌트에 접근하는 방법을 제공하며, 버전과 빌드 번호를 추적하는 메커니즘을 제공한다.”
- 첫 번쨰 “~하며,”는 SuperDashboard에 책임이 너무 많다는 증거

단일 책임 원칙

자세한 것은 클린 소프트웨어 참조
SRP

클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙
“책임”이라는 개념 정의, 적절한 클래스 크기 제시

위 5가지 메서드의 SuperDashboard는?

sw 버전 정보를 추적 : sw 출시 때마다 달라짐
자바 스윙 컴포넌트 관리

최상위 GUI 윈도우 스윙 표현인 JFrame에서 파생한 클래스이므로
스윙 코드를 변경할 떄마다 버전 번호가 달라짐
역은 false : 때로는 다른 코드를 바꾸고 나서도 버전 번호를 바꾼다

책임 = 변경할 이유

이를 파악하려 애쓰면 코드 추상화가 쉬어진다

위에서 버전 정보를 다루는 메서드들을 빼내서 독자적인 클래스를 만든다면

단일 책임 클래스

//다른 어플리케이션에서 재사용하기 아주 쉬운 구조!
public class Version {
  public int getMajorVersionNumber() 
  public int getMinorVersionNumber() 
  public int getBuildNumber()
}

SRP = 중요하고 이해하고 지키기 쉽지만 설계자가 잘 어기는 규칙 중 하나.. 어째서?

sw를 돌아가게 만드는 활동(구현 개발)과 sw를 깨끗하게 만드는 활동(클린 코드)은 별개
두뇌 용량의 한계로 클린 코딩 보다는 구현 개발에 초점
- 올바른 태도
- 관심사를 분리하는 작업은 프로그램뿐 아닌 프로그래밍 활동에서도 마찬가지로 중요
문제는?
1. 프로그램이 돌아가면 일이 끝났다고 여김
- 구현 개발의 관심사 종료시 ‘깨끗하고 체계적인 sw(클린 코드)’라는 다음 관심사로 전환하지 않음
- 구현된 만능 클래스를 단일 책임 클래스 여럿으로 분리하는 대신 다음 이슈처리해버림
1. 클래스가 많아지면 큰 그림 이해 못한다고 우려
- 자잘한 SRP 클래스가 많아지면 큰 그림 이해를 위해 여러 클래스를 수없이 넘나들어야 한다며 걱정
양은 비슷하다
- 작은 클래스가 많은 시스템에든, 큰 클래스가 몇개 뿐인 시스템이든 들어가는 부품은 그 수가 비슷함
- 어느 시스템이든 익힐 내용은 그 양이 비슷
따라서 고민할 질문은 도구상자를 어떻게 관리하고 싶은가? 이다
- 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가?
- 큰 서러 몇개에 모두를 던져 넣고 싶은가?
기본 규모가 어느정도에 이르는 시스템은 논리가 많고도 복잡하다
복잡성을 다룰려면 체계적인 정리가 필수
그래야 개발자가 어디에 무엇이 있는지 쉽게 찾을 수 있음
그래야 (변경시)직접 영향이 미치는 컴포넌트만 이해해도 충분
그렇지 않은 다목적 클래스 몇 개로 구성된 시스템은 (변경시) 당장 알 필요가 없는 부분까지 보여 독자 방해
작은 클래스 여럿으로 이뤄진 시스템이 바람직함
작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

응집도(Cohesion)

클래스는 인스턴스 변수 수가 작아야 한다.
각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
일반적으로 메서드가 변수를 더 많이 사용할 수록 메서드와 클래스는 응집도가 더 높다.
모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높지만, 이런 클래스는 가능하지도, 바람직하지도 않다.
하지만 가능한한 응집도가 높은 클래스를 지향해야 한다.
응집도가 높다 = 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미

응집도가 높은 Stack 구현 코드

//size를 제외한 두 메서드는 두 변수 모두 사용
public class Stack {
  private int topOfStack = 0;
  List elements = new LinkedList();

  public int size() { 
    return topOfStack;
  }

  public void push(int element) { 
    topOfStack++; 
    elements.add(element);
  }
  
  public int pop() throws PoppedWhenEmpty { 
    if (topOfStack == 0)
      throw new PoppedWhenEmpty();
    int element = elements.get(--topOfStack); 
    elements.remove(topOfStack);
    return element;
  }
}

함수를 작게, 매개변수 목록을 짧게라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아지는 케이스 발생
→ 이는 십중 팔구 새로운 클래스를 쪼개야 한다는 신호
→ 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼갠다

응집도를 유지하면 작은 클래스 여럿이 나온다

큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다
예)변수가 아주 많은 큰 함수

큰 함수 일부를 작은 함수로 extract하려 함
빼내려는 코드가 큰 함수에 정의 된 변수를 많이 사용한다
그러면 변수들을 새 함수에 인수로 넘겨야 하나?
답은? 전혀 아니다
- 변수들을 클래스 인스턴스 변수로 승격 시키면 인수가 필요없음
- 불행히 응집력이 낮아짐 : 몇몇 함수만 사용하는 인스턴스 변수가 점점 더 늘어나므로
- 몇몇 함수가 몇몇 인스턴스 변수만 사용하게되면? 독자적인 클래스로 쪼개라!!

결론 : 큰 함수 작은 함수로 스플릿 → 종종 작은 클래스 여럿으로 쪼갤 기회 → 프로그램의 체계가 잡히고 구조가 투명해짐

예시) 커누스 교수가 쓴 문학적 프로그래밍(Literate Programming)에 나오는 유서 깊은 예제

커누스 교수의 PrintPrimes를 자바로 변환한 코드
그가 직접 짠 포르그램이 아닌 웹도구로 출력한 결과

PrintPrimes.java

package literatePrimes;

public class PrintPrimes {
  public static void main(String[] args) {
    final int M = 1000; 
    final int RR = 50;
    final int CC = 4;
    final int WW = 10;
    final int ORDMAX = 30; 
    int P[] = new int[M + 1]; 
    int PAGENUMBER;
    int PAGEOFFSET; 
    int ROWOFFSET; 
    int C;
    int J;
    int K;
    boolean JPRIME;
    int ORD;
    int SQUARE;
    int N;
    int MULT[] = new int[ORDMAX + 1];
    
    J = 1;
    K = 1; 
    P[1] = 2; 
    ORD = 2; 
    SQUARE = 9;
  
    while (K < M) { 
      do {
        J = J + 2;
        if (J == SQUARE) {
          ORD = ORD + 1;
          SQUARE = P[ORD] * P[ORD]; 
          MULT[ORD - 1] = J;
        }
        N = 2;
        JPRIME = true;
        while (N < ORD && JPRIME) {
          while (MULT[N] < J)
            MULT[N] = MULT[N] + P[N] + P[N];
          if (MULT[N] == J) 
            JPRIME = false;
          N = N + 1; 
        }
      } while (!JPRIME); 
      K = K + 1;
      P[K] = J;
    } 
    {
      PAGENUMBER = 1; 
      PAGEOFFSET = 1;
      while (PAGEOFFSET <= M) {
        System.out.println("The First " + M + " Prime Numbers --- Page " + PAGENUMBER);
        System.out.println("");
        for (ROWOFFSET = PAGEOFFSET; ROWOFFSET < PAGEOFFSET + RR; ROWOFFSET++) {
          for (C = 0; C < CC;C++)
            if (ROWOFFSET + C * RR <= M)
              System.out.format("%10d", P[ROWOFFSET + C * RR]); 
          System.out.println("");
        }
        System.out.println("\f"); PAGENUMBER = PAGENUMBER + 1; PAGEOFFSET = PAGEOFFSET + RR * CC;
      }
    }
  }
}

엉망징창 프로그램

심한 들여쓰기
많은 이상한 변수
빡빡히 결합된 구조

작은 함수와 클래스로 나누고 함수와 클래스와 변수에 좀더 의미있는 이름을 부여하며 리팩터링을 해보자

PrimePrinter.java (리팩터링 버전)

package literatePrimes;

public class PrimePrinter {
  public static void main(String[] args) {
    final int NUMBER_OF_PRIMES = 1000;
    int[] primes = PrimeGenerator.generate(NUMBER_OF_PRIMES);
    
    final int ROWS_PER_PAGE = 50; 
    final int COLUMNS_PER_PAGE = 4; 
    RowColumnPagePrinter tablePrinter = 
      new RowColumnPagePrinter(ROWS_PER_PAGE, 
            COLUMNS_PER_PAGE, 
            "The First " + NUMBER_OF_PRIMES + " Prime Numbers");
    tablePrinter.print(primes); 
  }
}

RowColumnPagePrinter.java

package literatePrimes;

import java.io.PrintStream;

public class RowColumnPagePrinter { 
  private int rowsPerPage;
  private int columnsPerPage; 
  private int numbersPerPage; 
  private String pageHeader; 
  private PrintStream printStream;
  
  public RowColumnPagePrinter(int rowsPerPage, int columnsPerPage, String pageHeader) { 
    this.rowsPerPage = rowsPerPage;
    this.columnsPerPage = columnsPerPage; 
    this.pageHeader = pageHeader;
    numbersPerPage = rowsPerPage * columnsPerPage; 
    printStream = System.out;
  }
  
  public void print(int data[]) { 
    int pageNumber = 1;
    for (int firstIndexOnPage = 0 ; 
      firstIndexOnPage < data.length ; 
      firstIndexOnPage += numbersPerPage) { 
      int lastIndexOnPage =  Math.min(firstIndexOnPage + numbersPerPage - 1, data.length - 1);
      printPageHeader(pageHeader, pageNumber); 
      printPage(firstIndexOnPage, lastIndexOnPage, data); 
      printStream.println("\f");
      pageNumber++;
    } 
  }
  
  private void printPage(int firstIndexOnPage, int lastIndexOnPage, int[] data) { 
    int firstIndexOfLastRowOnPage =
    firstIndexOnPage + rowsPerPage - 1;
    for (int firstIndexInRow = firstIndexOnPage ; 
      firstIndexInRow <= firstIndexOfLastRowOnPage ;
      firstIndexInRow++) { 
      printRow(firstIndexInRow, lastIndexOnPage, data); 
      printStream.println("");
    } 
  }
  
  private void printRow(int firstIndexInRow, int lastIndexOnPage, int[] data) {
    for (int column = 0; column < columnsPerPage; column++) {
      int index = firstIndexInRow + column * rowsPerPage; 
      if (index <= lastIndexOnPage)
        printStream.format("%10d", data[index]); 
    }
  }

  private void printPageHeader(String pageHeader, int pageNumber) {
    printStream.println(pageHeader + " --- Page " + pageNumber);
    printStream.println(""); 
  }
    
  public void setOutput(PrintStream printStream) { 
    this.printStream = printStream;
  } 
}

PrimeGenerator.java

package literatePrimes;

import java.util.ArrayList;

public class PrimeGenerator {
  private static int[] primes;
  private static ArrayList multiplesOfPrimeFactors;

  protected static int[] generate(int n) {
    primes = new int[n];
    multiplesOfPrimeFactors = new ArrayList(); 
    set2AsFirstPrime(); 
    checkOddNumbersForSubsequentPrimes();
    return primes; 
  }

  private static void set2AsFirstPrime() { 
    primes[0] = 2; 
    multiplesOfPrimeFactors.add(2);
  }
  
  private static void checkOddNumbersForSubsequentPrimes() { 
    int primeIndex = 1;
    for (int candidate = 3 ; primeIndex < primes.length ; candidate += 2) { 
      if (isPrime(candidate))
        primes[primeIndex++] = candidate; 
    }
  }

  private static boolean isPrime(int candidate) {
    if (isLeastRelevantMultipleOfNextLargerPrimeFactor(candidate)) {
      multiplesOfPrimeFactors.add(candidate);
      return false; 
    }
    return isNotMultipleOfAnyPreviousPrimeFactor(candidate); 
  }

  private static boolean isLeastRelevantMultipleOfNextLargerPrimeFactor(int candidate) {
    int nextLargerPrimeFactor = primes[multiplesOfPrimeFactors.size()];
    int leastRelevantMultiple = nextLargerPrimeFactor * nextLargerPrimeFactor; 
    return candidate == leastRelevantMultiple;
  }
  
  private static boolean isNotMultipleOfAnyPreviousPrimeFactor(int candidate) {
    for (int n = 1; n < multiplesOfPrimeFactors.size(); n++) {
      if (isMultipleOfNthPrimeFactor(candidate, n)) 
        return false;
    }
    return true; 
  }
  
  private static boolean isMultipleOfNthPrimeFactor(int candidate, int n) {
    return candidate == smallestOddNthMultipleNotLessThanCandidate(candidate, n);
  }
  
  private static int smallestOddNthMultipleNotLessThanCandidate(int candidate, int n) {
    int multiple = multiplesOfPrimeFactors.get(n); 
    while (multiple < candidate)
      multiple += 2 * primes[n]; 
    multiplesOfPrimeFactors.set(n, multiple); 
    return multiple;
  } 
}

변화

프로그램이 길어짐

리팩터링 → 더 길 서술적인 변수명 사용
리팩터링 → 코드 주석을 추가하는 수단으로 함수 선언과 클래스 선언 사용
→ 가독성을 높이고자 공백을 추가하고 포맷팅

책임에 따라 분류

PrimePrinter : main 함수 하나만 포함하며 실행 환경 책임
RowColumnPagePrinter : 숫자 목록을 주어진 행과 열에 맞춰 페이지에 출력하는 방법
PrimeGenerator : 소수 목록 생성
- 객체로 인스턴스화하는 클래스가 아니다
- 변수를 선언하고 감추려고 사용하는 유용한 공간일 뿐
- 소수 계산 알고리즘 변경시 해당 클래스 변경

재구현이 아니다

실제 동작원리가 비슷하다
원래 프로그램의 정확한 동작을 검증하는 테스트 슈트를 먼저 작성
이후 테스트를 수행하며 확인하면서 조금씩 코드를 변경

변경하기 쉬운 클래스

시스템은 지속적인 변경 가해짐
변경이 있을 때 마다 의도대로 동작하지 않을 위험이 따른다.

깨끗한 시스템은 클래스를 체계적으로 관리해 변경에 따르는 위험을 최대한 낮춘다.

변경이 필요해 손대야 하는 클래스

// 새로운 새로운 SQL문을 지원할 때, 기존 SQL문을 수정할 때 수정 필요
// 변경할 이유가 2가지 → SRP를 위반한다

public class Sql {
  public Sql(String table, Column[] columns)
  public String create()
  public String insert(Object[] fields)
  public String selectAll()
  public String findByKey(String keyColumn, String keyValue)
  public String select(Column column, String pattern)
  public String select(Criteria criteria)
  public String preparedInsert()
  private String columnList(Column[] columns)
  private String valuesList(Object[] fields, final Column[] columns) private String selectWithCriteria(String criteria)
  private String placeholderList(Column[] columns)
}

(경험에 의하면) 클래스 일부에서만 사용되는 비공개 메서드는 코드를 개선할 잠재젹 여지 시사
→ 실제로 개선에 뛰어드는 계기는 시스템이 변해서라야 한다
→ SQL클래스를 논리적으로 완성으로 여긴다면 책임 분리 시도 필요 없음
→ 변경이 필요하지 않는다면 내버려두는 편이 좋음
→ 변경을 위해 손을 대는 순간 설계 개선에 대한 고민/시도 필요

닫힌 클래스 집합

// 공개 인터페이스를 전부 SQL 클래스에서 파생하는 클래스로 만듬
// valueList와 같은 비공개 메서드는 해당 파생 클래스로 옮김
// 모든 파생 클래스가 공통으로 사용하는 비공개 메서드는 Where, ColumnList 두 유틸 클래스에 넣었다

  abstract public class Sql {
    public Sql(String table, Column[] columns) 
    abstract public String generate();
  }
  public class CreateSql extends Sql {
    public CreateSql(String table, Column[] columns) 
    @Override public String generate()
  }
  
  public class SelectSql extends Sql {
    public SelectSql(String table, Column[] columns) 
    @Override public String generate()
  }
  
  public class InsertSql extends Sql {
    public InsertSql(String table, Column[] columns, Object[] fields) 
    @Override public String generate()
    private String valuesList(Object[] fields, final Column[] columns)
  }
  
  public class SelectWithCriteriaSql extends Sql { 
    public SelectWithCriteriaSql(
    String table, Column[] columns, Criteria criteria) 
    @Override public String generate()
  }
  
  public class SelectWithMatchSql extends Sql { 
    public SelectWithMatchSql(String table, Column[] columns, Column column, String pattern) 
    @Override public String generate()
  }
  
  public class FindByKeySql extends Sql public FindByKeySql(
    String table, Column[] columns, String keyColumn, String keyValue) 
    @Override public String generate()
  }
  
  public class PreparedInsertSql extends Sql {
    public PreparedInsertSql(String table, Column[] columns) 
    @Override public String generate() {
    private String placeholderList(Column[] columns)
  }
  
  public class Where {
    public Where(String criteria) public String generate()
  }
  
  public class ColumnList {
    public ColumnList(Column[] columns) public String generate()
  }

특징 : 장점만 취한다

SRP 지원 : 클래스가 서로 분리됨, 함수 하나를 수정해도 다른 함수가 망가지지 않음
OCP 지원
- 파생 클래스 생성하는 방식으로 새로운 기능 추가에 개방적
  - update 문 추가시 UpdateSql 클래스를 끼워 넣으면 끝
- 다른 클래스를 닫아놓음 → 수정에 폐쇄적

변경으로부터 격리

요구사항은 변한다 → 코드도 변한다
의존객체의 상세 구현에 의존하는 클라이언트 → 구현이 바뀌면 위험 → 인터페이스, 추상 클래스로 구현이 미치는 영향을 격리
상세한 구현에 의존하는 코드는 테스트도 어렵다
추상화를 통해 테스트가 가능할 정도로 시스템의 결합도를 낮춤→ 유연성과 재사용성도 더욱 높아진다.

결함도가 낮다는 말은 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어있다는 뜻이다.

예)Portfolio 클래스

외부 TokyoStockExchange API를 사용해 포트폴리오 값을 계산 → 외부 시세 변화 영향으로 값이 달라짐

인터페이스를 생성한 후 메서드를 선언하다.

1
2
3

public interface StockExchange { 
  Money currentPrice(String symbol);
}

// TokyoStockExchange 클래스 : StockExchange 인터페이스를 구현
// Portfolio 생성자를 통해 StockExchange 참조자를 주입
public Portfolio {
  private StockExchange exchange;
  public Portfolio(StockExchange exchange) {
    this.exchange = exchange; 
  }
  // ... 
}

// StockExchange 인터페이스로 상세 구현의 의존을 막았으므로 테스트용 클래스로 바꿀 수 있음
// TokyoStockExchange 클래스를 흉내냄며 고정된 주가를 반환하는 테스트용 클래스 FixedStockExchangeStub 를 만들 수 있다
// 무난히 테스트 코드를 작성 할 수 있다.

public class PortfolioTest {
  private FixedStockExchangeStub exchange;
  private Portfolio portfolio;
  
  @Before
  protected void setUp() throws Exception {
    exchange = new FixedStockExchangeStub(); 
    exchange.fix("MSFT", 100);
    portfolio = new Portfolio(exchange);
  }

  @Test
  public void GivenFiveMSFTTotalShouldBe500() throws Exception {
    portfolio.add(5, "MSFT");
    Assert.assertEquals(500, portfolio.value()); 
  }
}

위의 테스트가 가능할 정도로 시스템 결합을 낮추면?

유연성과 재사용성이 더 높아짐
시스템 결합이 낮다 : 각 시스템 요소가 다른 요소, 그리고 변경으로부터 잘 격리가 되어있다는 의미 → 각 요소 이해도 쉬어짐
결합도 최소로 줄이면? 자연스럽게 DIP를 따르는 클래스가 나온다
DIP : 클래스가 상세 구현이 아닌 추상화 의존해야 한다는 원칙

[Clean Code] Ⅸ. 단위 테스트

Wed, 09 Feb 2022 00:54:04 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅸ. 단위 테스트

1997이전

TDD 개념 없었음
단위 테스트
- 자기 프로그램이 돌아간다는 사실만 확인하는 일회성 코드
- 클래스 메서드를 공들여 구현한 후, 임시 코드를 급조해 테스트 수행

현재

테스트 코드 : 코드의 구현을 모두 확인하는 테스트 코드
애자일과 TDD → 단위테스트 자동화 이미 많아짐
급한 테스트 추가 + 제대로 된 테스트 케이스 작성을 놓침

TDD 법칙 3가지

3가지 법칙

실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다
컵파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트 작성
현재 실패하는 테스트를 통과할 정도로만 실제 코드 작성
→ 3법칙 따르면 개발과 테스트가 대략 30초 주기
→ 테스트 코드가 실제 코드보다 불과 몇 초전
→ 매일 수십개, 매달 수백개, 매년 수천 개에 해당하는 테스트 케이스
→ 실제 코드를 사실상 전부 테스트 하는 테스트 케이스
→ 때로는 심각한 관리 무제 유발

깨끗한 코드 유지하기

테스트 코드는 지저분해도 빨리?

실제 코드 진화 → 테스트도 진화 필요
테스트 코드가 지저분하면 변경이 어려움 → 테스트 코드 추가/수정이 실제 코드 짜는 시간보다 오래걸림
테스트 코드는 실제 코드 못지 않게 중요하다
테스트 코드도 구현 코드처럼 깨끗하게 짜야 한다

테스트는 유연성, 유지보수성, 재사용성 제공

테스트 케이스가 있으면 변경에 대한 공포없이 안심하고 개선 가능
테스트는 변경되는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠

Clean Test Code

테스트 코드의 가장 중요한 점? 가독성
실제코드보다 테스트 코드에서 가독성은 더 중요
높은 가독성? → 명료성, 단순성, 붕푸한 표현력

SerializedPageResponderTest.java

 // FitNess에서 가져온 코드
 // 아래 테스트 케이스 세 개는 이해하기 어렵기에 개선할 여지가 충분
 // 첫째, addPage와 assertSubString을 부르느라 중복되는 코드가 매우 많다
 // 좀 더 중요하게는 자질구레한 사항이 너무 많아 테스트 코드의 표현력이 떨어진다.
public void testGetPageHieratchyAsXml() throws Exception {
  crawler.addPage(root, PathParser.parse("PageOne"));
  crawler.addPage(root, PathParser.parse("PageOne.ChildOne"));
  crawler.addPage(root, PathParser.parse("PageTwo"));

  request.setResource("root");
  request.addInput("type", "pages");
  Responder responder = new SerializedPageResponder();
  SimpleResponse response =
    (SimpleResponse) responder.makeResponse(new FitNesseContext(root), request);
  String xml = response.getContent();

  assertEquals("text/xml", response.getContentType());
  assertSubString("PageOne", xml);
  assertSubString("PageTwo", xml);
  assertSubString("ChildOne", xml);
}

public void testGetPageHieratchyAsXmlDoesntContainSymbolicLinks() throws Exception {
  WikiPage pageOne = crawler.addPage(root, PathParser.parse("PageOne"));
  crawler.addPage(root, PathParser.parse("PageOne.ChildOne"));
  crawler.addPage(root, PathParser.parse("PageTwo"));

  PageData data = pageOne.getData();
  WikiPageProperties properties = data.getProperties();
  WikiPageProperty symLinks = properties.set(SymbolicPage.PROPERTY_NAME);
  symLinks.set("SymPage", "PageTwo");
  pageOne.commit(data);

  request.setResource("root");
  request.addInput("type", "pages");
  Responder responder = new SerializedPageResponder();
  SimpleResponse response =
    (SimpleResponse) responder.makeResponse(new FitNesseContext(root), request);
  String xml = response.getContent();

  assertEquals("text/xml", response.getContentType());
  assertSubString("PageOne", xml);
  assertSubString("PageTwo", xml);
  assertSubString("ChildOne", xml);
  assertNotSubString("SymPage", xml);
}

public void testGetDataAsHtml() throws Exception {
  crawler.addPage(root, PathParser.parse("TestPageOne"), "test page");

  request.setResource("TestPageOne"); request.addInput("type", "data");
  Responder responder = new SerializedPageResponder();
  SimpleResponse response =
    (SimpleResponse) responder.makeResponse(new FitNesseContext(root), request);
  String xml = response.getContent();

  assertEquals("text/xml", response.getContentType());
  assertSubString("test page", xml);
  assertSubString(", xml);
}

문제점

addPage와 assertSubString을 부르느라 중복되는 코드가 매우 많다
PathParser
- 문자열을 pagePath 인스턴스로 변환
- pagePath 웹 로봇(크롤러)가 사용하는 객체 → 테스트와 무관하며 테스트 의도만 흐린다
Responder생성, respoonse 수집 코드 → 역시 잡음
resource의 인수에서 요청 URL 을 만드는 어설픈 코드
읽는 사람을 고려하지 않음

SerializedPageResponderTest.java 9-2_리팩터링한 코드

public void testGetPageHierarchyAsXml() throws Exception {
  makePages("PageOne", "PageOne.ChildOne", "PageTwo");

  submitRequest("root", "type:pages");

  assertResponseIsXML();
  assertResponseContains(
    "PageOne", "PageTwo", "ChildOne");
}

public void testSymbolicLinksAreNotInXmlPageHierarchy() throws Exception {
  WikiPage page = makePage("PageOne");
  makePages("PageOne.ChildOne", "PageTwo");

  addLinkTo(page, "PageTwo", "SymPage");

  submitRequest("root", "type:pages");

  assertResponseIsXML();
  assertResponseContains(
    "PageOne", "PageTwo", "ChildOne");
  assertResponseDoesNotContain("SymPage");
}

public void testGetDataAsXml() throws Exception {
  makePageWithContent("TestPageOne", "test page");

  submitRequest("TestPageOne", "type:data");

  assertResponseIsXML();
  assertResponseContains("test page", ");
}

BUILD-OPERATE-CHECK 패턴이 위와 같은 테스트 구조에 적합

각 테스트는 명확히 세 부분으로 나눠진다.
첫 부분은 테스트 자료를 만든다.
두 번째 부분은 테스트 자료를 조작
세 번째 부분은 조작한 결과가 올바른지 확인

테스트 코드는 본론에 돌입해 진짜 필요한 자료유형과 함수만 사용

잡다하고 세세한 코드를 거의 다 없앰
읽는 사람으로 하여금 테스트 코드가 수행하는 기능을 재빨리 이해

도메인 특화된 테스트 언어

위의 리팩토링된 코드는 DSL로 테스트 코드 구현 기법 보여줌
흔히 쓰는 시스템 조작 API 사용대신 API 위에 함수, 유틸리티 구현후 사용
이렇게 구현한 함수와 유틸리티는 테스트 코드에서 사용하는 특수 API가 된다
→ 테스트 구현 당사자, 테스트를 읽어볼 독자를 도와주는 테스트 언어
테스트 API는 처음부터 설계된 API가 아님 → 리팩터링하며 진화된 API

이중 표준

테스트 API에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다
단순,간결,표현력 풍부는 동일
실제 코드만큼 효율적일 필요는 없음 → 테스트 환경에서 돌아가는 코드이므로

EnvironmentControllerTest.java

//대충 읽어도 온도가 급격히 떨어지면 경보, 온풍기, 송풍기 확인하는 테스트 코드
@Test
public void turnOnLoTempAlarmAtThreashold() throws Exception {
  hw.setTemp(WAY_TOO_COLD); 
  controller.tic(); 
  assertTrue(hw.heaterState());   
  assertTrue(hw.blowerState()); 
  assertFalse(hw.coolerState()); 
  assertFalse(hw.hiTempAlarm());       
  assertTrue(hw.loTempAlarm());
}
//상태와 상태값 보느라 가독성 떨어짐

EnvironmentControllerTest.java(리팩터링)

@Test
public void turnOnLoTempAlarmAtThreshold() throws Exception {
  wayTooCold();
  assertEquals("HBchL", hw.getState());
}

설명

wayTooCold함수로 기존 tic함수 숨김
그릇된 코드 위반에 가깝지만 여기에 적절 → 테스트 코드가 읽기 쉬어짐

EnvironmentControllerTest.java (bigger selection)

@Test
public void turnOnCoolerAndBlowerIfTooHot() throws Exception {
  tooHot();
  assertEquals("hBChl", hw.getState()); 
}
  
@Test
public void turnOnHeaterAndBlowerIfTooCold() throws Exception {
  tooCold();
  assertEquals("HBchl", hw.getState()); 
}

@Test
public void turnOnHiTempAlarmAtThreshold() throws Exception {
  wayTooHot();
  assertEquals("hBCHl", hw.getState()); 
}

@Test
public void turnOnLoTempAlarmAtThreshold() throws Exception {
  wayTooCold();
  assertEquals("HBchL", hw.getState()); 
}

테스트 코드 이해가 너무 쉬어짐

MockControlHardware.java

public String getState() {
  String state = "";
  state += heater ? "H" : "h"; 
  state += blower ? "B" : "b"; 
  state += cooler ? "C" : "c"; 
  state += hiTempAlarm ? "H" : "h"; 
  state += loTempAlarm ? "L" : "l"; 
  return state;
}

성능적으로 효율적이지 못한 코드
효율을 높이려면 StringBuffer가 더 작합하지만 보기에 흉하다
위 코드는 StringBuffer를 사용하지 않아 치루는 비용이 미미→ 테스트에선 자원 제한일 가능성이 낮으므로

이중 표준의 본질

실제 환경에서는 절대 안되지만 테스트 환경에서는 전혀 문제 없는 방식이 존재
대게 메모리,cpu효율 관련
클린 코드 여부와는 철저히 무관

테스트당 assert 하나

테스트 코드시 함수마다 assert 하나만 사용?

그래야 한다는 파 존재
확실한 장점이 있음 → 결론이 하나라 코드가 이해하기 쉽고 빠름
모두 적용되지 않음
위 9-2_리팩터링 코드는
“출력이 XML”이다라는 assert와
“특정 문자열을 포함”이라는 assert가 있으며
이 둘을 하나로 병합하는 방식이 불합리해보임
방법 : 테스트를 쪼개 각자가 assert 수행

SerializedPageResponderTest.java (단일 Assert)

public void testGetPageHierarchyAsXml() throws Exception { 
  givenPages("PageOne", "PageOne.ChildOne", "PageTwo");
  
  whenRequestIsIssued("root", "type:pages");
  
  thenResponseShouldBeXML(); 
}

public void testGetPageHierarchyHasRightTags() throws Exception { 
  givenPages("PageOne", "PageOne.ChildOne", "PageTwo");
  
  whenRequestIsIssued("root", "type:pages");
  
  thenResponseShouldContain(
    "PageOne", "PageTwo", "ChildOne"
  ); 
}

given-when-then 관례 사용
- 테스트 코드 일기가 쉬워짐
- 불행히도 위에서 보듯이 테스트를 분리하면 중복된 코드가 많아짐
- 해결? 템플릿 메서드 패턴 사용시 중복 제거 가능
템플릿 메서드 패턴 : 중복 제거 가능
- given/when을 부모 클래스에
- then을 자식 클래스에
다른 방법?
- 독자적 클래스를 만들고 @Before에 given when을 넣고 @Test에 then부분을 넣어도 된다
문제는? 모두가 배보다 배꼽이 크다
모든걸 감안하면 결국 9-2처럼 assert을 여러 개를 사용하는 것이 좋다

테스트당 개념 하나

→테스트 함수마다 한 개념만 테스트하라

/**
 * addMonth() 메서드를 테스트하는 장황한 코드
 */
public void testAddMonths() {
  SerialDate d1 = SerialDate.createInstance(31, 5, 2004);

  SerialDate d2 = SerialDate.addMonths(1, d1); 
  assertEquals(30, d2.getDayOfMonth()); 
  assertEquals(6, d2.getMonth()); 
  assertEquals(2004, d2.getYYYY());
  
  SerialDate d3 = SerialDate.addMonths(2, d1); 
  assertEquals(31, d3.getDayOfMonth()); 
  assertEquals(7, d3.getMonth()); 
  assertEquals(2004, d3.getYYYY());
  
  SerialDate d4 = SerialDate.addMonths(1, SerialDate.addMonths(1, d1)); 
  assertEquals(30, d4.getDayOfMonth());
  assertEquals(7, d4.getMonth());
  assertEquals(2004, d4.getYYYY());
}

바람직하지 못한 코드

독자적인 개념 3개를 테스트 → 독자적 테스트 3개로 쪼개야
한 함수일경우 독자가 각 절이 거기에 존재하는 이유와 각 절이 테스트하는 개념을 모두 이해해야 한다.

분리한 테스트 코드

(5월처럼) 31일로 끝나는 달의 마지막 날짜가 주어지는 경우

(6월처럼) 30일로 끝나는 한 달을 더하면 날짜는 30일이 되어야지 31일이 되어서는 안 된다.
두 달을 더하면 그리고 두 번째 달이 31일로 끝나면 날짜는 31일이 되어야 한다.

(6월처럼) 30일로 끝나는 달의 마지막 날짜가 주어지는 경우
1. 31일로 끝나는 한 달을 더하면 날짜는 30일이 되어야지 31일이 되면 안 된다.

분리하면? → 감춰진 일반적인 규칙이 보임

날짜에 어떤 달을 더 하면 날짜는 그달의 마지막 날짜보다 커지지 못함
→ 2월+28일 + 1달 = 3월 28일 → 채우면 좋을 테스트 케이스

포인트

개념당 assert 문을 최소로
세트스 함수당 개념 하나만 테스트

F.I.R.S.T

이미지 from

1. FAST

테스트는 빨라야 한다
느리면 자주 못 돌림 → 초반에 문제 못 찾음, 코드 마음껏 정리 불가 → 코드 품질 망가짐

2. Isolates

각 테스트는 서로 의존하면 안된다
각 테스트는 독립적으로 어떤 순서로 실행해도 괜찮아야 한다
테스트가 의존하면? → 연쇄 실패 발생 → 원인 진단 어려움 → 테스트 결함 숨겨짐

3. Repeatable

테스트는 어떤 환경에서도 반복 가능해야 한다
실제 환경, QA 환경, 오프라인된 노트북에서도 실행 가능해야 한다
테스트가 돌아가지 않는 환경이 하나라도 있으면 안된다

4. Self-validating

테스트는 bool값으로 결과를 내야 한다
스스로 성공과 실패가 가늠해야 한다
그러지 않으면? → 주관적 판단 → 지루한 수작업 평가

4. Timely

테스트는 적시에 작성해야 한다
테스트 하려는 실제 코드 구현 직전에 구현한다
실제 코드 구현 후엔? 실제 코드가 테스트 하기 어렵다는 사실 발견
테스트가 불가능한 실제 코드 설계 했을 수도

결론

‘깨끗한 테스트 코드’는 책 한 권을 할애해도 모자랄 주제다
테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존/강화
→실제 구현 코드보다 더 중요할지도
테스트 코드는
- 깨끗하게 지속적으로 관리
- 표현력 높이고 간결하게 정리
- 테스트 API를 구현해 DSL을 만들어 테스트 코드를 짜기 쉽게 만들자

[Clean Code] Ⅷ. 경계

Wed, 09 Feb 2022 00:53:46 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅷ. 경계

모든 프로그램을 직접 개발하지 않음

패키지, 오픈소스, 다른 사내의 컴포넌트등
외부 코드와 우리 코드를 깔끔하게 통합하는 방법?

외부 코드 사용

인터페이스 제공자와 인터페이스 사용자의 긴장

제공자
- 패키지 제공자, 프레임워크 제공자
- 적용성 최대한 넓히려 → 더 많은 환경에서 돌아가도록
사용자
– 자신의 요구에 집중하는 인터페이스를 원함

Java.util.Map

Map : 굉장히 다양한 인터페이스로 수많은 기능 제공
Map의 기능성/유연성은 유용하나 위험도 큼
Map을 여기저기 넘길때 Map.clear()로 누구나 내용 삭제 가능

객체 유형 제한 없음 : 마음만 먹으면 어떤 객체든 추가 가능

일반적인 Map 사용

// Sensor 객체를 담는 Map
Map sensors = new HashMap(); 
// Sensor 가 필요하면
Sensor s = (Sensor) sensors.get(sensorId);

동작은 하나 클린 코드는 아님
- Map의 리턴값인 Object의 cast 책임이 클라이언트에 있음
- 코드의 의도가 들어나지 않음

Generics를 사용해서 가독성을 올린 예시

1 2	Map sensors = new HashMap(); Sensor s = sensors.get(sensorId);

사용자에게 필요하지 않은 기능까지 제공하는 문제를 해결하지 못함
Map 인터페이스도 변함 (ex)자바5의 제네릭 추가등 : 이경우 수정코드가 많음

Map을 좀 더 깔끔하게 사용한 예시

public class Sensors {

    private Map sensors = new HashMap(); 
    
    public Sensor getById(String id) {
        return (Sensor)sensors.get(id);
    }
    //이하 생략
}

경계 인터페이스인 Map을 Sensors 안으로 숨김
- Map 인터페이스가 변하더라도 나머지 프로그램에 영향 없음
- 제네릭 사용 여부에 영향 X → Sensors 클래스 안에서 객체 유형 관리/변환
Sensors 클래스가 프로그램에 필요한 인터페이스만 제공
- 코드 이해가 쉬우며 오용하기는 어려움
- 나머지 사용 클라이언트에 설계 규칙/ 비지니스 규칙을 따르도록 강제 가능

Map(또는 유사한 경계 인터페이스를 )여기저기 넘기지 마라

이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의
공개 API 인자나 반환값으로 Map 인스턴스를 사용하면 안된다

경계 살피고 익히기

외부 패키지 테스트는 우리 책임이 아니나 사용할 코드를 테스트 함이 바람직함
외부 코드 익히기 어려움
- 타사 라이브러리 문서 읽음으로사용법 결정
- 코드 작성해서 라이브러리 예쌍 작동 확인
- 디버깅 문제 : 우리 코드 버그 or 라이브러리 버그?
  학습 테스트
간단한 테스트 케이스를 작성해서 외부 코드를 익히는 방법
프로그램에서 사용하는 방식대로 외부 API 호출
통제된 환경에서 API를 제대로 이해하는가 확인
API 사용목적 초점

log4j 익히기

학습 테스트
지금까지 간단한 콘솔 로거 초기화 방법 익힘
이제 모든 지식을 독자적 로거 클래스로 캡슐화
나머지 프로그램은 log4j 경계 인터페이스를 몰라도 사용 가능

학습 테스트는 공짜 이상이다

학습테스트는 이해도를 높여주는 정확한 실험
투자노력보다 얻는 성과가 더 큼
패키지 새 버전 나오면 학습 테스트를 돌려서 차이가 있는지 검증 가능
이런 경계 테스트가 있으면 패키지 새 버전 이전이 쉬어짐
아니면 필요이상 낡은 버전을 오랫동안 사용하려는 유혹에 빠지기 쉬움

아직 존재하지 않는 코드를 사용하기

경게의 또 다른 유형 : 아는코드와 모르는 코드를 분리하는 경계
예시)

상황
- sw에 ‘송신기’가 필요
- 송신기 시스템 책임진 사람들은 인터페이스도 정의하지 못한 상태
- 프로젝트 지연 없게 하기 위해 송신기와 먼 부분부터 작업
- 작업 부분과 송신기 시스템 부분의 경계를 부딫치게 되며 기능정의를 하게 되었음
  - 지정한 주파수를 이용해 이 스트림에서 들어오는 자료를 아날로그 신호로 전송하라
- 아직 API설계가 되지 않으므로 구체적인 방법은 모름 → 구현을 나중으로
- 자체적 인터페이스 정의
  - Transmitter 인터페이스 클래스 정의
  - transmit 메서드 추가
  - 주파수와 자료스트림을 입력받음
바라는 인터페이스 구현 → 인터페이스 전적 통제한다는 장점 → 코드 가독성과 분명한 코드 의도 반영
(통제할수도 없고 정의되지도 않은) 송신기 API에서 Communication Controller 분리
- 필요한 인터페이스 정의 했으므로 Communication Controller는 깔끔 / 깨끗
- 실제 송신기 API가 정의된 뒤에는 Transmitter Adapter 구현으로 간극을 매운다
- ADAPTER 패턴 사용 → API 사용 캡슐화 → API 수정 시 수정될 코드를 한 곳으로
- 테스트도 간편 : 적절한 Fake Transmitter 사용 → Communication Controller 테스트 가능
Transmitter API 인터페이스가 나온다음에 경계 테스트 생성해서 올바로 API 사용하는지도 테스트 가능

깨끗한 경계

경계의 변경

sw 개발설계가 우수하다면? 변경시 많은 투자와 재작업이 필요하지 않음
통제 못하는 코드 사용시 너무 많은 투자나 향후 변경 비용이 너무 커지지 않도록 각별히 유의

경계 코드는 깔끔히 분리

기대치 정의 테스트 ㅂ작성
외부 호출한 코드를 가능한 줄여 경계를 관리하자
- Map의 예처럼 새로운 클래스로 경계를 감싸거나
- ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자
- 어떤 방법이든 가독성향상, 경계 인터페이스 사용 일관성 향상, 패키지 변경시 변경 코드 감소

[Clean Code] Ⅶ. 오류 처리

Wed, 09 Feb 2022 00:53:26 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅶ. 오류 처리

클린 코드와 오류처리의 상관관계

오류의 가능성은 늘 언제나 존재
오류 정정의 책임은 프로그래머가 가지고 있음
여기저기 흩어진 오류 처리 코드 → 실제 코드 로직 파악 어렵게 만듬

오류 코드 보다 예외 사용

이전 프로그래밍 언어 → Exception 제공 x

개발자들이 에러 상태나 flag를 set해야 함

에러코드를 리턴, 호출하는 측에서 예외 처리해줘야 함

안좋은 예 오류 플래그, 호출자에게 오류 코드 반환 등

public class DeviceController {
  ...
  public void sendShutDown() {
    DeviceHandle handle = getHandle(DEV1);
    // Check the state of the device
    if (handle != DeviceHandle.INVALID) {
      // Save the device status to the record field
      retrieveDeviceRecord(handle);
      // If not suspended, shut down
      if (record.getStatus() != DEVICE_SUSPENDED) {
        pauseDevice(handle);
        clearDeviceWorkQueue(handle);
        closeDevice(handle);
      } else {
        logger.log("Device suspended. Unable to shut down");
      }
    } else {
      logger.log("Invalid handle for: " + DEV1.toString());
    }
  }
  ...
}

위 코드 단점
- 호출자 코드 복잡 : 호출 리턴 받은 즉시 오류 확인 필요
- 불행히 이 단계를 잊어버리기 쉬움

Exception 사용하면?

깔끔해짐
겉보기만 아름다워지는 것이 아님
실제 로직과 예외처리 부분이 나누어짐

필요 부분에 집중

오류 발견시 예외를 던지는 코드

public class DeviceController {
  ...
  public void sendShutDown() {
    try {
      tryToShutDown();
    } catch (DeviceShutDownError e) {
      logger.log(e);
    }
  }
    
  private void tryToShutDown() throws DeviceShutDownError {
    DeviceHandle handle = getHandle(DEV1);
    DeviceRecord record = retrieveDeviceRecord(handle);
    pauseDevice(handle); 
    clearDeviceWorkQueue(handle); 
    closeDevice(handle);
  }
  
  private DeviceHandle getHandle(DeviceID id) {
    ...
    throw new DeviceShutDownError("Invalid handle for: " + id.toString());
    ...
  }
  ...
}

개념 분리 : 디바이스 종료 알고리즘 + 오류 처리 알고리즘
각 개념을 독립적으로 살펴보기 가능해짐

try-catch-Finally부터 작성하라

try블록은 트랜잭션과 비슷
try가 어떻든 catch에서는 프로그램 상태를 일관성 있게 유지

코드의 scope 정의 가능
예시

TEST 코드

//예외를 기대하는 단위 테스트 코드
@Test(expected = StorageException.class)
public void retrieveSectionShouldThrowOnInvalidFileName() {
  sectionStore.retrieveSection("invalid - file");
}

1. 구현코드1 : 예외를 던지지 않으므로 실패

public List retrieveSection(String sectionName) {
  // dummy return until we have a real implementation
  return new ArrayList();
}

예외를 던지는 구현 코드로 테스트 성공

  public List retrieveSection(String sectionName) {
    try {
      FileInputStream stream = new FileInputStream(sectionName)
    } catch (Exception e) {
      throw new StorageException("retrieval error", e);
    }
  return new ArrayList();
}

이제부터 리팩토링 가능

catch 블럭에서 예외 유형 좁히기

// Exception의 범위를 FileNotFoundException으로 줄여 잡아낸다.
public List retrieveSection(String sectionName) {
  try {
    FileInputStream stream = new FileInputStream(sectionName);
    stream.close();
  } catch (FileNotFoundException e) {
    throw new StorageException("retrieval error", e);
  }
  return new ArrayList();
}

try catch구조로 범위 정의 → TDD를 사용해 나머지 논리 추가
나머지 논리는 FileInputStream생성과 close()사이에 넣는다
먼저 강제로 예외를 일으키는 테스트 케이스를 작성 후 테스트를 통과하게 코드를 작성하는 방법 권장
자연스럽게 try블록의 트랜잭션 부터 구현하게됨 → 범위 내에서 트랜잭션 본일 유지가 쉬워짐

unchecked 예외를 사용하라

논쟁은 끝났다 : unchecked 사용하라!

checked Execption vs Unchecked Exception

가장 명확한 기준 : 꼭 처리를 해야 하는 부분
확인된 예외 : 반드시 try/catch로 감싸거나 throw로 처리해야 한다

이전엔는 확인된 예외를 좋은 아이디어로 생각

확인된 예외 : checked exception
북구될 가능성이 있는 문제상황으로 봄
컴파일단에서 확인이 가능하고 복구를 시도해 보는 것이 일차적 관심상
메서드 선언시 메서드가 반환할 예외 모두 열거
메서드 반환 예외는 메서드 유형의 일부
코드가 메서드를 사용하는 방식이 메서드 선언과 일치하지 않으면 아예 컴파일도 불가

현재는 확인된 예외가 반드시 필요하지 않는다

c#, c++, 파이썬, 루비 : 확인된 예외가 없지만 안정적인 sw만드는데 문리가 없음

확인된 예외(checked exception)의 비용

위에서 말했듯이 모든 중간 단계 메소드에 해당 exception을 throw 해야 함
OCP 위반

메서드에서 확인된 예외를 던졌는데 catch 블록이 3단계 위라면
그 사이 메서드 모두 선언부에 해당 예외를 정의해야함 (throw 절)
하위 단계 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야함(새로운 예외 추가or throw절 추가등)
(코드가 전혀 변경이 없어도) 선언부가 바뀌므로 모듈 다시 빌드하고 배포해야함
throws 경로의 모든 함수가 최하위 함수의 예외(하위 세부)를 알아야 함 → 캡슐화가 꺠진다
오류를 원거리에서 처리하기 위해 예외를 사용했는데 예외가 캡슐화를 깨버리는 아이러니

때로는 유용

아주 중요한 라이브러리라면 모든 예외를 잡아야함
일반적 어플리케이션? 의존성 비용>>>>>> 예외로 얻는 이득

예외에 메시지를 담아라 - 예외에 의미있는 정보를 담기

예외를 던질때 전주 상황을 충분히 덧붙여라

오류가 발생한 원인/위치 찾기가 쉬어짐
자바는 모든 예외에 호출 스택을 제공 → 실패 코드 의도 파악을 위해선 해당 정보로 부족
오류 메시지에 정보를 담아 예외와 함께 던져야함
- 실패한 연산 이름, 실패 유형도 언급
- 로깅 사용시 catch 블럭에서 오류룰 기록하도록 충분한 정보를 넘겨준다

호출자를 고려해서 예외 클래스 정의

오류 분류방법은 수없이 많음 : 오류 발생한 위치, 유형등

프로그래머 가장 큰 관심사 : 오류를 잡아내는 방법

형편 없는 오류 분류 예시

// 외부 라이브러리가 던질 예외를 모두 잡음
// 중복도 심함
ACMEPort port = new ACMEPort(12);
try {
  port.open();
} catch (DeviceResponseException e) {
  reportPortError(e);
  logger.log("Device response exception", e);
} catch (ATM1212UnlockedException e) {
  reportPortError(e);
  logger.log("Unlock exception", e);
} catch (GMXError e) {
  reportPortError(e);
  logger.log("Device response exception");
} finally {
  ...
}

일반적인 상황에서 우리가 오류를 처리하는 방식
→ (오류 원인과 무관하게) 비교적 일정

오류를 기록한다
프로그램을 계속 수행해도 좋은지 확인한다

위의 코드 의 경우
→ 예외 대응 방식이 예외 유형과 무관하게 거의 동일

호출하는 라이브러리 api를 감싸면서 예외 유형 하나를 반환하도록

LocalPort → ACMEPort Wrapper class

// 호출부 - Exception 처리가 들어나지 않도록 수행 가능
LocalPort port = new LocalPort(12);
  try {
    port.open();
  } catch (PortDeviceFailure e) {
    reportError(e);
    logger.log(e.getMessage(), e);
  } finally {
    ...
  }
//---------------------------------------------  
//ACMEPort가 던지는 예외를 잡아 변환하는 wrapper class
  public class LocalPort {
    private ACMEPort innerPort;
    public LocalPort(int portNumber) {
      innerPort = new ACMEPort(portNumber);
    }
    
    public void open() {
      try {
        innerPort.open();
      } catch (DeviceResponseException e) {
        throw new PortDeviceFailure(e);
      } catch (ATM1212UnlockedException e) {
        throw new PortDeviceFailure(e);
      } catch (GMXError e) {
        throw new PortDeviceFailure(e);
      }
    }
    ...
  }

wrapping의 유용성

실제로 외부 api 사용시 wrapping 기법이 최선
외부 api wrapping → 외부 라이브러리와 프로그램 사이의 의존성이 크게 줄어든다
나중에 다른 라이브러리로 갈아타도 비용이 적음
wrapping 클래스에서 외부 api 호출 대신 테스트 코드 넣어주는 방법으로 테스트도 쉬어짐
wrapping 사용하면 특정 업체가 api를 설계한 방식에 발목 잡히지 않음
위의 예제에선 port 디바이스 실패를 표현하는 예외 유형 하나 정의 → 프로그램이 깨끗해짐

예외 클래스 수

예외 클래스가 하나만 있어도 충분한 코드 → 예외 클래스에 포함된 정보로 오류를 구분해도 괜찮은 경우
한 예외 잡아내고 다른 예외 무시해도 괜찮다면? 여러 예외 클래스 사용

정상 흐름을 정의하라

앞절의 지침 충실히 → 비지니스와 오류처리가 잘 분리된 코드
오류 감지가 프로그램 언저리로 밀려나게 됨
- 외부 API를 감싸 독자적 예외 던짐
- 코드위에 처리기를 정의해 중단된 계산을 처리
- 대부분은 좋은 처리 방식이지만 이런 중단이 적합하지 않을 때도 있음

총계를 계산하는 허술한 코드

try {
  MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
  m_total += expenses.getTotal(); //식비 비용 청구 → 청구 식비를 총계에 더함
} catch(MealExpensesNotFound e) {
  m_total += getMealPerDiem(); //식비 비용 청구 안하면 → 일일 기본 식비를 총계에 더함
}
// 예외가 논리를 따라가기 어렵게 만듬

특수상황을 처리할 필요가 없으면 코드가 더 간결해진다.. 다음처럼 가능한가?

1 2	MealExpenses expenses = expenseReportDAO.getMeals(employee.getID()); m_total += expenses.getTotal();

정답 : 가능함

ExpenseReportDAO가 언제나 MealExpense 객체 반환하도록 고침

청구 식비가 없으면 일일 기본 식비를 반환하는 MealExpense 객체 반환

public class PerDiemMealExpenses implements MealExpenses {
    public int getTotal() {
      // return the per diem default
    }
  }
  
  // ex??
  public class ExpenseReportDAO {
    ...
    public MealExpenses getMeals(int employeeId) {
      MealExpenses expenses;
      try {
        expenses = expenseReportDAO.getMeals(employee.getID());
      } catch(MealExpensesNotFound e) {
        expenses = new PerDiemMealExpenses();
      }
      
      return expenses;
    }
    ...
  }

특수 사례 패턴
- 클래스를 만들거나 객체를 조작해서 특수 사례를 처리하는 방식
- 객체나 클래스가 예외적인 상황을 캡슐화해서 처리
- 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다

null을 반환하지 마라

null확인이 가득한 코드 → 나쁜 코드

null 반환 코드는 일거리를 늘리며 호출자에게 문제를 넘김

한명이라도 null 체크 빼먹으면 위험

public void registerItem(Item item) {
    if (item != null) {
      ItemRegistry registry = peristentStore.getItemRegistry();
      if (registry != null) {
        Item existing = registry.getItem(item.getID());
        if (existing.getBillingPeriod().hasRetailOwner()) {
          existing.register(item);
        }
      }
    }
  }
// - peristentStore가 null인 경우 예외처리 안됨
// - 안된 것도 찾기가 힘든

메서드에서 null을 반환하고 픈 유혹이 든다면? → 예외를 던지거나 특수 사례 객체를 반환하라
사용하려는 외부 api가 null 반환? → 감싸기 기법 사용 → 예외 던지거나 특수 사례 객체 반환하는 방식 고려

많은 경우 특수 사례 객체가 손쉬운 해결책

예시

// 1. null 반환
List employees = getEmployees();
  if (employees != null) { 
    for(Employee e : employees) {
      totalPay += e.getPay();
    }
  }
// 2. null 체크 없애고 getEmployees에서 빈 리스트 반환
List employees = getEmployees();
  for(Employee e : employees) {
    totalPay += e.getPay();
  }
  
  public List getEmployees() {
    if( .. there are no employees .. )
      return Collections.emptyList();
    }
}
// 코드도 깔끔해지고 nullPointerException 발생도 줄어든다 - 안정화

null 전달하지마라

메서드 null 반환보다 메서드 null 전달이 더 나쁨
정상적인 인수로 null을 기대하는 API가 아니라면 메서드로 null 전달하는 코드는 최대한 피한다
일반적으로 대다수의 프로그래밍 언어들은 파라미터로 들어온 null에 대해 적절한 방법을 제공하지 못한다.
가장 이성적인 해법은 null을 파라미터로 받지 못하게 하는 것이다.

null이 전달되면 NullPointerException 발생!

public class MetricsCalculator {
  public double xProjection(Point p1, Point p2) {
    return (p2.x – p1.x) * 1.5;
  }

어떻게 고치는가?

// 1. 새로운 예외 유형을 만들어 던지기
// NullPointerException은 안나지만 InvalidArgumentException를 잡아내는 처리기 필요
public class MetricsCalculator {
  public double xProjection(Point p1, Point p2) {
    if(p1 == null || p2 == null){
      throw InvalidArgumentException("Invalid argument for MetricsCalculator.xProjection");
    }
    return (p2.x – p1.x) * 1.5;
  }

// 2. assert문 사용
// 문서화가 잘되어 코드 가독성은 좋으나 문제 해결은 여전함
// null 전달시 실행오류 여전함
public class MetricsCalculator {
  public double xProjection(Point p1, Point p2) {
    assert p1 != null : "p1 should not be null";
    assert p2 != null : "p2 should not be null";
    
    return (p2.x – p1.x) * 1.5;
  }
}

null 인수의 자체가 문제

대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없음
애초에 null을 넘기지 못하도록 금지하는 정책이 함리적
인수로 null이 넘어오면 코드에 문제가 있는 것

결론

클린코드는 읽기도 좋지만 안정성도 좋야야 하며 상충하는 목표가 아님
오류처리를 프로그램 로직과 분리해서 독자적 사안으로 고려 → 튼튼한 클린코드 작성 가능
독립적 추론 가능 , 코드 유지보수성 올라감

실무 예외 처리 패턴

제로베이스에서 한달 한권의 내용

1. getOrElse

예외 대신 기본 값 리턴
1. null이 아닌 기본값 : 위의 employee 예제
2. 도메인에 맞는 기본 값 : 아래 설명

나쁜 예

UserLevel userLevel = null;
try {
  User user = user.Repository.findByUserId(userId);
  userLevel = user.getUserLevel();
} catch (UserNotfoundException e) {
  userLevel = UserLevel.BASIC;
}
// 호출부에서 예외 처리를 통해 userLevel 값을 처리한다
// 코드를 계속 읽어나가면서 논리적인 흐름이 끊긴다

좋은 예

// 호출부 - 단순해짐
UserLevel userLevel = userService.getuserLevelOrDefault(userId);
//////////////////////////////////////////////////

public class UserService {
  public static final UserLevel USER_BASIC_LEVEL = UsrLevel.BASIC;
  
  public UserLevel getUserLevelOrdefault(Long userId) {
    try {
      User user = userRepository.findByUserId(userId);
      return user.getUserLevel();
    } catch(UserNotFoundException e) {
      return USER_BASIC_LEVEL;
    }
  }
}

예외처리를 데이터 제공 쪽 처리 → 호출부가 심플, 단순해짐
코드 리딩시 논리적 흐름이 끊기지 않음
도메인에 맞는 default 값을 도메인 서비스에서 관리

getOrElseThrow

기본값이 없으면 null대신 예외를 던진다

나쁜 예

User user = userRepository.findByUseId(userId);
if (user != null) {
  // user를 이용한 처리
}

user를 사용하는 쪽에서 매번 체크를 해야한다.
가독성 뿐만 아니라 안정성도 떨어진다.
null 체크가 빠진 부분이 발생할 수 있다.

좋은 예

// 호출부
User user = user.Service.getUserOrElseThrow(userId);
//////////////////////////////////

public class UserService {
  public static final UserLevel USER_BASIC_LEVEL = UsrLevel.BASIC;
  
  public User getUserOrElseThrow(Long userId) {
    User user = userRepository.findByUserId(userId);
    if (user == null) {
      throw new IllegalArgumentException("User is not found. userId = " + userId)
    }
    return user;
    }
  }
}

기본 값이 없는 경우임
기본 값이 없으면 null 체크 → 데이터가 없으면 예외 던짐
호출부에서 매번 null 체크가 필요 없음
호출부의 가독성 올라감

실무에선 보통 자신의 예외를 정의

public class MyProjectException extends RuntimeException {
  private MyErrorCode errorCode;
  private String errorMessage;
  
  public MyProjectException(MyErrorCode errorCode) {
    //
  }
  
  public MyProjectException(MyErrorCode errorCode, String errorMessage) {
    //
  }
}

public enum MyErrorCode {
  private String defaultErrorMessage;
  
  INVALID_REQUEST("잘못된 요청입니다."),
  DUPLICATED_REQUEST("기존 요청과 중복되어 처리할 수 없습니다."),
  // ...
  INTERNAL_SERVER_ERROR("처리 중 에러가 발생했습니다.");
}

//호출부 - 클라이언트가 아닌 내부 null 처리 부분
if (request.getUserName() == null) {
  throw new MyProjectException(ErrorCode.INVALID_REQUEST, "userName is null");
}

장점

에러 로그에서 stacktrace할 때 자신의 예외라는 것을 바로 인지 가능
다른 라이브러리 에러와 섞이지 않음 : 다른 IllegalArgumentException과 분리
우리 도메인에서 발생한 에러 종류를 나열 가능

[Clean Code] Ⅵ. 객체와 자료구조

Wed, 09 Feb 2022 00:53:10 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅵ. 객체와 자료구조

Intro

변수를 비공개private로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 충동이든 변덕이든, 변수 타입이나 구현을 맘대로 바꾸고 싶어서다. 그렇다면 어째서 수많은 프로그래머가 조회get 함수와 설정set 함수를 당연하게 공개public해 비공개 변수를 외부에 노출할까?

인트로가 괜춘하다
한번 생각해보자.. 일단 캡슐화
캡슐화 - 외부에 들어나지 않도록
다수가 함께 작업하는 프로젝트의 경우 해당 자료를 보호할 수 있도록 자료 보호

자료 추상화

6-1 구체적 Point 클래스 : 구현 회부 노출

public class Point { 
  public double x; 
  public double y;
}

6-2 추상적인 Point 클래스 : 구현을 완전히 숨긴다

public interface Point {
  double getX();
  double getY();
  void setCartesian(double x, double y); 
  double getR();
  double getTheta();
  void setPolar(double r, double theta); 
}

인터페이스 포인트(6-2)

어떤 좌표계인지는 알 수가 없다
자료구조를 명백히 표현하며 그 이상도 표현한다
- 클래스 메서드가 접근 정책 강제
- 좌표를 읽을 때는 각 값을 개별적으로 읽어야 한다
- 좌표 설정시에는 두 값을 한꺼번에 설정해야 가능

클래스 포인트(6-1)

확실하게 직교좌표계를 사용
개별적으로 좌표값 읽고 설정하게 강제
구현을 노출 : 변수는 private인데 getter,setter가 있어도 마찬가지로 외부 노출로 본다

6-2 > 6.1

진정한 클래스

형식 논리에 치우쳐 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지 않는다
변수 사이에 함수 계층이 들어간다고 구현이 저절로 감춰지지 않는다
진정한 의미의 클래스 : 추상 인터페이스를 제공해서 사용자가 구현을 모르는 채 자료의 핵심 조작 가능
추상적인 개념으로 표현 >>> 자료 세부 공개하기
인터페이스나 getter,setter 설정으로 추상화가 되지 않음
생각없는 getter/setter를 추가하는 방법이 가장 나쁘다
개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다

자료/객체 비대칭

특징 : 사소한 차이지만 영향은 엄청남

객체 : 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개
자료 구조 : 자료를 그대로 공개하며 별다른 함수를 제공하지 않음

procedural Shape

public class Square { 
  public Point topLeft; 
  public double side;
}

public class Rectangle { 
  public Point topLeft; 
  public double height; 
  public double width;
}

public class Circle { 
  public Point center; 
  public double radius;
}

public class Geometry {
  public final double PI = 3.141592653589793;
  
  public double area(Object shape) throws NoSuchShapeException {
    if (shape instanceof Square) { 
      Square s = (Square)shape; 
      return s.side * s.side;
    } else if (shape instanceof Rectangle) { 
      Rectangle r = (Rectangle)shape; 
      return r.height * r.width;
    } else if (shape instanceof Circle) {
      Circle c = (Circle)shape;
      return PI * c.radius * c.radius; 
    }
    throw new NoSuchShapeException(); 
  }
}

procedural Shape

GeoMetry 클래스는 3가지 도형 클래스 다룬다
각 클래스는 간단한 자료 구조, 메서드 X
도형이 동작하는 방식 GeoMetry클래스에서 구현
객체 지향에서는 상상할 수 없는 클래스
변화시?
- Geometry에 둘레 길이 구하는 함수 추가? → 3가지 도형 클래스는 아무 영향이 없음
- 반대로 새 도형을 추가하고 싶다면? → Geomtry의 함수를 모두 고쳐야 함

Polymorphic Shape

public class Square implements Shape { 
  private Point topLeft;
  private double side;
  
  public double area() { 
    return side * side;
  } 
}

public class Rectangle implements Shape { 
  private Point topLeft;
  private double height;
  private double width;

  public double area() { 
    return height * width;
  } 
}

public class Circle implements Shape { 
  private Point center;
  private double radius;
  public final double PI = 3.141592653589793;

  public double area() {
    return PI * radius * radius;
  } 
}

Polymorphic Shape

객체지향적
area() : polymorphic method
Geomtry클래스 필요없음
변화시?
- 새 도형을 추가하고 싶다면? → 기존 함수 영향 zero
- Geometry에 둘레 길이 구하는 함수 추가? → 3가지 도형 클래스 모두 뜯어 고쳐야 함

해결법 ?VISIOR 패턴?
주로 상속없이 클래스에 메서드를 효과적으로 추가하기 위해 사용
합성 객체의 내부 구조가 VISITOR에 Open됨 → 캡슐화 위반 문제점

procedural Shape VS Polymorphic Shape
상호 보완적이며 사실상 반대 → 객체와 자료구조는 근본적으로 양분됨
서로의 장점

(자료구조를 사용하는) 절차적 코드 : 기존 자료 구조 변경 없이 새함수 추가
OOP 코드 : 기존 함수 변경 없이 새 클래스 추가 쉬움
서로의 단점
(자료구조를 사용하는) 절차적 코드 : 새로운 자료 추가 어려움(모든 함수 수정 필요)
OOP 코드 : 새로운 함수를 추가하기 어려움(모든 클래스를 고쳐야 함)
결론
모든 것이 객체라는 생각은 미신
때로는 단순한 자료 구조+절차적 코드가 가장 적합한 상황도 존재

디미터 법칙

상세 내용은 실용주의 프로그래머 227 p

잘 알려진 휴리스틱
- 휴리스틱 : 경험에 기반하여 문제를 해결하거나 학습하거나 발견해 내는 방법
모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다
- 객체는 자료를 숨기고 함수를 공개
- 즉 조회 함수로 내부 구조를 공개하면 안된다는 의미
- ex) 모든 getter 사용? 내부 구조가 노출되므로 안된다는 뜻
클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다
- 클래스 C
- f가 생성한 객체
- f 인수로 넘어온 객체
- C 인스턴스 변수에 저장된 객체
- 주의: 위 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출 X

train wreck = 기차 충돌

아파치 프레임워크의 train wreck처럼 보이는 함수

1	final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

위와 같은 코드는 디미터 법칙이 안지켜지는 것으로 보여짐
ctxt가 Options를 포함 → Options가 ScratchDir 포함 → ScratchDir이 AbsolutePath를 포함
→함수가 하나가 아는 지식이 굉장히 많음 → 해당 함수가 많은 객체를 탐색 가능함
이렇게 나누는 것이 좋다
1
2
3
Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();
첫번째 예제가 디미터 법칙을 위반했는가?
ctx, Options, ScratchDir이 객체인가 자료구조인지에 따라 달림
- 객체라면? 내부구조를 숨겨야하므로 확실하게 디미터 법칙 위반
- 자료구조라면? 당연히 내부 구조를 노출해야함 → 디미터 법칙 적용 안됨
첫번째 예제의 혼란의 이유? Getter 사용 덕분
이런식으로 구현되면 디미터 법칙을 거론할 필요가 없다
1
final String outputDir = ctxt.options.scratchDir.absolutePath;
자료구조는 무조건 함수없이 공개 변수만 포함, 객체는 비공개 변수+공개함수를 포함하면 문제가 간단해진다 ‘

잡종구조

단순한 자료 구조에도 getter,setter를 요구하는 프레임워크나 표준(bean등;)이 존재 → 원흉
이런 혼란으로 때때로 절반은 객체, 절반은 자료구조인 잡종 구조가 등장
잡종 구조는 중요기능 수행 함수 + 공개변수 + getter,setter도 존재
getter,setter덕에 미공개 변수를 사용하고픈 유혹에 빠지기 쉬움 → 리팩토링 책에서는 기능 욕심(Feature Envy)라고 함
새로운 함수는 물론이고 새로운 자료구조도 추가하기 어려움 → 양쪽의 단점만 모아놓은 구조
잡종 구조는 되도록 피하는 편이 좋다
프로그그래머 함수/타입을 보호할지 공개할지 확신하지 못하거나(아니면 무지해서) 어중간하게 내놓은 설계에 불과

구조체 감추기

//1
ctxt.getAbsolutePathOfScratchDirectoryOption();
//2
ctxt.getScratchDirectoryOption().getAbsolutePath();

문제점 : 둘 다 좋은 방법이 아님

1번은 ctxt객체에 공개해야하는 메서드가 너무 많아짐
2번은 getScratchDirectoryOption()가 객체가 아닌 자료구조 반환임을 가정

ctxt가 객체라면 무언가를 해라 라고 해야지 속을 드러내라고 하면 안됨

임시 디렉토리의 절대경로가 왜 필요한가? 절대경로를 얻어 어디에 쓸것인가?

한참 아래의 같은 모듈에서 가져온 코드

// 추상화 수준이 뒤섞여서 불편
// 점과 슬래시와 파일 확장자등이 부주의하게 섞여있음
String outFile = outputDir + "/" + className.replace('.', '/') + ".class"; 
FileOutputStream fout = new FileOutputStream(outFile); 
BufferedOutputStream bos = new BufferedOutputStream(fout);
// 결론 : 임시파일을 생성하기 위해 절대 경로가 필요함

ctxt 객체에 임시 파일을 생성하라고 시키면 어떨까?

1	BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);

객체에 맡기기 적당한 임무로 보임
ctxt는 내부 구조를 드러내지 않으며, 모듈은 자신이 몰라야 하는 여러 객체를 탐색할 필요가 없다.
따라서 디미터 법칙을 위반하지 않는다.

자료 전달 객체

자료 구조의 전형적인 형태 : DTO

공개 변수만 존재 , 함수 없음
DTO라고도 한다
굉장히 유용한 구조체 : DB 통신, 소켓 메시지 구문 통신
흠히 DB의 가공되지 않은 정보를 어플리케이션 코드의 객체로 변환과정에서 가장 처음으로 사용하는 구조
getter/setter를 가진다

좀더 일반적인 형태 : bean 구조

데이터 표현이 목적인 자바 객체
private 변수 + getter, setter
일종의 사이비 캡슐화, 별다른 이득이 없음
zh

활성 레코드 : DTO의 특수 형태

위의 dto나 bean구조의 자료구조 + 탐색 함수(save or find) 제공
DB 테이블이나 다른 소스에서 자료를 직접 변환한 결과 → DB row를 객체에 매핑하는 패턴
엔티티와 다르게 생겼음~
불행히도 활성 레코드에 비지니스 규칙 메서드를 추가한 자료구조를 객체 취급하는 개발자가 흔함
잡종 구조가 나오므로 바람직하지 않음
해결책
- 활성 레코드는 자료 구조로 취급해야한다
- 비지니스 규칙을 담으면서 내부 자료를 숨기는 객체(엔티티등)는 따로 생성
객체가 많아지면 복잡해짐, 가까운 곳에 관련 로직이 있는 것이 좋음
→ 현업에서는 엔티티에 간단한 메서드를 추가해 사용
→ 현업에서는 엔티티에 간단한 메서드를 추가해 사용

결론

객체는 동작을 공개하고 자료를 숨긴다.
그래서 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다.

자료 구조는 별다른 동작 없이 자료를 노출한다.
그래서 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다.

(어떤) 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다.
다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다.
우수한 소프트웨어 개발자는 편견 없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.

김과장이 햇갈려서 질의 응답에 많은 시간을 허비
디미터의 법칙을 객체가 아닌 메서드의 관점으로 착각해서 체인메서드들을 쓰면 안되는 것으로 착각함
객체의 관점으로 봐야 함을 설명하는데도 이해를 못해서 많은 시간 허비
다음 번 알려줄 때에는 해당 부분을 햇갈리지 않도록 부연 설명을 미리 준비 해야 할 듯

[Clean Code] Ⅴ. 형식 맞추기

Wed, 09 Feb 2022 00:52:42 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅴ.형식 맞추기(Formatting)

목적

코드 형식은 중요하다

너무 중요하지만 융통성 없이 맹목적으로 따르면 안된다
코드 형식은 의사소통의 일환이며 개발자의 1차적 의무
돌아가는 코드가 1차적인 의무가 아님
오늘 구현한 코드의 가독성은 앞으로의 코드 품질에 큰 영향
원래 코드는 사라져도 스타일과 규율은 사라지지 않고 유지보수에 계속 영향을 미친다

적절한 행 길이를 유지하라

책에서는 여러 프로젝트의 파일 크기를 조사한 결과를 보여준다
대표적인 예시 - FitNesse

5만 라인이 넘는 시스템
500줄이 넘어가는 파일 없으며, 대다수 200줄 미만
일반적으로 큰 파일 보다 작은 파일이 이해가 쉽다

신문기사처럼 작성하라

좋은 신문 기사의 모습

최상단에 기사를 몇 마디로 요약하는 표제
독자는 위 아래로 기사를 읽으며 표제를 읽고 기사를 읽을지 결정
첫 문단 : 전체 기사 내용 요약, 세부사항 숨기고 큰 그림 위주로 보여줌
쭉 읽어 나가면? : 이름, 발언, 주장등 세부사항이 드러남

소스파일도 비슷하게 작성

이름 : 간단하면서도 이름만 보고 올바른 모듈인지 판단되게 신경써서 짓는다
소스 파일 첫 부분 : 고차원 개념과 알고리즘 설명
아래로 내려갈 수록 의도가 세세하게 묘사됨
마지막에 가장 저차원 함수와 세부내역

생각해볼 점

신문은 다양한 기사로 이루어짐
대다수 기사가 아주 짧으며 어떤 기사는 조금 길며 한 면을 채우는 기사는 매우 드물다
신문이 세부내ㅔ역을 무작위로 섞은 긴 기사 하나만 싣는다면 아무도 읽지 않는다
소스코드와 비교하면서 생각해보자

개념은 빈 행으로 분리

거의 모든 코드의 읽는 순서 : 왼쪽→오른쪽, 위→아래
각 줄 : 수식이나 절을 나타낸다
여러 줄의 묶음 : 완결된 생각 하나
생각 사이에는 빈 행을 넣어 분리해야 한다

빈 행이 없으면 가독성이 떨어진다

빈 행 없을 때

package fitnesse.wikitext.widgets;
import java.util.regex.*;
public class BoldWidget extends ParentWidget {
  public static final String REGEXP = "'''.+?'''";
  private static final Pattern pattern = Pattern.compile("'''(.+?)'''",
    Pattern.MULTILINE + Pattern.DOTALL);
  public BoldWidget(ParentWidget parent, String text) throws Exception {
    super(parent);
    Matcher match = pattern.matcher(text); match.find(); 
    addChildWidgets(match.group(1));}
  public String render() throws Exception { 
    StringBuffer html = new StringBuffer(""); 
    html.append(childHtml()).append(""); 
    return html.toString();
  } 
}

빈 행 있을 때

package fitnesse.wikitext.widgets;

import java.util.regex.*;

public class BoldWidget extends ParentWidget {
  public static final String REGEXP = "'''.+?'''";
  private static final Pattern pattern = Pattern.compile("'''(.+?)'''", 
    Pattern.MULTILINE + Pattern.DOTALL
  );
  
  public BoldWidget(ParentWidget parent, String text) throws Exception { 
    super(parent);
    Matcher match = pattern.matcher(text);
    match.find();
    addChildWidgets(match.group(1)); 
  }
  
  public String render() throws Exception { 
    StringBuffer html = new StringBuffer(""); 
    html.append(childHtml()).append(""); 
    return html.toString();
  } 
}

세로 밀집도

줄바꿈이 개념 분리라면? 세로 밀집도는 연관성을 의미
밀접한 코드행은 세로로 가까이 놓여야 한다
연관성이 있는 부분을 주석등의 추가로 멀리 떨어뜨리면 한 눈에 들어오지 않게 된다

연관성 부분에 주석이 들어가 변수끼리 멀어진 경우

ublic class ReporterConfig {
  /**
  * The class name of the reporter listener 
  */
  private String m_className;
  
  /**
  * The properties of the reporter listener 
  */
  private List m_properties = new ArrayList();
  public void addProperty(Property property) { 
    m_properties.add(property);
  }

주석 제거로 한 눈에 들어오게 된 클래스

public class ReporterConfig {
  private String m_className;
  private List m_properties = new ArrayList();
  
  public void addProperty(Property property) { 
    m_properties.add(property);
  }

수직 거리

이런 경험이 있는가?

함수 연관 관계, 동작을 이해하려고 함수를 오가며 소스 파일을 위로 오가는데 못찾게 되는 경험?
함수/변수가 정의된 코드를 찾으려 상속 관계를 줄줄히 올라간 경험?
시스템을 이해하려는 목적과 달리 각 조각이 어디에 있는지 찾고 기억해야 함
시간과 노력을 엄청나게 소모
서로 밀접한 개념은 세로로 가까이 둬야 한다
두 개념이 서로 다른 파일에 속한다면 규칙이 통하지 않는다.
타당한 근거가 없다면 밀접한 개념은 한 파일에 → protected 변수를 피해야 하는 이유 중 하나
연관성 : 한 개념을 이해하는데 다른 개념이 중요한 정도
연관성 있는 개념이 떨어져있으면 읽는 사람이 파일/클래스를 뒤져야함

변수 선언

변수는 사용 위치에 최대한 가까이 선언

좋은(작은)함수는 지역 변수 각 함수 맨 처음에 선언

JUnit 4.3.1의 함수 예시

private static void readPreferences() {
  InputStream is = null; // 맨 처음에 선언
  try {
    is = new FileInputStream(getPreferencesFile()); 
    setPreferences(new Properties(getPreferences())); 
    getPreferences().load(is);
  } catch (IOException e) { 
    try {
      if (is != null) 
        is.close();
    } catch (IOException e1) {
    } 
  }
}

루프 제어 변수는 : 흔히 루프 안에 선언

public int countTestCases() { 
  int count = 0;
  for (Test each : tests) //이렇게~
    count += each.countTestCases(); 
  return count;
}

긴 함수 : 블록 상단이나 루프 직전에 변수 선언 사례
(아주 드문 케이스)

TestNG의 아주 긴 함수 중 일부

for (XmlTest test : m_suite.getTests()) {
  TestRunner tr = m_runnerFactory.newTestRunner(this, test); //이렇게 
  tr.addListener(m_textReporter); 
  m_testRunners.add(tr);

  invoker = tr.getInvoker();
  
  for (ITestNGMethod m : tr.getBeforeSuiteMethods()) { 
    beforeSuiteMethods.put(m.getMethod(), m);
  }

  for (ITestNGMethod m : tr.getAfterSuiteMethods()) { 
    afterSuiteMethods.put(m.getMethod(), m);
  } 
}

인스턴스 변수

자바 :클래스 맨 처음에 선언
C++ : scissors rule(모든 인스턴스 변수를 클래스 마지막에 선언한다)
중요한 것은 인스턴스 변수를 모으고 어디서 찾을 수 있는지 모두가 알고 있어야 함

변수간 세로 거리 X → 정상적인 클래스는 대다수의 클래스 메서드가 인스턴스 변수 사용

JUnit4.3.1의 TestSuite 클래스 일부분


public class TestSuite implements Test {
  static public Test createTest(Class theClass,
                  String name) {
    ... 
  }

  public static Constructorextends TestCase> 
  getTestConstructor(Classextends TestCase> theClass) 
  throws NoSuchMethodException {
    ... 
  }

  public static Test warning(final String message) { 
    ...
  }
  
  private static String exceptionToString(Throwable t) { 
    ...
  }
  
  private String fName; //이거 

  private Vector fTests= new Vector(10); //이것도

  public TestSuite() { }
  
  public TestSuite(final Class theClass) { 
    ...
  }

  public TestSuite(Class theClass, String name) { 
    ...
  }
  
  ... ... ... ... ...
}

종속 함수 : 한 함수가 다른 함수 호출

세로로 가까이 배치 - 연관성끼리
가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치 - 자연스럽게 읽히도록
일관적으로 규칙 적용 한다면 → 읽는 사람은 호출된 함수가 잠시 뒤에 정의되리라고 예측

호출되는 함수 찾기가 쉬어지며 모듈 전체의 가독성도 올라간ㄷ

FitNesse의 일부 코드

// 가장 먼저 호출하는 함수가 바로 아래 정의
// 그다음 호출하는 함수는 그 다음 정의

public class WikiPageResponder implements SecureResponder { 
  protected WikiPage page;
  protected PageData pageData;
  protected String pageTitle;
  protected Request request; 
  protected PageCrawler crawler;
  
  public Response makeResponse(FitNesseContext context, Request request) throws Exception {
    String pageName = getPageNameOrDefault(request, "FrontPage");  
    loadPage(pageName, context); 
    if (page == null)
      return notFoundResponse(context, request); 
    else
      return makePageResponse(context); 
    }

  private String getPageNameOrDefault(Request request, String defaultPageName) {
    String pageName = request.getResource(); 
    if (StringUtil.isBlank(pageName))
      pageName = defaultPageName;

    return pageName; 
  }
  
  protected void loadPage(String resource, FitNesseContext context)
    throws Exception {
    WikiPagePath path = PathParser.parse(resource);
    crawler = context.root.getPageCrawler();
    crawler.setDeadEndStrategy(new VirtualEnabledPageCrawler()); 
    page = crawler.getPage(context.root, path);
    if (page != null)
      pageData = page.getData();
  }
  
  private Response notFoundResponse(FitNesseContext context, Request request)
    throws Exception {
    return new NotFoundResponder().makeResponse(context, request);
  }
  
  private SimpleResponse makePageResponse(FitNesseContext context)
    throws Exception {
    pageTitle = PathParser.render(crawler.getFullPath(page)); 
    String html = makeHtml(context);
    SimpleResponse response = new SimpleResponse(); 
    response.setMaxAge(0); 
    response.setContent(html);
    return response;
  } 
    /*makeResponse 함수에서 호출하는 getPageNameOrDefault함수 안에서 "FrontPage" 상수를 사용하지 않고,
상수를 알아야 의미 전달이 쉬워지는 함수 위치에서 실제 사용하는 함수로 상수를 넘겨주는 방법이
가독성 관점에서 훨씬 더 좋다*/

/*
그렇다면 getPageNameOrDefault 함수안에서 isBlank 판단 이후 상수를 사용하는게 좋아 보일 듯
*/
...

위 코드는 상수를 적절한 수준에 두는 좋은 예제
- 예)
  - makeResponse 함수에서 호출하는 getPageNameOrDefault함수 안에서 “FrontPage” 상수를 사용하지 않고
  - getPageNameOrDefault 함수안에서 isBlank 판단 이후 상수를 사용
- 위의 예에는 : 기대와 달리 잘 알려진 상수가 적절하지 않은 저차원 함수에 묻힌다
- [G35-p394]: 구성 정보는 최상위 단계에 두어라 : 상수를 저차원 함수에 숨기지 말고 고차원에 두어야 저차원 함수를 뒤적이지 않게 됨
- 상수를 알아야 마땅한 함수에서 실제 사용하는 함수로 상수를 넘겨주는 방법이 더 좋다

개념적 유사성

개념적인 친화도가 높은 코드는 서로를 끌어당김 → 친화도가 높을 수록 가까이 배치
친화도 요인 : 종속성, 변수 사용, 비슷한 동작을 수행하는 일군의 함수

Junit4.3.1 코드

public class Assert {
  static public void assertTrue(String message, boolean condition) {
    if (!condition) 
      fail(message);
  }

  static public void assertTrue(boolean condition) { 
    assertTrue(null, condition);
  }

  static public void assertFalse(String message, boolean condition) { 
    assertTrue(message, !condition);
  }
  
  static public void assertFalse(boolean condition) { 
    assertFalse(null, condition);
  } 
...

개념적 친화도가 매우 높은 함수들임
- 명명법이 똑깥고 기본 기능이 유사하고 간단
- 서로가 서로를 호출하는 것은 부차적 요인 → 종속 관계가 없어도 가까이 배치할 함수

세로 순서

함수 호출 종속성 아래 방향 유지 → 자연스럽게 모듈이 고차원→저차원으로 자연스럽게 내려감
- 호출되는 함수를 호출하는 함수보다 나중에 배치
- C, C++, Pascal과 정확히 반대 : 함수 호출을 위해 적어도 미리 선언은 해놔야하는 언어
신문 기사와 같이
- 가장 중요한 개념 가장 먼저 표현 : 세세한 사항을 최대한 배제
- 세세한 사항은 가장 마지막에 표현
- 독자들이 첫 함수 몇 개만 읽어도 개념 파악이 되도록
- 좋은 목록 3-7(ch3마지막), 15-5(p338, )

가로 형식 맞추기

과거 훌러리스(Hollerith) :80자 제한
- 가로 80, 세로 12단 천공카드, 기계를 고안한 통계학자
가급적 짧은 행이 바람직함
120자 정도로 행 길이 제한 권고 - 인텔리 제이 120으로 되어있음

가로 공백과 밀집도

가로 공백 : 밀접한 개념, 느슨한 개념 표현 가능

private void measureLine(String line) { 
  lineCount++;
  int lineSize = line.length(); // 할당 연산자 좌우로 공백 → 좌우 요소가 확실하게 구분.
  totalChars += lineSize; 
  
  // 괄호 안의 인수끼리는 쉼표 뒤의 공백을 통해 인수가 별개라는 사실을 보여준다.
    // 함수명과 괄호는 공백없음 - 함수와 인수의 밀접함
    // 괄호 안의 인자끼리는 쉼표 뒤의 공백 → 쉼표 강조 → 각 인자가 별개라는 의미
  lineWidthHistogram.addLine(lineSize, lineCount);
  recordWidestLine(lineSize);
}

연산자의 우선순위를 강조하기 위해서도 공백을 사용

불행히 IDE의 포매터가 나중에 해당 공백을 삭제하는 경우가 흔함
포매터 대부분 연산자 우선순위 고려 불가하므로 수식에 같은 간격 적용하기 때문

가로 정렬

밥아저씨의 정렬
- 어셈블리어 영향

public class FitNesseExpediter implements ResponseSender {
  privateSocket        socket;
  private InputStream         input;
  private OutputStream        output;
  private Reques        request; 
  private Response         response;
  private FitNesseContex      context; 
  protected long        requestParsingTimeLimit;
  private long        requestProgress;
  private long        requestParsingDeadline;
  private boolean        hasError;

    public FitNesseExpediter(Socket          s,
                             FitNesseContext context) throws Exceptions
    {
        this.context =              context;
        socket =                    s;
        input =                     s.getInputStream();
        output =                    s.getOutputStream();
        requestParsingTimeLimit =   10000;
    }

좋지 않은 정렬

보기엔 깔끔해 보여도 코드의 엉뚱한 부분이 강조되 진짜 의도가 가려지게 됨
변수유형대신 변수 이름부터 읽게 됨
할당문 : 할당 연산자가 눈에 안보이고 우측 피연산자만 눈에 보임
대다수의 포매터는 위의 정렬을 무시

선언문/할당문 별도 정렬 필요 X

정렬이 필요할 정도로 선언부가 길다면 클래스를 쪼개야 한다

들여쓰기

Scope를 한눈에 표현 : 프로그래머들이 크게 의존

들여쓰기 무시하기

들여쓰기를 무식하고 싶은 유혹들 : 간단한 if, while, 짧은 함수

들여쓰기 안하고 한 행에 범위를 뭉뚱그린 코드

public class CommentWidget extends TextWidget {
  public static final String REGEXP = "^#[^\r\n]*(?:(?:\r\n)|\n|\r)?";
  
  public CommentWidget(ParentWidget parent, String text){super(parent, text);}
  public String render() throws Exception {return ""; }  //멋져보이나 아니야
}

한 줄 함수라도 들여쓰기를 하자

public class CommentWidget extends TextWidget {
  public static final String REGEXP = "^#[^\r\n]*(?:(?:\r\n)|\n|\r)?";
  
  public CommentWidget(ParentWidget parent, String text){
    super(parent, text);
  }
  
  public String render() throws Exception {
    return ""; 
  } 
}

가짜 범위

가능한 피하라
피하지 못할 땐 밑에처럼
빈 while 문을 어쩔수 없이 쓸때는 괄호로 감싸고 새로운 행에 세미콜론
1
2
while (dis.read(buf, 0, readBufferSize) != -1)
;

팀 규칙

팀에 속해있다면 팀 규칙이 가장 우선시 되고 선호되어야 한다
팀은 한가지 규칙에 합의 필요
- sw 일관적인 코딩스타일 적용 필요
좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이뤄지고, 읽기 쉬운 문서는 스타일이 일관적이고 매끄러워야 한다.

밥 아저씨의 형식 규칙

이러한 규칙의 예제

코드 자체가 구현 문서가 되는 예제

public class CodeAnalyzer implements JavaFileAnalysis { 
  private int lineCount;
  private int maxLineWidth;
  private int widestLineNumber;
  private LineWidthHistogram lineWidthHistogram; 
  private int totalChars;
  
  public CodeAnalyzer() {
    lineWidthHistogram = new LineWidthHistogram();
  }
  
  public static List findJavaFiles(File parentDirectory) { 
    List files = new ArrayList(); 
    findJavaFiles(parentDirectory, files);
    return files;
  }
  
  private static void findJavaFiles(File parentDirectory, List files) {
    for (File file : parentDirectory.listFiles()) {
      if (file.getName().endsWith(".java")) 
        files.add(file);
      else if (file.isDirectory()) 
        findJavaFiles(file, files);
    } 
  }
  
  public void analyzeFile(File javaFile) throws Exception { 
    BufferedReader br = new BufferedReader(new FileReader(javaFile)); 
    String line;
    while ((line = br.readLine()) != null)
      measureLine(line); 
  }
  
  private void measureLine(String line) { 
    lineCount++;
    int lineSize = line.length();
    totalChars += lineSize; 
    lineWidthHistogram.addLine(lineSize, lineCount);
    recordWidestLine(lineSize);
  }
  
  private void recordWidestLine(int lineSize) { 
    if (lineSize > maxLineWidth) {
      maxLineWidth = lineSize;
      widestLineNumber = lineCount; 
    }
  }

  public int getLineCount() { 
    return lineCount;
  }

  public int getMaxLineWidth() { 
    return maxLineWidth;
  }

  public int getWidestLineNumber() { 
    return widestLineNumber;
  }

  public LineWidthHistogram getLineWidthHistogram() {
    return lineWidthHistogram;
  }
  
  public double getMeanLineWidth() { 
    return (double)totalChars/lineCount;
  }

  public int getMedianLineWidth() {
    Integer[] sortedWidths = getSortedWidths(); 
    int cumulativeLineCount = 0;
    for (int width : sortedWidths) {
      cumulativeLineCount += lineCountForWidth(width); 
      if (cumulativeLineCount > lineCount/2)
        return width;
    }
    throw new Error("Cannot get here"); 
  }
  
  private int lineCountForWidth(int width) {
    return lineWidthHistogram.getLinesforWidth(width).size();
  }
  
  private Integer[] getSortedWidths() {
    Set widths = lineWidthHistogram.getWidths(); 
    Integer[] sortedWidths = (widths.toArray(new Integer[0])); 
    Arrays.sort(sortedWidths);
    return sortedWidths;
  } 
}

정리

포맷팅이 중요한 이유

가독성에 필수적
아마추어적으로 보이지 않는다
잘못된 포맷팅으로 코드를 잘못 이해해서 버그를 발생할 위험을 줄일 수 있음
어렸을때 띄어쓰기, 문법 공부 - > 이게 잘 되어 있으면 글이 잘 읽힌다
기본 중의 기본

클린 코드 포매팅

적절한 길이
- 200라인 이하 권장 , 500라인 이하 권장
- 현업에서 실제 대부분의 코드도 200라인 유지
- 200라인이 넘어가면 클래스가 여러가지 일을 수행할 확율이 높은 → SRP 위배
밀접 개념 가까이
- 행 묶음은 완결된 생각 하나 표현함 → 개념은 빈 행으로 분리
- 변수는 사용되는 위치에서 최대한 가까이 선언

Java Class Declarations

오라클 : https://www.oracle.com/java/technologies/javase/codeconventions-fileorganization.html#1852
- static variable → instance variables → Constructors → Methods
- 변수는 : public → protected → package → private 순서
- 메서드
  - 스코프와 접근에 따라 그루핑이 되어야 한
  - public 메서드에서 private 메서드는 그 아래에 둔다 → 그래야 가독성 높아짐
  - 가독성 위주로 그룹핑

Team Coding Convention

코딩 스타일에 관한 약속
개발 언어의 컨벤션이 우선, 애매하면(변수명) 팀 컴벤션을 따른다
- 예) enum타입으로 사용하는 varchar타입의 경우 컬럼명은 _type로 끝나도록 네이밍한다
없다면 함께 만들어가는게 좋다
참고할 만한 컨벤션
- mysql 컨벤션 : snake_case
- Google Java Style Guide: https://google.github.io/styleguide/javaguide.html
  - 현업에서 많이 참고
- 네이버 헥데이 코딩 컨벤션 : https://naver.github.io/hackday-conventions-java
  - 네이버에서 헥데이라는 행사에서 쓰기 위한 컨벤션
  - 네이버 현업과 비슷하고 한글로 되어 있음

[Clean Code] Ⅳ. 주석

Wed, 09 Feb 2022 00:52:21 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅳ. 주석

나쁜 코드에 주석을 달지 말아라. 새로 짜라.
브라이언 W. 커니핸 P.J 플라우거

주석

잘달린 주석 : 그 어떤 정보보다 유용
경솔하고 근거 없는 주석 : 코드 이해 어렵게 만듬
오래되고 조잡한 주석 : 거짓과 잘못된 정보를 퍼뜨려 악영향

주석은 필요악

주석은 순수하게 선하지 않다
프로그래밍 언어 자체가 표현력이 풍부하다면
아니면 개발자(우리자신)가 프로그래밍 언어를 사용해 의도를 표현할 능력이 있다면
주석은 전혀 필요하지 않을 것이다
주석은 실패를 의미하며 줄이려 노력해야 한다
- 주석이 없이는 자신을 표현을 할 수 없기에 사용
- 주석의 내용을 코드로 의도를 표현하는 것이 가장 좋다
- 코드는 변화하고 진화하며 일부가 옮겨지고 조각이 나뉘거나 병합된다
- 주석은 코드를 따라가지 못한다 : 주석을 유지보수 하는 것은 불가능
- 코드만이 정확한 정보를 제공한다
- 부정확한 주석은 없는 주석보다 나쁘다

주석은 나쁜 코드를 보완하지 않는다

주석이 필요한 이유? 나쁜 코드

모듈을 작성하니 엉망이고 알어먹기 어려움
그래서 주석을 달아야겠다? → No! 코드를 정리해야 한다
표현력이 풍부, 깔끔하고 주석이 없는 코드 > 복잡하고 어수선하나 주석이 아주 많이 달려있는 코드
어지름을 주석으로 설명하는 노력으로 그 어지름을 치우는 데에 시간과 노력을 투자하라

코드로 의도를 표현하라

// 어떤 쪽이 좋을까
//////////////////

// 1.
// 지구언에게 복지 혜택을 받을 자격이 있는지 검사한다.
if((employee.flags & HOURLY_FLAG) && (employee.age > 65))

// 2.
if (employee.isEligibleForFullBenefits())

몇 초만 더 생각하면 코드로 대다수 의도를 표현 가능
많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분

좋은 주석

글자값을 한다고 생각되는 주석

법적인 주석

회사가 정립한 구현 표준에 맞춰 법적인 이유로 넣는 주석

가능하다면, 표준 라이선스나 외부 파일을 참조

// Copyright (C) 2003, 2004, 2005 by Object Montor, Inc. All right reserved.
// GNU General Public License
```  
### 정보를 제공하는 주석
  - 예1)기본정보를 주석으로 제공
    - 유용함
    - 가능하면 함수 이름에 정보를 담는 편이 더 좋음 - 네이밍의 중요성
  - 예2)정규표현식의 결과물 형태를 주석으로
    - 시각과 날짜를 변환하는 클래스를 만들어 코드를 옮겨주면 주석이 필요가 없음
```java
// 1.
// 테스트 중인 Responder 인스턴스를 반환
protected abstract Responder responderInstance();

// 위의 경우 함수이름에 정보를 담아 다음처럼 작성하면 주석을 없앨 수 있다
protected abstract Responder responderBeingTested();

// 2.
// 좋은 주석
// kk:mm:ss EEE, MMM dd, yyyy 형식이다.
Pattern timeMatcher = Pattern.compile("\\d*:\\d*\\d* \\w*, \\w*, \\d*, \\d*");
```    

### 의도를 설명하는 주석
```java
// 스레드를 대량 생성하는 방법으로 어떻게든 경쟁 조건을 만들려 시도한다.
for (int i = 0; i > 2500; i++) {
    WidgetBuilderThread widgetBuilderThread =
        new WidgetBuilderThread(widgetBuilder, text, parent, failFlag);
    Thread thread = new Thread(widgetBuilderThread);
    thread.start();
}

때로는 주석으로 구현 이해를 도와주는 걸 넘어서 결졍에 깔린 의도를 설명하기도 한다

public int compareTo(Object o) {
    if (o instanceof WikiPagePath) {
        WikiPagePath p = (WikiPagePath) o;
        String compressName = StringUtil.join(names, "");
        String compressedArgumentName = StringUtil.join(p.names, "");
        return compressedName.compareTo(compressedArgumentName);
    }
    return 1;  // 오른쪽 유형이므로 정렬 순위가 더 높다.
}

의미를 명료하게 밝히는 주석

public void testCompareTo() throws Exception {
    WikiPagePath a = PathParser.parse("PageA");
    WikiPagePath ab = PathParser.parse("PageA.PageB");
    WikiPagePath b = PathParser.parse("PageB");
    
    assertTrue(a.compareTo(a) == 0);    // a == a
    asserTrue(a.compareTo(b) != 0);     // a != b
    assertTrue(ab.compareTo(ab) == 0);  // ab == ab
}

모호한 인수나 반환값은 그 자체를 명확하게 만드는게 더 좋다 - 이해가 쉬어지므로
인수/반환값이 표준라이브러리 이거나 변경하지 못하는 코드? 의미를 명료하게 밝히는 주석이 유용
그릇된 주석의 위험, 올바른지 검증이 안되는 위험 - 주석의 위험
더 나은 방법이 없는지 고민할 것

결과를 경고하는 주석

다른 프로그래머에게 결과를 경고할 목적

1
2
3

// 여유 시간이 충분하지 않다면 실행하지 마십시오.
public void _testWithReallyBigFile() {
}

ex)시간이 굉장히 오래걸리는 테스트 케이스
JUnit에선 어노테이션으로 간단하게 @Ignore("실행이 너무 오래걸림")

TODO 주석

//TODO 주석

// TODO-MdM 현재 필요하지 않다.
// 체크아웃 모델을 도입하면 함수가 필요 없다.
protected VersionInfo makeVersion() throws Exception {
    return null;
}

앞으로 할일, 현재 이유, 미래 모습등
필요하지만 당장 구현하기 어려운 업무를 기술
ex)더 좋은 이름을 떠올려달라, 문제를 봐달라, 더이상 필요없는 기능을 삭제해라, 이벤트에 맞춰 코드를 고쳐라
요새 IDE는 TODO주석을 찾아줌 : 주석을 잊을 위험은 없음, 그래도 한번씩 점검해서 없어도 괜찮은 주석은 삭제
FIXME : 문제가 있지만 당장 수정할 필요는 없을 때(가능하면 빨리 수정하는 것이 좋음)

중요성 강조 주석

공개 API에서의 Javadocs

설명이 잘된 공개 API는 참으로 유용하고 만족스럽다

ex) 표준 자바 라이브러리에서 사용한 Javadocs가 좋은 예
공개 API를 구현한다면 반드시 훌륭한 Javadocs를 작성하라
어느 주석과 마찬가지로 Javadocs도 잘못될 가능성이 존재

정말 좋은 주석 - 주석을 달지 않을 방법을 찾아낸 주석!

나쁜 주석 = 대부분의 주석, 대다수의 주석

많은 주석 : 허술한 코드 지탱, 엉성한 코드 변명, 미숙한 결정 합리화

주절거리는 주석

특별한 이유 없이 다는 주석 → 시간 낭비
주석을 막상 단다면 충분히 시간을 들여 최고의 주석을 달도록 노력
이해가 안되어 다른 모듈을 뒤져야하는 주석 → 독자와 소통하지 못하는 주석 → 바이트 낭비

아래가 바이트 낭비의 예 : 주석의 의미를 알려면 다른 모듈을 뒤져야 함

public void loadProperties() {
    try {
        String propertiesPath = propertiesLocation + "/" + PROPERTIES_FILE;
        FileInputStream propertiesStream = new FileInputStream(propertiesPath);
        loadedProperties.load(propertiesStream);
    } catch (IOException e) {
        // 속성 파일이 없다면 기본값을 모두 메모리로 읽어 들였다는 의미다.
    }
}

같은 이야기 중복하는 주석

// this.closed가 true일 때 반환되는 유틸리티 메서드다.
// 타임아웃에 도달하면 예외를 던진다.
public synchronized void waitForClose(final long timeoutMillis) throws Exception {
    if (!closed) {
        wait(timeoutMillis);
        if (!closed) {
            throw new Exception("MockResponseSender could not be closed");
        }
    }
}

→ 코드 내용이 그대로 설명하는 주석

주석이 코드보다 더 많은 정보를 제공하지 못함
의도/근거를 설명하는 주석도 아니고 코드보다 읽기가 쉽지도 않음
코드보다 부정확 → 독자가 함수를 대충 이해하고 넘어가게 만듬

오해 여지가 있는 주석

// this.closed가 true일 때 반환되는 유틸리티 메서드다.
// 타임아웃에 도달하면 예외를 던진다.
public synchronized void waitForClose(final long timeoutMillis) throws Exception {
    if (!closed) {
        wait(timeoutMillis);
        if (!closed)
            throws new Exception("MockResponseSend could not be close");
    }
}0

this.closed가 true로 되는 순간에 메서드 반환이 아닌 true여야 반환되는 것이다
주석만 본 프로그래머는 왜 코드가 느려지는지 알 수가 없음

의무적으로 다는 주석

모든 함수에 Javadocs를 달거나 모든 필드에 주석 : 어리석기 그지 없음

코드를 복잡하게 만들고 거짓말을 퍼뜨리고 혼동과 무질서를 초래하는 아무 가치가 없는 주석

/**
 *
 * @param title CD 제목
 * @param author CD 저자
 * @param tracks CD 트랙 숫자
 * @param durationInMinutes CD 길이(단위: 분)
 */
public void addCD(String title, String author, int tracks, int durationInMinutes) {
    CD cd = new CD();
    cd.title = title;
    cd.author = author;
    cd.tracks = tracks;
    cd.duration = durationInMinutes;
    cdList.add(cd);
}

이력을 기록하는 주석

소스 코드 관리 시스템이 없었던 시절의 바람직한 관례
현재는 혼란만 가중하므로 완전히 제거할것

있으나 마나 하는 주석

→ 너무 당연한 사실을 언급하고 새로운 정보를 제공못하는 주석

/*
 * 기본 생성자
 */
protected AnnualDateRule() {
    /** 월 중 일자 */
    private int dayOfMonth;
    /**
    * 월 중 일자를 반환한다.
    *
    * @return 월 중 일자
    */
    public int getDayOfMonth() {
        return dayOfMonth;
    }

}

개발자가 주석을 무시하는 습관에 빠지게 함 → 코드를 읽으며 주석을 건너뜀 → 코드 바뀌면서 주석은 거짓말이 됨
감정표현등 → 분풀이 주석으로 할 노력으로 코드 구조를 개선했었어야

무서운 잡음

특정 오픈소스의 Javadocs에는 의미 없는 잡음이 존재

함수나 변수로 표현가능하면 주석을 달지 말라

주석 표현 버전

1 2	// 전역 목록 에 속하는 모듈이 우리가 속한 하위 시스템에 의존하는가? if (module.getDependSubsystems().contains(subSysMod.getSubSystem()))

주석을 없애고 코드로 의미를 표현 버전

1
2
3

ArrayList moduleDependees = smodule.getDependSubSystems();
String ourSubSystem = subSysMod.getSubSystem();
if (moduleDependees.contains(ourSubSystem))

위치를 표시하는 주석

1	// Actions /////////////////////////////////////////////

가독성이 떨어짐, 뒷부분의 잡음 제거 필요
배너 : 눈에 띄며 주의 환기 → 반드시 필요할 때만 아주 드물게 사용할 것

닫는 괄호에 다는 주석

중괄호가 많아서 주석이 필요할 정도? 중첩이 심하고 장환한 함수라는 뜻
클린코드가 지향하는 작고 캡슐화된 함수에서 해당 주서은 잡음일 뿐
닫는 괄호에 주석을 달야야겠다는 생각이 든다면 함수를 작게 줄이려고 노력해야함

공로를 돌리거나 저자를 표시하는 주석

코드 오염시키지 말아라
코드에 오랫동안 방치되어 점점 쓸모 없어지고 부정확한 정보로 변함
이런 정보는 소스 코드 관리 시스템에 저장할 것

주석으로 처리한 코드

주석으로 처리한 코드는 절대 작성하지 말 것

InputStreamResponse response = new InputStreamResponse();
response.setBody(formatter.getResultStream(), formatter.getByteCount());
// InputStream resultsStream = formatter.getResultStream();
// StreamReader reader = new StreamRead(resultsStream);
// response.setContent(reader.read(formatter.getByteCount()));

Apache commons의 코드

this.bytePos = writeBytes(pngIdBytes, 0);
//hdrPos = bytePos;
writeHeader();
writeResolution();
//dataPos = bytePos;
if (writeImageData()) {
    wirteEnd();
    this.pngBytes = resizeByteArray(this.pngBytes, this.maxPos);
} else {
    this.pngBytes = null;
}
return this.pngBytes;

주석 처리한 코드 : 밉살스러운 관행
- 이유가 있다고 남겼다고 사람들이 생각함 → 지우기 주저
- 점점 쓸모없는 코드 주석이 쌓여감
- 1960년대 에는 주석으로 처리한 코드가 유용
- 소스 관리 시스템이 알아서 코드를 기억해줌 → 코드 주석처리가 필요가 없음
- 그냥 코드를 삭제하라

HTML 주석

혐오 그 자체

Javadocs에 html 태그
```
나 태그 난리
```
IDE에서 조차 읽기 어려움
Javadocs등의 도구로 주석을 뽑아 웹에 올리려면 해당 태그 삽입은 프로그래머가 아닌 도구가 책임

전역 정보

(주석을 달아야 한다면) 근처 있는 코드만 기술
코드 일부에 주석을 달면서 시스템 정반적 정보 기술 X
아래 예시)
- 이미 정보가 중복됨
- 주석은 기본 포트 정보를 기술
- 함수는 포트 기본값 통제 불가 → 이 주석은 밑의 함수가 아닌 다름 함수의 내용 설명
- 즉 포트 기본값 설정 코드가 변해도 이 주석이 변하리라는 보장이 없음
  1
  2
  3
  4
  5
  6
  7
  8
  /**
  * 적합성 테스트가 동작하는 포트: 기본값은 8082.
  *
  * @param fitnessePort
  */
  public void setFitnessePort(int fitnessePort) {
  this.fitnewssePort = fitnessePort;
  }

너무 많은 정보

주석에 스펙 역사나 관련없는 정보 장황하게 늘어놓지 마라

모호한 관계

Apache commons의 주석

/*
 * 모든 픽셀을 담을 만큼 충분한 배열로 시작한다(여기에 필터 바이트를 더한다).
 * 그리고 헤더 정보를 위해서 200 바이트를 더한다.
 */
 this.pngBytes = new byte[((this. width + 1) * this.height * 3) + 200];

위의 주석을 보고 드는 생각
- 필터 바이트는 무엇?
- +1과 관련이 있나? 아니면 *3과 관련이 있나? 아니면 둘다?
- 한 픽셀이 한 바이트인가?
- 200을 추가하는 이유는?
주석 다는 목적 : 코드 만으로 설명이 부족해서
주석 자체가 다시 설명을 요구하는 안 좋은 주석

함수 헤더

짧은 함수 : 긴 설명이 필요 없음
짧고 한 가지만 수행하며 이름을 잘 붙인 함수 >>>>> 주석으로 헤더를 추가한 함수

비공개 코드의 Javadocs

공개 API에선 Javadocs가 유용
공개하지 않을 코드라면 Javadocs가 쓸모가 없음
시스템 내부에 속한 클래스와 함수에 Javadocs를 생성할 필요가 없음

예제

예제)

주석을 잘 달았다고 착각하게 만들지만 바람직하지 않은 코드

/**
 * 이 클래스는 사용자가 지정한 최대 값까지 소수를 생성한다. 사용한 알고리즘은 에라스토테네스의 체다.
 * 
 * 에라스토테네스: 기원전 276년 ...(후략)
 * 
 * 알고리즘은 상당히 단순하다. 2에서 시작하는 정수 배열을 대상으로 2의 배수를 모두 제거한다.
 * 다음으로 남은 정수를 찾아 이 정수의 배수를 모두 지운다. 최대 값의 제곱근이 될 때까지 이를 반복한다.
 *
 * @author Alphonse
 * @version 13 Feb 2002 atp
 */
import java.util.*;

public class GeneratePrimes {
    /*
     * @param maxValue는 소수르 찾아낼 최대 값
     */
     public static int[] generatePrimes(int maxValue) {
         if (maxValue >= 2) {  // 유일하게 유요한 경우
             // 선언
             int s = maxValue + 1;  // 배열 크기
             boolean[] f = new booleans[s];
             int i;
             
             // 배열을 참으로 초기화
             for (i = 0; i < s; i++)
                 f[i] = true;
             
             // 소수가 아닌 알려진 숫자를 제거
             f[0] = f[1] = false;
             
             // 체
             int j;
             for (i = 2; i < Math.sqrt(s) + 1; i++) {
                 if (f[i]) {  // i가 남아 있는 숫자라면 이 숫자의 배수를 구한다.
                     for (j = 2 * i; j < s; j += i)
                         f[j] = false;  // 배수는 소수가 아니다.
                 }
             }
             
             // 소수 개수는?
             int count = 0;
             for (i = 0; i < s; i++) {
                 if (f[i])
                     count++;  // 카운트 증가
             }
             
             int[] primes = new int[count];
             
             // 소수를 결과 배열로 이동한다.
             for (i = 0, j = 0; i < s; i++) {
                 if (f[i])  // 소수일 경우에
                     primes[j++] = i;
             }
             
             return primes;  // 소수를 반환한다.
         }
         else // maxValue < 2
                 return new int[0];  // 입력이 잘못되면 비어 있는 배열을 반환한다.
     }
}

위의 코드의 리팩터링 결과

/**
 * 이 클래스는 사용자가 지정한 최대 값까지 소수를 구한다.
 * 알고리즘은 에라스토테네스의 체다.
 * 2에서 시작하는 정수 배열을 대상으로 작업한다.
 * 처음으로 남아 있는 정수를 찾아 배수를 모두 제거한다.
 * 배열에 더 이상 배수가 없을 때까지 반복한다.
 */
public class PrimeGenerator {
    private static boolean[] crossedOut;
    private static int[] result;
    
    public static int[] generatePrimes(int maxValue) {
        if (maaxValue < 2)
            return new int[0];
        else {
            uncrossIntegersUpTo(maxValue);
            crossOutMultiples();
            putUncrossedIntegerIntoResult();
            return result;
        }
    }
    
    private static void uncrossIntegersUpTo(int maxValue) {
        crossedOut = new boolean[maxValue + 1];
        for (int i = 2; i < crossedOut.length; i++)
            crossedOut[i] = false;
    }
    
    private static void crossOutMultiples() {
        int limit = determineIterationLimit();
        for (int i = 2; i <= limit; i++)
            if (notCrossed(i))
                crossOutMultiplesOf(i);
    }
    
    private static int determineIterationLimit() {
        // 배열에 있는 모든 배수는 배열 크기의 제곱근보다 작은 소수의 인수다.
        // 따라서 이 제곱근보다 더 큰 숫자의 배수는 제거할 필요가 없다
        dobule iterationLimit = Math.sqrt(crossedOut.length);
        return (int) iterationLimit;
    }
    
    private static void crossOutMultiplesOf(int i) {
        for (int multiple = 2 * i; multiple < crossedOut.length; multiple += i)
            crossedOut[multiple] = true;
    }
    
    private static boolean notCrossed(int i) {
        return crossedOut[i] == false;
    }
    
    private static void putUncrossedIntegersIntoResult() {
        result = new int[numberOfUncrossedIntegers()];
        for (int j = 0, i = 2; i < crossedOut.length; i++)
            if (notCrossed(i))
                result[j++] = i;
    }
    
    private static int nubmerOfUncrossedIntegers() {
        int count = 0;
        for (int i = 2; i < crossedOut.length; i++)
            if (notCrossed(i))
                count++;
        
        return count;
    }
}

요약

주석을 최대한 쓰지 말자
쓰려면 좋은 주석
주석보다는 어노테이션
JavaDoc

[Clean Code] Ⅲ. 함수

Mon, 03 Jan 2022 00:51:51 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅲ. 함수

함수

프로그래밍 초창기 : 시스템을 루틴과 하위 루틴으로 나눔
포트란, PL/1 시절 : 프로그램, 하위 프로그램, 함수로 나눔
현재는 함수만 살아남음 : 가장 기본적 단위

함수 잘만드는 규칙

작게 만들어라

첫째도 작게. 둘째도 더 작게!
블록과 들여쓰기
- if/while등에 들어가는 블록은 단 한줄이어야 한다
- 대게 여기서 함수 호출
- wraping하는 enclosing func가 작아짐
- 블록안의 함수명이 적절하면 이해도 상승
- 함수의 들여쓰기는 1단이나 2단을 넘어서면 안된다

한가지만 해라!

함수에 대한 선배들의 충고

함수는 한 가지를 해야 한다
그 한가지를 잘해야 한다
그 한가지만을 해야한다

한가지의 범위 : TO

ex) To RenderPageWithSetupsAndTeardowns
- 페이지가 테스트 페이지인지 확인
- 테스트 페이지면 설정,해제 페이지를 넣는다
- 테스트 페이지임에 상관없이 HTML 렌더링
지정된 함수 이름 아래 추상화 수준이 한단계 : 한 가지 작업만 하는 함수
섹션이 나누어지는 함수(선언,초기화,로직등)은 여러 작업을 한다는 증거

함수당 추상화 수준은 하나

함수 내 모든 문장의 추상화 수준이 동일해야 한다
다른 추상화 수준이 섞여 있으며 읽기에 헷갈림
내려가기 규칙
- 위에서 아래로 이야기처럼 읽혀야 좋다
- 위에서 아래로 읽으면 함수 추상화가 한번에 한 단계씩 낮아짐

Switch문 처리

siwtch문은 작게 만들기 어려움

본질적으로 N가지 처리
블행히도 switch문을 완전히 피할 방법도 없음

예제 : 직원 유형에 따라 다른 값을 계산해 반환하는 함수

Payroll.java

public Money calculatePay(Employee e)
 throws InvalidEmployeeType {
     switch (e.type) {
         case COMMISSIONED:
            return calculateCommissionedPay(e);
         case HOURLY:
            return calculateHourlyPay(e);
         case SALARIED:
            return calculateSalariedPay(e);
         default:
            return new InvalidEmployeeType(e.type);
     }

}

문제점
1. 함수가 길다. 새 회원 유형이 추가되면 더 길어짐
2. ‘한 가지’작업만 수행하지 않음
3. SRP(Single Responsibility Principal) 위반 : 코드 변경 이유가 여럿
4. OCP(Open Closed Principal) 위반 : 새회원 유형 추가할 떄마다 코드 변경
5. 위함수와 구조가 동일한 함수가 무한정 존재
- isPayday(Employee e, Date date);
- deliverPay(Employee e, Money pay);
해결 방법 : 다형성 객체를 생성하는 코드로 상속관계로 숨긴다
1. switch문을 추상 팩토리에 숨기고 아무에게 보여주지 않음
2. 팩토리는 switch문을 이용해 적절한 Employee 파생 클래스의 인스턴스 생성
3. 함수들(calculatePay, isPayday, deliverPay)는 Employee 인터페이스를 거쳐 호출 → 다형성(polymorphism)으로 실제 파생 클래스의 함수가 실행됨

public abstract class Employee {
    public abstract boolean isPayday();
    public abstract Money calculatePay();
    public abstract void deliverPay(Money pay);
}
//-------------------------
public interface EmployeeFactory {
    public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType {
        switch (r.type) {
         case COMMISSIONED:
            return new CommissionedEmployee(r);
         case HOURLY:
            return new HourlyEmployee(r);
         case SALARIED:
            return new SalariedEmployee(r);
         default:
            return new InvalidEmployeeType(r.type);
       }
    }
}

서술적인 이름을 사용하라

좋은 이름이 주는 가치는 매우 중요
길고 서술적인 이름이 짧고 어려운 이름보다 좋음
길고 서술적인 이름 > 길고 서술적인 주석
좋은 이름을 고르고 코드를 더 좋게 재구성한 사례도 존재함
일관성 있는 네이밍
- 모듈내의 함수 이름은 같은 문구/명사/동사 사용

함수 인수

이상적 인수 : 0개

3개: 가능한 피하라, 4개: 특별한 이유가 필요, 5개 특별한 이유가 있어도 안됨

인수는 어렵다

개념을 이해하기 어렵게 만듬
함수 이름과 인수 사이에 추상화 수준이 다름
코드 읽는 사람이 인수까지 파악해야함

테스트 관점 더 어려움

인수가 3개 이상이면 유효한 값으로 모든 조합 구성해 테스트하기 부담스럽다

출력인수는 더 어렵다

개발자는 함수에 인수로 입력을 넘기고 반환으로 출력을 받는것에 익숙

최선은 0개의 인수, 차선은 1개의 인수

많이 쓰는 단항 형식

가장 흔한 경우
1. 인수에 질문을 던지는 경우
2. 인수를 근거해서 먼가를 변환해 결과를 반환
흔하지 않지만 유용한 경우 : 이벤트
- 이벤트는 입력 인수만 있고 출력 인수가 없음
- 이벤트는 이름과 문맥 주의해서 선택 : 이벤트라는 사실이 코드에 명확하게
이외에는 가급적 단항 함수는 피할 것
- 입력 인수를 변환하는 함수라면 변환 결과는 반환값으로 돌려줄 것

플래그 인수

추하다
함수로 부울값을 넘기는 관례는 끔찍
- 부울 값에 따라 하는 일이 다름 → 함수가 여러가지를 처리한다고 공표

2항 함수

2항 함수는 1항 함수보다 이해가 어려움
2항 함수가 적절한 경우 : 직교 좌표계 점 Point p = new Point(0,0)
assertEquals(expected, actual)
- 문제가 있음
- 바꿔쓰는 경우가 허다
- 자연적 순서가 없어서 인위적으로 기억해야 함
2항이 무조건 나쁘다는 소리가 아님
- 불가피하면 어쩔 수 없음
- 하지만 그만큼 위험이 따르는 부분이라는 것을 인지 필요
- 가능한 단항으로 바꾸도록 애써야 한다

3항 함수

2항보다 더 이해 어려움 - 신중히 고려 필요
assertEquals(expected, actual, message)
- 메시지 무시 하는 오버로딩도 있음
- expected 위치 자꾸 헷갈림

인수 객체

인수가 많다면 독자적인 클래스 변수로 선언?
VO나 DTO → 결국 개념을 표현

인수 목록

3항이상의 가변 인수 의 경우 문제가 있음
동사와 키워드
- 함수의 의도, 인수의 순서, 의도 표현 - 좋은 함수 이름 필 수
- 단항 함수 : 동사/명사 쌍
- 함수 이름에 키워드 추가 하는 형식도 있음
- assertExpectedEqualsActual(expected,actual) : 인수 순서 기억 필요 없음

부수 효과를 일으키지마라

Side effect는 거짓말 : 함수에서 1가지만 하겠다고 해놓고 다른 것도 함
많은 경우 시간적 결합(temporal coupling), 순서 종속성(order dependency) 초래

출력 인수

인수를 출력으로 쓰지말아라
- 기본적으로 우리는 인수를 함수 입력으로 해석
- 선언부를 보고 확인? 벌써 주춤 및 생산성 저하,
객체 지향 언어에서는 출력 인수를 사용할 필요가 거의 없다
- 이전 언어에는 출력인수가 불가피한 경우가 존재
- 객체 지향에서는 this가 존재
- ex) public void appendFooter(StringBuffer report)
  - appendFooter(s); : 출력을 인수에 넣었음
  - 다음과 같이 쓸 수 있도록 고치자 : report.appendFooter()
함수에서(굳이) 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하자.

명령과 조회 분리 = CQS

함수는 커맨드(무언가를 수행)하거나 쿼리(무언가에 답)하거나 둘중 하나만 할 것
1. 코드 자체가 일단 괴상해짐(책의 내용처럼)
2. 함수는 하나만 해야 하는 SRP를 지킬 수 있겠고
3. 사이드 이펙트도 최소화할 수 있음

오류 코드 보다는 예외 사용

명령 함수에서 오류코드 반환 → CQS 약간 위반
- 오류 코드 반환시 호출자는 오류 코드를 곧바로 처리해야 함 → 코드 복잡
- 예외를 사용하면 오류 처리가 원래 코드와 분리 → 코드가 깔끔해짐
try-catch 뽑아내기
- 추함 : 블록 자체가 코드 구조에 혼란을 주고 정상/오류 동작을 뒤섞는다
- 해당 블록을 별도 함수로 뽑아내자
- catch 블록도 별도로 뽑아야 한다
  - 함수는 한가지 작업만 해야 한다
  - 오류 처리도 ‘한 가지’ 작업에 속함
  - 오류 처리 함수는 오류만 처리해야 함
  - 함수에 try가 있다면 함수는 try로 시작해서 catch/finally로 끝나야 한다
Error.java 의존성 자석
- 오류코드를 반환한다 → (클래스,열거,변수 어떤 거든) 어디선가 오류 코드 정의한다
- Error.java : 에러 코드를 모아놓은 enum class 라고 가정 → 의존성 자석
  - 다른 클래스에서 Error enum을 import
  - Error enum이 변하면 Error를 사용하는 모든 클래스 재컴파일 필요
  - 재컴파일/재배치 번거로움 → 새오류 코드 정의 싫어함 → 기존 코드 재 사용;
- 예외는 Exception클래스에서 파생 → 재컴파일/재배치 없이 새 예외 클래스 추가 가능

반복하지 마라 : DRY(Don’t Repeat Yourself) 원칙

중복 = 모든 악의 근원

길이가 늘어남, 변경시 중복 된만큼 케어, 바쁘릴시 오류가 발생할 확율도 높음
많은 법칙/기법이 오직 중복을 없애거나 제어할 목적으로 존재
- RDMBS의 정규형 : 중복 제거
- OOP : 코드를 부모 클래스로 몰아넣음 → 중복 제거
- AOP, COP : 어떤 관점으로 보면 이들 모두 중복 제거 전략
- 하위 루틴 발명 이래로 모든 sw개발의 혁신은 중복을 제거하려는 지속적인 노력의 결과

구조적 프로그래밍

모든 함수와 함수 내 모든 블록에 입구와 출구는 하나만 존재해야 한다
Edsger Dijkstra(에츠허르 데이크스트라)Structured Programming(구조적 프로그래밍 원칙

함수는 return이 하나이어야 할 것
루프 안에서 break/continue 사용하면 안된다
goto는 절대로 사용하지 말 것

위 규칙은 함수가 큰 경우에 한해서 상당한 이득

함수를 아주 작게 만든다면 간혹 return/break/continue 여러번 사용 무방
때로는 오히려 단일 입/출구 규칙보다 의도 표현이 용이
goto는 큰함수에서만 의미 → 작은 함수에서 피해야 함

함수를 어떻게 짜는가?

sw작성 = 글짓기

글짓기
- 먼저 기록을 기록후 읽기 좋게 다듬는다
- 초안은 대게 서투르고 어수선
- 말을 다듬고 문장을 고치고 문단을 정리
- 제대로 작성될 때까지
함수 작성도 마찬가지
- 처음엔 길고 복잡, 들여쓰기 단계도 많고 중복된 루프와 긴 인수 목록
- 네이밍도 즉흥적, 중복 코드도 많음
- 서투른 위의 코드를 빠짐없이 테스트 하는 단위 테스트 케이스 작성
- 이후 코드 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거
- 이 와중에 코드는 항상 단위 테스트를 통과
- 최종적으로 이 챕터의 규칙을 따르는 함수를 결과물로.
- 처음부터 짜내지 않는다. 그게 가능한 사람도 없다

결론

DSL

특정 응용분야 시스템을 기술할 목적으로 설계된 도메인 특화언어

프로그래머 대가

시스템은 구현할 프로그램이 아니라 풀어갈 이야기로 여긴다
프로그램 언어를 수단으로 좀더 풍부하고 표현력이 강한 언어를 만들어 이야기를 풀어간다
재귀라는 기교로 시스템에 발생하는 동작은 그 도메인에 특화된 언어를 사용해 자신만의 이야기

3.7 규칙적용 코드 예시

규칙적용 코드 예시

public class SetupTeardownIncluder {
  private PageData pageData;
  private boolean isSuite;
  private WikiPage testPage;
  private StringBuffer newPageContent;
  private PageCrawler pageCrawler;
 
  public static String render(PageData pageData) throws Exception {
    return render(pageData, false);
  }
 
  public static String render(PageData pageData, boolean isSuite)
    throws Exception {
    return new SetupTeardownIncluder(pageData).render(isSuite);
  }
 
  private SetupTeardownIncluder(PageData pageData) {
    this.pageData = pageData;
    testPage = pageData.getWikiPage();
    pageCrawler = testPage.getPageCrawler();
    newPageContent = new StringBuffer();
  }
 
  private String render(boolean isSuite) throws Exception {
    this.isSuite = isSuite;
    if (isTestPage())
      includeSetupAndTeardownPages();
    return pageData.getHtml();
  }
 
  private boolean isTestPage() throws Exception {
    return pageData.hasAttribute("Test");
  }
 
  private void includeSetupAndTeardownPages() throws Exception {
    includeSetupPages();
    includePageContent();
    includeTeardownPages();
    updatePageContent();
  }
  private void includeSetupPages() throws Exception {
    if (isSuite)
      includeSuiteSetupPage();
    includeSetupPage();
  }
 
  private void includeSuiteSetupPage() throws Exception {
    include(SuiteResponder.SUITE_SETUP_NAME, "-setup");
  }
 
  private void includeSetupPage() throws Exception {
    include("SetUp", "-setup");
  }
 
  private void includePageContent() throws Exception {
    newPageContent.append(pageData.getContent());
  }
 
  private void includeTeardownPages() throws Exception {
    includeTeardownPage();
    if (isSuite)
      includeSuiteTeardownPage();
  }
 
  private void includeTeardownPage() throws Exception {
    include("TearDown", "-teardown");
  }
 
  private void includeSuiteTeardownPage() throws Exception {
    include(SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown");
  }
 
  private void updatePageContent() throws Exception {
    pageData.setContent(newPageContent.toString());
  }
 
  private void include(String pageName, String arg) throws Exception {
    WikiPage inheritedPage = findInheritedPage(pageName);
    if (inheritedPage != null) {
      String pagePathName = getPathNameForPage(inheritedPage);
      buildIncludeDirective(pagePathName, arg);
    }
  }
 
  private WikiPage findInheritedPage(String pageName) throws Exception {
    return PageCrawlerImpl.getInheritedPage(pageName, testPage);
  }
 
  private String getPathNameForPage(WikiPage page) throws Exception {
    WikiPagePath pagePath = pageCrawler.getFullPath(page);
    return PathParser.render(pagePath);
  }
 
  private void buildIncludeDirective(String pagePathName, String arg) {
    newPageContent
      .append("\n!include ")
      .append(arg)
      .append(" .")
      .append(pagePathName)
      .append("\n");
  }
}

추가

SOLID - 너무 유명한 법칙인데 계속 드문드문한 법칙

SRP(Single Responsibility Principle)
- 단일 책임의 원칙
- THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.
- 한 클래스는 하나의 기능을 가진다
- 클래스가 제공하는 모든 서비스는 그 하나의 책임을 수행하는데 집중되어야 한다
- 어떤 변화에 의해 클래스를 변경해야 하는 이유도 오직 하나뿐이어야 한다
- 적용시 책임영역이 확실 → 책임 변경에서 다른 책임의 변경의 연쇄를 막음
- 책임의 적절한 분배 → 코드 가독성 향상, 유지보수 용ㅇ이
- 다른 원리들을 적용하는 기초
  - 리팩토링이 필요한 위험사항 해법은 직/간접적으로 SRP원리와 연관
  - 리팩토리 근본정신(항상 코드를 최상으로 유지)도 항상 객체 책임을 최상의 상태로 분배한다는 것에서 비롯되므로
- 다른 것에 비해 단순하지만 실무에서 직접 적용해서 설계가 그리 쉽지는 않음
- 의도적인 많은 연습과 경험이 필요
- 무조건적인 책임 분리가 SRP가 적용되는 것이 아니다
  - 객체간의 응집력(cohesion)이 있다면 병합이 순작용의 수단 - 강 응집력 지향
  - 결합력(coupling)이 있다면 분리가 순 작용의 수단 - 약 결합력 지향
OCP(Open Close Principal)
- 개방폐쇄의 원칙
- YOU SHOULD BE ABLE TO EXTEND A CLASSES BEHAVIOR, WITHOUT MODIFYING IT.
- sw 요소는 확장에 열려있고 변경에 닫혀있어야 한다
- 객체지향 소프트웨어 설계라는 책에서 정의됨 - 1998, 버틀란트 메이어(Bertrand Meyer)
- sw요소 : 컴포넌트, 클래스, 모듈, 함수
- 변경을 위한 비용은 최소화, 확장을 위한 비용은 극대화
- 객체지향의 장점을 극대화하는 아주 중요한 원리
- 요구사항 변경이나 추가 사항시
  - 기존 요소는 수정이 일어나지 말아야한다
  - 기존 구성요소를 쉽게 확장해서 재사용할 수 있어야 한다
  - 밥아저씨
    - OCP는 관리 가능하고 재사용 가능한 코드를 만드는 기반
    - OCP를 가능하게 하는 중요 매커니믐 : 추상화, 다형성
LSP (The Liskov Substitution principle)
- 리스코프 치환원칙
- FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.
- 서브 타입은 언제나 기반 타입으로 교체 가능해야 함
- 서브 타입은 기반 타입이 약속한 규약을 포함하고 지켜야함
- 클래스의 상속, 인터페이스 상속 이용해 확장성 획득
- 다형성/확장성을 극대화하기 위해 인터페이스를 사용하는 것이 좋다
  - 상속을 통한 재사용은 기반/서브 사이에 IS-A 관계일 경우로만 제한 권장
  - 부모클래스를 작성한 개발자가 세웠던 가정, 추론 과정, 원리를 정확히 이해 필요
    이는 자식 클래스가 부모클래스에게 강하게 결합된 의미
  - 상속은 부모와 자식 클래스의 결합도가 매우 높음
  - 상속은 추상화를 이용을 해야 위의 문제가 해결됨
    - 자식의 클래스가 부모 클래스의 구현이 아닌 추상화에 의존하도록
- 합성(컴포지션) 사용 가능 : 이펙티브 자바 18번 아이템
  - 구글에서 “이펙티브 자바 18” 검색
  - 데코레이터 패턴 처럼
ISP (Interface Segregation Principle)
- 인터페이스 분리 원칙
- CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE.
- 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다
- 가능한 최소한의 인터페이스만 구현
- 특정 클래스 이용하는 클라이언트가 여러 개이며 각각 클래스의 특정 부분만 이용?
  → 여러 인터페이스로 분류해서 클라이언트가 필요한 기능만 전달한다
- SRP가 클래스의 단일 책임이라면? ISP는 인터페이스의 단일 책임
DIP (Dependency Inversion Principle)
- 의존성 역전의 법칙
  - A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.
  - B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS.
- 상위 모델은 하위 모델의 의존하면 안되며 둘다 추상화에 의존해야 한다
- 추상화는 세부사항에 의존해선 안되며 세부사항은 추상화에 따라 달라진다
- 하위 모델의 변경이 상위 모듈의 변경을 요구하는 위계 관계를 끊는다
- 실제 사용 관계는 그대로이나 추상화를 매개로 메시지를 주고 받으며 관계를 느슨하게
추가 참조
- 그림으로 보는 : https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898
- https://www.nextree.co.kr/p6960

간결한 함수

분기는 가능한 추상 클래스 or Factory
안전한 함수 - Side Effect

함수 리팩터링

기능을 구현하는 서투른 함수를 작성
테스트 코드 작성
리팩터링

[Clean Code] Ⅱ.의미 있는 이름

Sun, 02 Jan 2022 00:00:52 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅱ. 의미 있는 이름

이름을 잘 짖는 간단한 몇가지 규칙

의도를 분명히 밝혀라

변수명이나 메서드 명에서 정확하게 의도를 알 수 있는 이름

그릇된 정보를 피하라

그릇된 단서 : 널리 쓰이는 단어를 다른 의미로 사용, 자료구조 이름을 다른 뜻으롷 사용하는 등
역시 이름만 바꾸면 깨끗이 풀리는 문제들

의미 있게 구분하라

컴파일러/인터프리터만 통과하려는 식의 구현 : 의미 없는 이름 혹은 고민하지 않은 이름들
이름이 달라야 한다면 의미도 달라져야한다
읽는 사람이 차이를 알도록 이름을 지어야 한다

발음하기 쉬운 이름을 사용

발음하기 어려운 이름은 커뮤니케이션도 어려움

검색하기 쉬운 이름을 사용

예제 책등에서 보이는 문자 하나를 사용하는 이름/상수는 쉽게 눈에 띄지 않는다
ex) e는 영어에서 가장 많이 쓰이는 문자 → 검색을 해서 follow하기가 불가능
검색하기 쉬운 이름이 상수보다 좋다
이름 길이는 범위 크기에 비례해야한다
- 아주 간단한 메서드의 로컬 변수는 한 문자 사용 가능
- 변수나 상수를 코드 여러 곳에서 사용한다면 그만큼 검색하기 쉬운 이름이 바람직

인코딩을 피하라

이름에 인코딩(!)할 정보는 어차피 아주 많음
인코딩한 이름은 거의 발음하기 어려우며 오타가 생긴다
대표적인 예시 : 이제 필요없는 기법들
- 헝가리식 표기법(인코딩 대표방법)
- 멤버 변수 접두어
필요한 경우 : 인터페이스와 구현 클래스
- 굳이 하나를 인코딩해야 한다면 구현 클래스의 이름 ex)~~~FactoryImp

자신의 기억력을 자랑하지 마라

문자 하나만 사용 피하라
- 루프의 반복횟수를 세는 변수 i,j,k는 ok(l은 절대안된다!)
- 최악 이미 a와 b를 사용하므로 c를 사용
프로그래머들으 대체로 똑똑 : 자신의 능력을 과시하고 싶음
똑똑한 vs 전문가 : 전문가는 명료함이 최고라는 사실을 이해한다

클래스 이름

클래스 이름, 객체 이름은 명사,명사구가 적합
Manager, Processor, Data, Info등의 단어는 피하고 동사 사용 X

메서드 이름

메서드 이름은 동사,동사구가 적합
접근자,변경자,조건자는 javabean표준에 따라 get,set,is를 붙인다
Construct를 overload할때는 정적 팩토리 메서드를 사용한다(생성자 제한으로 private해버리기)

기발한 이름은 피하라

유머코드, 농담 코드를 넣지 말자
특정 문화에서만 사용되는 단어/농담은 피하라
재미난 이름보다는 명료한 이름을 선택 : 의도분명, 솔직하게 표현

한 개념에 한 단어 사용

추상적 개념 하나에 한 단어 고수 : 아니면 어느 클래스에서 어떤 단어를 썼는지 알기 어려움
동일 코드에 다른 이름? 읽는 사람은 클래스도 다르고 타입도 다르리가고 생각함

말장난 금지

한 단어를 2가지 목적으로 사용하지 마라
한 개념에 한 단어를 사용하라 하더라도 기존과 맥락이 다르다면 이름을 다르게 해야한다
집중적 탐구가 아니라 대충 훑어봐도 이해할 코드 작성이 목표

문제 영역에서 가져온 이름 사용하라

문제영역과 해법영역을 구분할 것
적절한 프로그래머 용어가 없는 문제 영역 개념과 관련이 깊은 코드라면 문제영역에서 이름을 가져온다
유지보수 프로그매러가 도메인 전문가에게 의미를 물어 파악 가능

의미 있는 맥락을 추가

스스로 의미 있는 이름 먼저 → 클래스, 함수, 이름공간에 넣어 맥락 부여 → 전부 실패하면 최후의 방법으로 접두어

불필요한 맥락을 없애라

의미가 분명한 경우라면 짧은 이름이 긴 이름보다 좋다 : 불필요한 맥락 추가X

구글 자바 스타일 가이드

p31 인터페이스 클래스와 구현 클래스 부분
- 밥 아저씨는 ShapeFactoryImp가 좋다고 하지만 CircleFactory가 훨씬 좋음
구글 자바 스타일 가이드에서 5번째 : https://google.github.io/styleguide/javaguide.html
1. 패키지 이름 : 모두 소문자, 언더스코어 없이
2. 클래스 이름
- UpperCamelCase(대문자 시작)
- 명사/명사구
- 인터페이스도 명사/명사구이지만 때때로 형용사/형용사구 ex)Readable
  (그러면 클래스는 ClassImplReadable 이런식으로)
- 테스트 클래스는 Test로 끝나야 한다
1. 메서드 이름
- lowerCamelCase(소문자 시작)
- 동사/동사구
- JUnit test 메서드에서 한해서 언더스코어 등장
  - 패턴 : _, for example pop_emptyStack
1. 상수 이름
- 상수 : 완전 불변,ㅡ 메서드 감지 가능한 부작용 없는 static final
- 인스턴스의 상태가 변경될 수 있는 경우 상수가 아님 : 단순히 객체변형을 막는것이 목적이 아니다
- CONSTANT_CASE : 모두 대문자, 언더스코어(_)로 각 단어 구분
1. 상수가 아닌 필드 이름
- lowerCamelCase
- 정적이나 다른것들 ㅂ포함
1. 파라미터
- lowerCamelCase
- public 메서드일때 한 글자 파라미터 이름은 피해야 한다
1. 지역 변수
- lowerCamelCase
- final, 불변이어도 지역변수는 상수로 간주 되지 않으며, 상수 스타일 지정하지 말아야
1. Type 변수 이름
- 단일 대문자, 추가적으로 한자리 숫자가 따라올수 있음(E,T,X,T2)
- 클래스 명명 규칙+ T : (RequestT, FooBarT)

[Clean Code] Ⅰ. 깨끗한 코드

Sat, 01 Jan 2022 00:41:38 GMT

Clean Code 3판을 읽고 정리한 글입니다

Ⅰ. 깨끗한 코드

오프닝

사소한 곳에서 발휘하는 정직은 사소하지 않다.
신은 세세함에 깃들어 있다
SW는 80%가 유지보수

코드는 언제나 존재

코드는 사라지지 않음

코드 : 요구사항 상세히 표현하는 수단
하위 어느 수준에 다르면 코드 없이 요구사항 표현이 불가능
기계가 실행할 정도의 상세하게 요구사항을 명시하는 작업 : coding
추상화가 아무리 높아져도 코드가 사라지진 않음
요구사항을 모호하게 주어도 정확한 프로그램 생성? : 절대 불가능
인간도 고객의 감정으로는 성공적인 시스템 구현 불가
제대로 명시한 요구사항 : 코드만큼 정형적 → 테스트 케이스로 사용가능

bad code

이 책은 좋은 코드가 중요하다는 다소 미약한 전제에 기반한다
Kent BeckImplementation Patterns

밥아저씨 : 미약하지 않으며 아주 아주 중요하다
wading(고행) : 나쁜 코드를 헤쳐나가는 작업 → 나쁜 코드는 회사가 문을 닫을 수 있을 정도의 치명적
르블랑의 법칙 : 나중은 결코 오지 않는다
- 일단 급하게 짜고 나중에 손본다고 생각하지 말고 처음 짤 때부터 잘 해야한다

나쁜 코드로 치르는 대가

나쁜 코드는 개발 속도 저하 유발
나쁜 코드가 쌓일 수록 팀 생산성 저하되며 나중에 0에 수렴
인력을 추가 투입?
- 추가 인력은 기존 설계와 히스토리를 잘 모름
- 설계를 잘 모름 → 의도에 맞는 변경과 반하는 변경 구분 못함
- 추가 인력은 생산성 향상 푸쉬 압박 시달림
- 결론 : 나쁜 코드를 더 많이 양산 → 다시 생산성 0

원대한 재설계의 꿈

팀이 재설계 요청, 관리층은 싫지만 어쩔수 없이 허락
두팀의 경주 시작 : 타이거팀-유능하고 똑똑한 TF팀, 기존팀-현재 시스템 유지보수팀
경주는 10년넘게 걸리는 경우도 있음
어마어마한 비용

태도

관리자의 일정과 요구사항을 강력히 푸쉬 → 그들의 책임
프로그래머들의 책임 : 좋은 코드를 사수하는 것
나쁜 코드가 초래하는 프로젝트 실패는 프로그래머들의 큰 책임이 있음
의사 비유: 환자(상사)가 요구해도 의사는 위험한 부분 단호히 거부
프로그래머도 마찬가지 : 나쁜 코드의 위험을 이해 못하는 관리자 말을 그대로 따르는 것은 전문가가 아님

원초적 난제

빨리 가려고 클린 코드 유지 X → 나쁜 코드 양산 → 생산성 저하, 기간 늘어남 → 결국 늦게 감

클린코드라는 예술?

클린 코드 구현 행위 = 그림을 그리는 행위와 비슷
- 그림을 보면 대부분의 사람은 잘 그려졌는지 엉망으로 그려졌는지 안다
- 그림을 잘 구분한다고 그림을 잘 그리진 않는다
- clean code 와 bad code를 구분하더라도 clean code를 작성할 수 있다는 것은 아님
clean code는 ‘코드 감각’을 필요로 함
- ‘청결’이라는 습득한 감각을 이용해 자잘한 기법들을 적용하는 절제와 규율 필요
- 절제와 규율을 적용해 클린 코드로 바꾸는 전략도 파악
코드 감각이 있는 프로그래머는 나쁜 모듈을 보면
- 좋은 모듈로 개선할 방안을 떠올린다
- ‘코드 감각’으로 최고 방안을 선택
- 여정을 계획

클린 코드의 정의

밥 아저씨들이 인터뷰한 수많은 guru들의 클린코드에 대한 주옥같은 정의와 주석들

보이스카우트 규칙

미국 보이스카우트 규칙 : 캠프장은 처음 왔을 떄보다 더 깨끗하게 해놓고 떠나라
이를 반영 : 체크아웃을 할 때 보다 (아주 작게라도) 더 깨끗한 코드를 체크인 해라

정리

bad code

성능이 나쁜 code : 불필요한 연산이 들어가서 개선의 여지가 있는 코드
의미가 모호한 코드 : 이해하기 어려운 코드, 네이밍과 내용이 다른 코드
중복된 코드 : 비슷한 내용인데도 중복된 코드 → 버그 양산

clean code

성능이 좋은 코드
의미가 명확한 코드 : 가독성 좋은 코드
중복이 제거된 코드

spring-mvc-RedirectAttributes

Mon, 22 Nov 2021 08:57:10 GMT

intro

원래 잘 사용하고 있는 어플리케이션에 변경 요청 사항이 생김
addAttribute로 끝내는 건줄 알고 까봤더니 마지막 view가 “redirect”접두어로 리다이렉트
Redirect는 이전 요청이 끊어지고 새로운 GET 요청 시작
따라서 Redirect 실행 이전의 모델 데이터는 소멸하므로 모델전달은 의미가 없음

RedirectAttributes

스프링이 제공
모든 플래시 속성을 세션에 복사
리다이렉션 이후 저장된 플래시 속성을 세션에서 모델로 이동

RedirectAttributes의 2 메서드

addAttribute
addFlashAttribute
차이점
- addAttribute로 전달한 값은 GET의 URL의 쿼리스트링으로 붙으며 리프레시해도 유지됨
- addFlashAttribute 전달값은 URL에 노출되지 않으며 리프레시 할 경우 데이터가 소멸(1회성)

마무리

MockMvc에서MockMvcResultMatchers.flash()로 플래시를 받아와서 플래시 속성에 접근 가능

lombok

Mon, 08 Nov 2021 01:56:49 GMT

롬복 정리

1. Opening

이미 5년도 넘게 쓰고 있는 롬복을 세삼스레 정리하게 된 것은 이펙티브 자바와 JPA 공부덕이다
세삼스럽다.

2. 롬복이란

롬복을 이용하면 특정 코드를 줄여서 가독성과 편의성을 올릴 수 있다
특히 Getter와 Setter를 엄청나게 줄일 수 있어서 애용했었는데..
오히려 그럼으로써 getter/setter를 남용하게 되는 원인이기도 하다

3. @Getter/@Setter

게터메서드, 세터 메서드 생성
필드가 아닌 클래스에 선언하는 경우 해당 클래스의 모든 필드의 게터,세터 생성
VO 클래스를 만들게 되는 경우 노가다에서 해방

4. 생성자

@NoArgsConstructor : 파라미터 없는 기본 생성자 생성
@AllArgsConstructor : 모든 필드 값을 파라미터로 받는 생성자
@RequiredArgsConstructor
- final, @NonNull 인 필드값만 파라미터로 받는 생성
- 사실 서비스나 컨트롤러도 이걸로 생성하는게 가장 깔끔하다
  - 어차피 컨트롤러는 서비스, 서비스는 JPA리포지토리등을 주입받음
  - 중간에 빈을 바꿀 일은 없음 : 처음 빈이 로딩될때 전부 설정값 반영됨
  - 그러면 해당 빈을 final로 하고 이 어노테이션을 사용하면 생성자 주입 방식 사용됨
@NonNull : 메서드 파라미터에 사용, null이 파라미터로 전달되면 예외
access 필드로 접근 권한 수정 가능
@NoArgsConstructor(access = AccessLevel.PROTECTED)
- JPA 기본 스펙상 기본 생성자 필요
- protected로 제어하는 것까지 허용되며 new로 객체생성함을 막을 수 있음

5. @ToString

이클립스나 인텔리제이가 만들어주는 ToString을 자동으로 생성
롬복을 사용하기전에는 Apache Commons Lang 라이브러리의 ToStringBuilder를 사용
보통 문제가 되는게 JPA 양방향 관계에서 잘못 사용하면 무한 순환해서 스택이 터지는 오류
그래서 개인적으로 exclude로 특정 필드 제외하는 것을 애용 했음
공부를 해보니 of를 권장 : exclude보다 새로 객체를 추가해 줄 떄 마다 수정 비용이 적다고 한다

6. @EqualsAndHashCode

equals(), hashcode()를 자동으로 생성해줌
ToString,처럼 exclude, callSuper 사용 가능
객체 직렬화에서 제외할때 사용하는 transient 키워드 사용시 exclude 효과
callSuper : 해당 속성을 통해 부모 클래스 필드까지 동일한지 체크 가능
성능 이슈가 발생할 수 있다고 한다(Set 자료 구조)

7. @Data

@Getter, @Setter, @RequiredArgsConstructor, @ToString, @EqualsAndHashCode를 한번에
사실 조금만 공부하면 실무에서는 절대 사용하지 않아야 한다.

8. @Builder

GoF 빌더 패턴을 간단하게 만들 수 있다
클래스에 설정시 @AllArgsConstructor효과가 생기므로 기피
생성자 빌더 패턴 적용시 장점
- 필요한 데이터만 설정 가능
  - 일반 생성자 사용시 필요없는 값에 더미값을 넣거나 해당 값이 없는 생성자를 새로 적용 필요
  - 빌더 사용시 동적으로 처리 : 객체 생성 용이, 코드양 줄임
- 유연성 확보
  - 파라미터 추가시 기존 코드 수정 필요. 생성 코드가 100개면 100개에 따른 수정이 필요
  - 빌더 패턴 이용시 기존 코드에 영향을 주지 않음
- 가독성 확보
  - 파라미터 증가시 리딩 효율 급격히 떨어짐
  - 빌더 패턴 적용시 가독성 유지, 직관적으로 어떤 데이터 설정인지 파악 가능
- 불변성 확보
  - Setter 사용은 불필요한 확장 가능성
    - Open-Closed 위배
    - 불필요한 코드리딩 필요
  - 따라서 클래스 변수를 final로 선언하고 객체의 생성은 빌더에 맡겨야 한다
advance
- builderClassName 파라미터로 nested 빌더 클래스의 이름을 (클래스명Builder가 기본)
- builderMethodName으로 빌더 클래스를 반환하는 static 메소드의 이름을 (builder()가 기본)
- buildMethodName으로 객체를 반환하는 빌드 메소드의 이름 (build()가 기본)을 설정할 수 있다
- @Builder.Default : 기본값 설정, 해당 값이 없으면 정해진 기본값을 토태로 빌더가 실행된다
- @Singular : List등의 컬렉션에 사용
  - builder에서 값을 추가할 떄 사용되는 메서드 이름 입력
  - 빈 컬렉션이 자동으로 생성되며, 이 컬렉션은 수정 불가
- @Builder(toBuilder = true)
  - 인스턴스에서도 builder 가능.
  - 해당 인스턴스에서 일부 값만 변경한 새로운 객체 생성 가능

9. @Cleanup

try-with-resource구문과 비슷한 효과
차이점
- try-with-resource : 구문이 종료될 때 AutoCloseable인터페이스의 close()호출
- @Cleanup : scope 종료시 어노테이션이 설정된 변수의 close() 호출

10. val

스칼라의 val 키워드 기능
객체 타입을 추론한 불변 값 선언
스클라와 달리 지역변수, foreach 구문에만 사용 가능
메소드 파라미터, 클래스 필드에 사용 불가

11. @Value

@Data어노테이션과 비슷하지만 필드를 변경할 수 없는 불변 객체를 만듬

예시

@Value
public class TestValve {
    String name;
    int val1;
    int val2;
}

빌드되면 다음과 같아진다

public final class TestValve {
    private final String name;
    private final int val1;
    private final int val2;

    public TestValve(final String name, final int val1, final int val2) {
        this.name = name;
        this.val1 = val1;
        this.val2 = val2;
    }

    public String getName() {
        return this.name;
    }

    public int getVal1() {
        return this.val1;
    }

    public int getVal2() {
        return this.val2;
    }

    public boolean equals(final Object o) {
        if (o == this) {
            return true;
        } else if (!(o instanceof TestValve)) {
            return false;
        } else {
            TestValve other = (TestValve)o;
            if (this.getVal1() != other.getVal1()) {
                return false;
            } else if (this.getVal2() != other.getVal2()) {
                return false;
            } else {
                Object this$name = this.getName();
                Object other$name = other.getName();
                if (this$name == null) {
                    if (other$name != null) {
                        return false;
                    }
                } else if (!this$name.equals(other$name)) {
                    return false;
                }

                return true;
            }
        }
    }

    public int hashCode() {
        int PRIME = true;
        int result = 1;
        int result = result * 59 + this.getVal1();
        result = result * 59 + this.getVal2();
        Object $name = this.getName();
        result = result * 59 + ($name == null ? 43 : $name.hashCode());
        return result;
    }

    public String toString() {
        String var10000 = this.getName();
        return "TestValve(name=" + var10000 + ", val1=" + this.getVal1() + ", val2=" + this.getVal2() + ")";
    }
}

@Value는 val 언노테이션 사용 → val 어노테이션 사용 가능할 때만 @Value 사용 가능

12 @Log

클래스 상단의 static final log 필드 자동 생성
SLF4J 사용하는 경우 @Slf4j를 사용하면 된다.

13. @Synchronized

Synchronized보다 더 자세한 설정이 가능한 어노테이션
Synchronized : static, insttance 단위로 락
@Synchronized: @파라미터로 입력받는 오브젝트 단위

파라미터가 없는 경우 어노테이션이 사용된 메소드 단위 락

public class TestValve {
    public static final Object OBJECT_LOCK = new Object();
    String name;
    String name2;
    int value;

    //파라미터로 입력받는 Object 단위 Lock
    @Synchronized("OBJECT_LOCK")
    public int valCalc(int value2){
        return value + value2;
    }

    @Synchronized("OBJECT_LOCK")
    public int getValue() {
        return value;
    }

    @Synchronized
    public String getName() {
        return name;
    }
    
    @Synchronized
    public String getName2() {
        return name2;
    }
}

롬복 사용시 부모 생성자 호출 불가

레퍼런스 : https://stackoverflow.com/questions/29740078/how-to-call-super-constructor-in-lombok
롬복에서 Parent에서 @AllArgsConstructor
Parent를 extend한 Child에서 super로 부모 생성자 호출 불가
리플랙션 사용시 슈퍼 클래스의 생성자를 호출할 수 없다

일반적인 경우

생성자에 builder 어노테이션을 추가하면 super 가능

@Getter
@AllArgsConstructor
public class Parent {
    private final String parentName;
    private final int parentAge;
}
@Getter
public class Child extends Parent {
    private final String childName;
    private final int childAge;
    @Builder
    public Child(String parentName, int parentAge, String childName, int childAge) {
        super(parentName, parentAge);
        this.childName = childName;
        this.childAge = childAge;
    }
}

답변 갱신

@SuperBuilder을 사용해서 상속되는 클래스 빌더 생성 가능
Lombok 1.18.2 이후부터 사용 가능

rkaehdaos in the purpleland

[Clean Code] 다 읽었다~

클린 코드 회고

Related POST

[Clean Code] XVII. 냄새와 휴리스틱

XVII. 냄새와 휴리스틱

전체 리스트

주석 - Comment

C1(부적절한 정보)

C2(쓸모 없는 주석)

C3(중복된 주석)

C4(성의없는 주석)

C5(주석 처리된 코드)

환경 - Environment

E1(여러 단계로 빌드)

E2(여러 단계로 테스트)

함수 - Function

F1(너무 많은 인수)

F2(출력인수)

F3(플래그 인수)

F4(죽은 함수)

일반 - General

G1(한 소스파일에 여러 언어)

G2(당연한 동작을 구현하지 않는다)

G3(올바로 처리되지 않은 경계)

G4(안전절차 무시)

G5 중복

G6(올바르지 못한 추상화 수준)

G7(기초 클래스가 파생 클래스에 의존)

G8(과도한 정보)

G9(죽은 코드)

G10(수직 분리된 경우)

G11(일관성 부족)

G12(잡동사니)

G13(인위적 결합)

G14(기능 욕심)

G15(선택자 인수)

G16(모호한 의도)

G17(잘못 지운 책임)

G18(부적절한 Static 함수)

G19(서술적 변수)

G20(이름과 기능이 일치하는 함수)

G21(알고리즘을 이해하라)

G22(논리적 의존성은 물리적으로 드러내라)

G23 if/else, Switch/Case 대신 다형성 사용

G24(표준 표기법)

G25(매직 숫자는 명명된 상수로 교체)

G26(정확하라)

G27(관례보다 구조 사용)

G28(조건을 캡슐화)

G29(부정조건은 피하라)

G30(함수는 한 가지만)

G31(숨겨진 시간적 결합)

G32(일관성을 유지하라)

G33(경계 조건을 캡슐화)

G34(함수는 추상화 수준을 한 단계만 내려가야 한다)

G35(설정 정보는 최상위 단계)

G36(추이적 탐색을 피하라)

자바 - JAVA

J1(긴 import 대신 wild 카드 사용)

J2(상수는 상속하지 않는다)

상수 대 Enum

이름 - Name

N1(서술적인 이름 사용)

N2(적절한 추상화 수준에서 이름 선택)

N3(가능하다면 표준 명명법)

N4(명확한 이름)

N5(긴 범위는 긴 이름을 사용하라)

N6(인코딩을 피하라)

N7(이름으로 부수효과를 설명하라)

테스트 - Test

T1(불충분한 테스트)

T2(커버리지 도구 사용)

T3(사소한 테스트를 건더 뛰지 마라)

T4(무시한 테스트는 모호함을 뜻함)

T5(경계 조건 테스트하라)

T6(버그 주변은 철저히 테스트)

T7(실패 패턴을 살펴라)

T8(테스트 커버리지 패턴을 살펴라)

T9(테스트는 빨라야 한다)