노트

DRY 원칙

Don't Repeat Yourself

설계#architecture · 연결된 개념 15개

쉽게 말하면

DRY 원칙은 가족 행사 날짜를 각자 수첩에 따로 적지 말고 공용 달력 한 곳에만 적자는 거예요. 날짜가 바뀌어도 한 곳만 고치면 되니, 누구는 옛 날짜로 찾아오는 일이 안 생겨요.

비유가 깨지는 곳 날짜가 똑같이 적혀 있다고 늘 같은 일정은 아니에요. 겉모양이 비슷한 코드라도 서로 다른 이유로 바뀌는 지식이면, 성급히 합칠 때 오히려 결합만 생기니 같은 지식일 때만 묶어요.

"모든 지식은 시스템 안에서 단일하고 명확하며 권위 있는 표현을 하나만 가져야 한다." 앤디 헌트와 데이브 토머스가 『실용주의 프로그래머』에서 정리한 원칙이다. 코드 줄의 반복만이 아니라 규칙·데이터·지식의 중복을 말한다.

  • 중복된 지식은 바뀔 때 모든 곳을 함께 고쳐야 하고, 하나라도 놓치면 불일치와 버그가 된다(산탄총 수술과 뒤엉킨 변경)
  • 켄트 벡은 TDD(Test-Driven Development)를 설명하며 "의존성이 문제라면 중복은 그 증상"이라고 했다. 중복을 없애면 의존성도 함께 사라진다(테스트 주도 개발 (TDD))
  • 숨은 중복도 있다. 서버와 클라이언트가 같은 타입과 검증 규칙을 따로 정의하는 것, 엔티티·DTO(Data Transfer Object)에 같은 필드를 나열하는 것 등이다(심플 디자인)
  • 데이터베이스에서 같은 사실을 여러 곳에 저장하지 않는 정규화(Normalization)도 같은 원칙이다

주의

겉모양이 같다고 같은 지식은 아니다. 우연히 비슷한 코드를 성급하게 합치면 두 쪽이 다른 이유로 바뀔 때 오히려 결합만 생긴다. 언제 합칠지는 3의 법칙가, 같은 값이라도 의미가 다르면 묶지 말라는 예는 매직 넘버와 설명 상수가 보여 준다.

출처: 『실용주의 프로그래머』 앤디 헌트·데이브 토머스 (원서 The Pragmatic Programmer) · Laws of Software Engineering: DRY (Don't Repeat Yourself)

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 섣부른 최적화

    "섣부른 최적화는 모든 악의 근원이다." 도널드 크누스(Donald Knuth)가 1974년 글 「Structured Programming with go to Statements」에서 쓴 말이다. 원문의 맥락은 작은 효율은 대부분(약 97%)의 경우 잊으라는 것이고, 정말 중요한 3%는 놓치지 말라는 말이 이어진다.

  • 결합도

    한 요소를 바꿀 때 다른 요소도 바꿔야 하는 관계. 결합도는 언제나 "어떤 변경에 대해" 결합되어 있는지를 함께 말해야 의미가 있다. 같은 두 모듈도 어떤 변경에는 묶여 있고 어떤 변경에는 독립적일 수 있다.

  • 4인치 반사경 먼저 (톰슨의 법칙)

    6인치 반사경 하나를 만드는 것보다 4인치를 먼저 만들고 6인치를 만드는 편이 더 빠르다.

  • 의존성 역전 원칙

    고수준 모듈(업무 규칙)이 저수준 모듈(데이터베이스(DB), HTTP(Hypertext Transfer Protocol) 클라이언트 같은 세부 구현)에 직접 의존하지 않고, 둘 다 추상화에 의존해야 한다는 원칙. 의존 방향이 "업무 → 세부"에서 "세부 → 추상화 ← 업무"로 뒤집힌다.

  • SOLID 원칙

    객체지향 설계를 위한 다섯 가지 원칙의 머리글자. 로버트 C. 마틴(Robert C. Martin)이 정리했고 마이클 페더스(Michael Feathers)가 SOLID라는 약어를 붙였다.

보기 옵션