반복하지 않기

Don't repeat yourself

"반복하지 마세요"(DRY)는 변경 가능성이 높은 정보의 반복을 줄이고, 변경 가능성이 낮은 추상화로 대체하거나, 애초에 중복을 피하는 데이터 정규화를 사용하는 것을 목표로 하는 소프트웨어 개발의 원칙입니다.

DRY 원칙은 "모든 지식은 시스템 내에서 명확하고 권위적인 단일 표현을 가져야 한다"고 명시되어 있습니다. 이 원칙은 앤디 헌트와 데이브 토마스가 그들의 책 실용주의 프로그래머에서 공식화했습니다.[1] 그들은 데이터베이스 스키마, 테스트 계획, 빌드 시스템, 심지어 문서화까지 이를 매우 광범위하게 적용합니다.[2] DRY 원리가 성공적으로 적용되면 시스템의 단일 요소를 수정하더라도 논리적으로 관련이 없는 다른 요소를 변경할 필요가 없습니다. 또한 논리적으로 관련된 요소는 모두 예측 가능하고 균일하게 변화하며, 따라서 동기화를 유지합니다. Thomas와 Hunt는 코드에 메서드와 서브루틴을 사용하는 것 외에도 코드 생성기, 자동 빌드 시스템, 스크립트 언어를 사용하여 여러 계층에서 DRY 원리를 준수합니다.

단일선택원칙

DRY의 특정한 경우는 단일 선택 원칙입니다. 버트런드 마이어(Bertrand Meyer)는 다음과 같이 정의했습니다. "소프트웨어 시스템이 일련의 대안을 지원해야 할 때마다 시스템에 있는 하나의 모듈만 전체 목록을 알아야 합니다."[3] 에펠탑을 디자인할 때 적용되었습니다.

대안

WET

DRY에 대한 반대 견해는 WET라고 불리는데, 이는 일반적으로 모든 것을 두[4] 번 쓰기 위해 사용되는 등의 용어입니다(또는 매번 쓰기를 즐기거나 모두의 시간을 낭비합니다). WET 솔루션은 개발자가 예를 들어 웹 애플리케이션의 양식에 주석 필드를 추가하는 작업을 수행할 수 있는 다중 계층 아키텍처에서 일반적입니다. 텍스트 문자열 "comment"는 레이블, HTML 태그, 읽기 함수 이름, 개인 변수, 데이터베이스 DDL, 쿼리 등에서 반복될 수 있습니다. DRY 접근 방식은 가장 중요한 작업을 제외한 모든 편집 작업을 줄이거나 제거하는 프레임워크를 사용하여 중복성을 제거함으로써 새로운 지식 변수를 한 곳에 추가할 수 있는 확장성을 제공합니다.[5] 케빈 그리어는 이 프로그래밍 원리를 명명하고 설명했습니다.[6][7]

아하.

추상화에 대한 또 다른 접근법은 AHA 원칙입니다. AHA는 Kent C가 설명한 성급한 추상화를 피한다는 의미입니다. 변화를 위해 먼저 최적화하고, 조기 최적화를 피하는 것이 좋습니다.[8] Sandi Metz의 "잘못된 추상화보다 복제를 선호합니다"에서 영향을 받았습니다.[9]

AHA는 투자 엔지니어가 소프트웨어를 추상화하는 데 더 깊이 노력할수록 그 투자 비용을 결코 회수할 수 없다고 인식한다는 것에 뿌리를 두고 있습니다(Sunk Cost 오류). 따라서 엔지니어는 요구 사항이 변경될 때마다 동일한 추상화를 계속 반복하는 경향이 있습니다. AHA 프로그래밍은 WET 솔루션과 DRY 솔루션 모두 필연적으로 경직되고 유지 관리가 어려운 소프트웨어를 생성한다고 가정합니다. 소프트웨어는 추상화로 시작하거나 특정 복제 횟수로 추상화하는 대신 필요할 때 추상화를 수행하거나 복제 자체가 장벽이 되어 추상화가 어떻게 작동해야 하는지 알 수 있는 경우 더 유연하고 강력할 수 있습니다.

AHA 프로그래밍은 원래 Dodds에 의해 "moist code"로 명명되었고, 나중에 Daniel Bartholomae에 의해 다시 명명되었으며,[10] Matt Ryer에 의해 DAMP(Don't Abstract Methods Injirly)로 언급되었습니다.[11] Jay Fields가 설명하고 DAMP(Descriptive and Angulous Phrases)라는 이름의 다른 프로그래밍 원칙이 있었고,[12] 커뮤니티는 모이스트라는 단어에 대한 문화적 혐오로 인해 모이스트 사용에 반대했습니다.[13] Dodds는 트위터에서 대안을 요구했고, Cher Scarlett의 AHA 제안에 합의하기 전에 대안으로 DATE를 제안했습니다.[8][14][15]

참고 항목

참고문헌

  1. ^ Hunt, Andrew; Thomas, David (1999). The Pragmatic Programmer : From Journeyman to Master (1 ed.). US: Addison-Wesley. pp. 320. ISBN 978-0201616224.
  2. ^ Dave Thomas, interviewed by Bill Venners (2003-10-10). "Orthogonality and the DRY Principle". Retrieved 2006-12-01.
  3. ^ 객체 지향 소프트웨어 구성, 2판, 63페이지
  4. ^ Pai, Praseed; Xavier, Shine (2017-01-31). .NET Design Patterns. Packt Publishing Ltd. ISBN 978-1-78646-186-5.
  5. ^ Justin Lee (2006-03-08). "DRY is for losers". Retrieved 2013-08-31.
  6. ^ Alex Papadimoulis (2011-12-08). "The WET Cart". Retrieved 2012-05-21.
  7. ^ Kevin Greer (2016-02-05). "FOAM DRY + WET". YouTube. Archived from the original on 2021-12-21. Retrieved 2016-03-09.
  8. ^ a b Kent C. Dodds (2019-04-01). "AHA Programming". Retrieved 2021-05-08.
  9. ^ Sandi Metz (2016-01-20). "The Wrong Abstraction". Retrieved 2021-05-08.
  10. ^ Bartholomae, Daniel (21 August 2020). "Moist code - Why code should not be completely DRY". The Startup CTO. Retrieved 11 November 2021.
  11. ^ Haus, Ev (24 December 2020). "Using DRY, WET & DAMP code". Medium. Retrieved 11 November 2021.
  12. ^ Fields, Jay. "DRY code, DAMP DSLs". Jay Fields' Thoughts. Retrieved 11 November 2021.
  13. ^ Resnick, Brian (28 April 2016). "Why do so many people dislike the word "moist"? This scientist has a theory". Vox Media. Retrieved 11 November 2021.
  14. ^ Dodds, Kent (27 March 2021). "3 Minutes with Kent: Write the code first, then make the abstraction". Briefs. Retrieved 11 November 2021.
  15. ^ Dodds, Kent; Bostian, Emma; Nisi, Nick (30 July 2021). "JS Party – Episode #186: Getting hooked on React". The Changelog. Retrieved 11 November 2021.

외부 링크