노트3의 법칙
Rule of Three
설계#refactoring · 연결된 개념 9개
쉽게 말하면
3의 법칙은 비슷한 일을 세 번째 할 때 정리하라는 경험칙이에요. 처음 본 사람은 낯설고 두 번째는 우연 같지만, 세 번째 마주치면 '아, 이웃이구나' 하고 알게 되는 것처럼 공통점이 드러나요.
비유가 깨지는 곳 숫자 3이 절대 규칙은 아니에요. 심플 디자인은 중복이 보이는 즉시 줄이라고 더 적극적으로 말해요. 중요한 건 우연히 같은 걸 억지로 묶지 않는 거예요.
비슷한 일을 세 번째 할 때 리팩터링하라는 경험칙. 돈 로버츠(Don Roberts)가 제시했고 『리팩터링』에 소개됐다.
- 처음에는 그냥 한다
- 두 번째로 비슷한 일을 하면 중복이 거슬려도 일단 진행한다
- 세 번째에는 리팩터링한다
- 두 개만으로는 무엇이 공통이고 무엇이 우연히 같은지 판단하기 어렵다. 세 개쯤 모이면 공통점이 드러나 더 나은 추상화를 고를 수 있다
- 너무 이른 추상화는 추측성 일반화가 되고, 잘못 뽑은 공통 함수는 중복보다 다루기 어렵다
- 반대로 중복을 계속 방치하면 산탄총 수술이 된다. 3의 법칙은 DRY 원칙 원칙을 언제 적용할지에 대한 타이밍 감각이다
- 심플 디자인의 입장은 더 적극적이다. 중복은 보이는 즉시 줄일 대상이고, 다만 중복이 아닌 것을 억지로 뽑지 말라고 한다. 초보일수록 규칙을 극단적으로 따라 보라는 조언과 함께 보면 좋다
출처: 『리팩터링 2판』 마틴 파울러 (원서 Refactoring, 2nd Edition) · Refactoring.Guru: When to Refactor
연결된 개념
이 노트를 가리키는 문서
뜻이 가까운 노트
- 섣부른 최적화
"섣부른 최적화는 모든 악의 근원이다." 도널드 크누스(Donald Knuth)가 1974년 글 「Structured Programming with go to Statements」에서 쓴 말이다. 원문의 맥락은 작은 효율은 대부분(약 97%)의 경우 잊으라는 것이고, 정말 중요한 3%는 놓치지 말라는 말이 이어진다.
- 소프트웨어 공학의 법칙들
소프트웨어 시스템과 팀, 의사결정에 반복해서 나타나는 경험칙들을 모아 부르는 말. 법칙이라고 부르지만 대부분 증명된 정리가 아니라 관찰과 격언이다. 판단할 때 떠올릴 이름표로 쓴다. 따로 노트를 둔 것은 링크로, 나머지는 한 줄로 적었다.
- 리팩터링 기법 카탈로그
리팩터링 기법을 무엇을 정리하는지에 따라 묶어 본 지도. 기법마다 거의 항상 반대 방향 기법이 짝으로 있어서(추출↔인라인, 올리기↔내리기) 상황에 따라 양쪽으로 오간다. 아래 묶음은 Refactoring.Guru 카탈로그(1판 기반)의 분류를 따랐고, 기법 이름은 2판 기준으로 적었다.
- 디미터 법칙
객체는 직접 아는 친구하고만 이야기하고, 친구의 친구에게 말을 걸지 말라는 원칙. a.getB().getC().doSomething() 같은 체인 호출을 피해 결합도를 낮춘다.
- 테스트 주도 개발 (TDD)
코드를 쓰기 전에 실패하는 자동화된 테스트부터 쓰고, 그 테스트를 통과시킨 뒤 중복을 없애는 짧은 주기를 반복하는 개발 방식. 켄트 벡이 정리했다.