맨위로가기

중복배제

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

중복 배제(DRY, Don't Repeat Yourself) 원칙은 소프트웨어 개발에서 코드 중복을 피하기 위한 원칙이다. 이는 "단일 선택 원칙"의 한 예시로, 시스템 내에서 특정 대안들의 완전한 목록을 단 하나의 모듈만 알고 있도록 하는 것을 의미한다. DRY 원칙은 WET(Write Everything Twice)와 AHA(Avoid Hasty Abstractions)와 대조되며, 코드의 기능적 행동에 초점을 맞춘 OAOO(Once and Only Once) 원칙과도 구분된다. DRY 원칙은 소규모 컨텍스트, 커뮤니티 참여, 구성 관리, 인간이 읽는 문서, 자동 프로그래밍, 단위 테스트 등 특정 상황에서는 유용하지 않을 수 있으며, 다른 설계 원칙과의 균형을 고려하여 적용해야 한다.

더 읽어볼만한 페이지

  • 프로그래밍 원칙 - 블랙박스
    블랙 박스는 자극 입력과 출력 반응의 관점에서 시스템을 추상화하여 외부적으로 관찰하는 이론으로, 전자 회로 이론, 사이버네틱스, 시스템 이론 등 다양한 분야에서 활용되며 예측 모델 구축 및 유효성 검증, 그리고 항공기 비행 기록 장치나 함수 교육 도구 등 실생활에도 응용된다.
  • 프로그래밍 원칙 - 정보 은닉
    정보 은닉은 소프트웨어 설계에서 모듈 내부 구현을 숨기고 정의된 인터페이스를 통해서만 상호 작용하도록 하여 모듈 독립성을 높이고 시스템 복잡성을 관리하는 데 중요한 기법으로, 객체 지향 프로그래밍의 캡슐화와 관련된다.
중복배제
일반 정보
원어 명칭Don't repeat yourself (DRY)
다른 이름Duplication Is Evil (DIE)
유형소프트웨어 개발 원칙
목표정보 중복 방지
창시자앤드루 헌트
데이브 토마스
처음 언급프래그매틱 프로그래머
영향유지 보수성 향상
코드 가독성 향상
소프트웨어 개발 비용 절감
관련 개념한 번만 말하기
추상화
데이터베이스 정규화
관례 우선 구성
직교성
상세 내용
설명모든 지식은 시스템 내에서 단 한 번, 명확하고 권위 있게 표현되어야 한다.
문제점정보 중복은 코드 유지 보수 및 리팩토링을 어렵게 만들고, 일관성 없는 코드 발생 가능성을 높인다.
해결책코드, 데이터, 문서 등 모든 영역에서 중복을 제거하고 추상화를 통해 코드를 재사용하며, 데이터베이스 정규화를 통해 데이터 중복을 최소화한다.
적용 분야소프트웨어 개발
데이터베이스 설계
문서 작성
지식 관리
추가 정보
참고 서적프래그매틱 프로그래머
객체지향 소프트웨어 공학
관련 링크Orthogonality and the DRY Principle (Dave Thomas 인터뷰)

2. 단일 선택 원칙 (Single Choice Principle)

'''단일 선택 원칙'''은 DRY 원칙의 특별한 경우이다. 베르트랑 메이어는 소프트웨어 시스템이 일련의 대안을 지원해야 할 때, 시스템 내의 단 하나의 모듈만이 해당 대안들의 완전한 목록을 알고 있어야 한다고 정의했다.[3] 이 원칙은 에펠을 설계할 때 적용되었다.

3. 대안

3. 1. WET (Write Everything Twice)

DRY의 반대 개념은 WET이라고 불리며, 일반적으로 "모든 것을 두 번 쓰기"[4](또는 "매번 쓰기", "타이핑을 즐기자", "모두의 시간을 낭비하기"[4])를 의미하는 두문자어이다. WET 솔루션은 다중 계층 아키텍처에서 흔히 발생한다. 예를 들어 개발자가 웹 애플리케이션의 양식에 댓글 필드를 추가하는 작업을 할 때, "comment"라는 텍스트 문자열은 레이블, HTML 태그, 읽기 함수 이름, 개인 변수, 데이터베이스 DDL, 쿼리 등에서 반복될 수 있다. DRY 접근 방식은 프레임워크를 사용하여 이러한 중복성을 제거하고, 새로운 지식 변수를 한 곳에서 추가할 수 있는 확장성을 제공한다.[5]

"WET"을 "DRY" 프로그래밍의 대안으로 개념화하는 것은 적어도 2002년부터 자바 세계에서 존재해 왔지만, 이 용어를 누가 만들었는지는 알려지지 않았다.[6]

3. 2. AHA (Avoid Hasty Abstractions)

AHA는 "조급한 추상화 회피(Avoid Hasty Abstractions)"의 약자로, 켄트 C. 도즈가 설명하였다. 우선 변경에 최적화하고 조기 최적화를 피하는 것을 의미한다.[7] 이는 샌디 메츠의 "잘못된 추상화보다 중복을 선호하라"는 개념의 영향을 받았다.[8]

AHA는 엔지니어가 소프트웨어 조각을 추상화하는 데 더 깊이 투자할수록, 해당 투자의 비용을 결코 회수할 수 없다고 인식한다는 점(매몰 비용 오류)을 이해하는 데 기반을 두고 있다. 따라서 엔지니어는 요구 사항이 변경될 때마다 동일한 추상화를 반복하는 경향이 있다. AHA 프로그래밍은 WET 및 DRY 솔루션 모두 필연적으로 유지 관리가 어렵고 경직된 소프트웨어를 만든다고 가정한다. 추상화부터 시작하거나 특정 횟수의 중복에서 추상화하는 대신, 추상화가 필요할 때 또는 중복 자체가 장벽이 되었고 추상화가 어떻게 작동해야 하는지 알게 되었을 때 추상화를 수행하면 소프트웨어가 더 유연하고 강력해질 수 있다.

AHA 프로그래밍은 원래 도즈에 의해 "moist code"로 명명되었고, 나중에 다니엘 바르톨로메에 의해 다시 명명되었다.[9] 원래는 맷 라이어에 의해 DAMP (''Don't Abstract Methods Prematurely'', 조기에 메서드를 추상화하지 마라)라고 불렸다.[10] 이미 제이 필즈가 설명한 DAMP (''Descriptive And Meaningful Phrases'', 설명적이고 의미 있는 구문)라는 다른 프로그래밍 원칙이 있었고,[11] 커뮤니티는 "moist"라는 단어에 대한 문화적 반감 때문에 MOIST의 사용에 반대했다.[12] 도즈는 트위터에서 대안을 요청했고, 체르 스칼렛이 AHA를 제안하기 전에 DATE를 대안으로 제안했다.[2][13][14]

4. Once and Only Once 원칙과의 대조

DRY 원칙은 애플리케이션에 필요한 정보(설정 정보 등)에 중점을 두는 반면, '''Once and Only Once''' (OAOO) 원칙은 코드의 기능적인 행동에 중점을 둔다는 점에서 구별된다. OAOO는 구조체나 객체 지향 언어에서의 상속을 구현해야 하는 이유가 된다.

예를 들어, DRY는 파일 집합의 위치는 애플리케이션 내 한 곳에만 저장해야 한다고 주장하지만, 이러한 파일에서 데이터를 가져오는 처리를 애플리케이션의 다른 부분에서 기술하는 횟수에 대해서는 관대하다. 반면, OAOO 원칙은 파일에서 데이터를 얻는 코드는 한 번만 작성하도록 요구하지만, 애플리케이션 내에서 이러한 파일을 배치하는 장소가 여러 곳에 있는 것에 대해서는 관대하다.

객체는 변수로서 저장되고 정보의 일부로 여겨지기 때문에 DRY는 객체에 적용되어 인스턴스를 하나만 갖는 반면, OAOO는 클래스에 적용된다는 점이 혼란을 야기할 수 있다.

5. DRY 원칙이 유용하지 않은 경우


  • 소규모 컨텍스트에서는 DRY에 기반하여 설계하는 노력이 두 개의 별도 데이터의 복사본을 유지 관리하는 노력보다 훨씬 커진다.
  • wiki 등 커뮤니티 참여에 높은 가치가 있는 컨텍스트에서는 DRY 원칙을 엄수하도록 하는 표준의 강요는 커뮤니티 참여를 저해할 수 있다.
  • 구성 관리와 버전 관리는 DRY 원칙을 벗어나지 않고 동일한 코드 복사본을 허용한다. 예를 들어, 개발용 환경, 테스트용 환경, 제품판 코드용 환경을 구축하여 진행 중인 개발과 테스트가 제품 코드를 영향을 주지 않도록 하는 방법이 있다.
  • 인간이 읽을 수 있는 문서 (코드 주석에서 인쇄된 매뉴얼까지)는 일반적으로 코드를 내부까지 읽고 이해할 능력이나 시간이 없는 사람들을 위해 다듬고, 설명을 덧붙여 코드 내부에 있는 것을 다시 기술하고 있다. 그러나 DRY에서는 인간이 읽을 수 있는 문서는 형식 변경을 제외하고는 아무런 가치가 없으며, 즉 기술될 것이 아니라 생성되어야 한다고 한다.
  • 소스 코드 생성 - 중복 금지는 소스 코드 생성에 도움이 되지만, 이는 출력 결과에 대해서가 아니라 중복된 정보가 인간이나 다른 코드에 의해 변경되지 않는 경우에만 해당된다.
  • 단위 테스트 - 소스 코드와의 모순을 찾아내는 것이 목적이며[16], 소스 코드에서 자동 생성해서는 안 된다. 다만, 소스 주석이나 문서로부터 자동 생성하는 것은 가능하다.[17]
  • 아벨 아브람(Abel Avram)은 DRY를 과도하게 추구함으로써 느슨한 결합 원칙이 파괴되는 예를 보여주며, DRY는 어디까지나 다른 원칙과의 균형 속에서 지켜져야 한다고 말했다.[16]

참조

[1] 서적 The Pragmatic Programmer : From Journeyman to Master https://archive.org/[...] Addison-Wesley 1999
[2] 웹사이트 Orthogonality and the DRY Principle http://www.artima.co[...] 2006-12-01
[3] 문서 Object Oriented Software Construction, 2nd edition, page 63
[4] 서적 .NET Design Patterns https://books.google[...] Packt Publishing Ltd 2017-01-31
[5] 웹사이트 DRY is for losers http://www.theserver[...] 2013-08-31
[6] 웹사이트 JavaOne 2002: Zig's Notes http://ziggr.com/jav[...] 2024-01-09
[7] 웹사이트 AHA Programming https://kentcdodds.c[...] 2021-05-08
[8] 웹사이트 The Wrong Abstraction https://sandimetz.co[...] 2021-05-08
[9] 웹사이트 Moist code - Why code should not be completely DRY https://startup-cto.[...] 2020-08-21
[10] 웹사이트 Using DRY, WET & DAMP code https://evhaus.mediu[...] 2021-11-11
[11] 웹사이트 DRY code, DAMP DSLs http://blog.jayfield[...] 2021-11-11
[12] 뉴스 Why do so many people dislike the word "moist"? This scientist has a theory. https://www.vox.com/[...] Vox Media 2016-04-28
[13] 웹사이트 3 Minutes with Kent: Write the code first, then make the abstraction https://www.briefs.f[...] 2021-03-27
[14] 웹사이트 JS Party – Episode #186: Getting hooked on React https://changelog.co[...] 2021-07-30
[15] 웹사이트 Orthogonality and the DRY Principle http://www.artima.co[...] 2003-10-10
[16] 웹사이트 DRY原則の利用: コードの重複と密結合の間 http://www.infoq.com[...] 2012-05-31
[17] 웹사이트 VB.net 開発のための単体テスト項目表作成ツール『UT.Browser』 http://utbrowser.cli[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com