DRY 원칙 C#: 코드 중복이 코드베이스를 해치고 있는 이유 – Derek Comartin의 설명

DRY 원칙 정의

영상 초반에 데릭은 많은 개발자들이 직면하는 상황, 즉 수정하기 어려운 시스템, 반복되는 코드와 불필요한 로직이 뒤얽힌 시스템을 다루는 상황을 설명합니다.

그는 C#에서 코드 반복을 줄이기 위한 전략으로 DRY 원칙을 소개하지만, 이 원칙이 종종 오해되는 경우가 있다고 경고합니다. 데릭이 0:28에서 설명하는 것처럼:

"DRY 원칙이 성공적으로 적용되면 시스템의 어떤 한 요소를 수정하더라도 논리적으로 관련 없는 다른 요소는 변경할 필요가 없습니다."

이 차이점은 매우 중요합니다. DRY 원칙은 단순히 코드 중복을 피하는 것뿐만 아니라, 관심사 분리와 적절한 코드 재사용을 촉진하여 유지보수하기 쉽고, 불필요한 내용이 없는 코드를 만들어 테스트와 리팩토링을 용이하게 하는 것을 목표로 합니다.

실제 사례: 거리 변환

이해를 돕기 위해 데릭은 C#으로 작성된 간단한 예제를 제시합니다. 그는 두 가지 방법을 제시합니다.

• 배송거리

• 통행료 거리

두 방법 모두 거리를 마일로 계산한 다음 동일한 논리를 사용하여 킬로미터로 변환합니다. 이것은 전형적인 코드 중복입니다.

데릭은 동일한 코드를 여러 곳에 두는 대신, 변환 로직을 MilesToKilometers()라는 비공개 메서드로 추출하는 방법을 보여줍니다. 이는 코드 재사용성을 높이기 위한 기본적이면서도 효과적인 리팩토링 방법입니다.

그는 일반적인 콘솔 앱 구조, 즉 정적 void Main을 가진 Program 클래스를 사용하여 이를 설명합니다. 이는 많은 개발자들이 로직을 테스트하거나 public int age, string username, string password 등과 같은 새로운 사용자 입력 시나리오를 실험할 때 사용하는 구조입니다.

건식 vs. 과결합

로직을 재사용 가능한 메서드나 별도의 클래스로 추상화하는 것이 이상적으로 들리지만, 데릭은 신중을 기할 것을 당부합니다. DRY 원칙을 과도하게, 특히 애플리케이션 전체에 적용하면 위험할 정도로 결합도가 높아질 수 있습니다.

예를 들어, 여러 프로젝트에서 사용하는 공유 유틸리티에 변환 로직을 배치한 후 나중에 반올림 동작이나 소수점 정밀도를 변경하면 해당 변경 사항이 예기치 않게 여러 영역에 영향을 미칠 수 있습니다. 데릭이 2분 31초에 말했듯이:

"고객들이 소수점 두 자리까지 기대하는 건가요?" 만약 이 값을 0으로 바꾸면 어떻게 될까요?

이는 시스템의 여러 부분에서 재사용되는 논리라는 점에서 여러 분야에 걸쳐 발생하는 문제이며, 너무 일찍 또는 명확한 경계 없이 중앙집권화할 경우 발생할 수 있는 위험성을 보여줍니다.

데릭의 조언은 코드의 적응성과 모듈성을 유지하는 데 중요한 두 가지 SOLID 원칙인 단일 책임 원칙과 의존성 역전 원칙을 반영합니다.

DRY로 인한 코드 비대화의 잘못된 결과

DRY 원칙을 잘못 사용했을 때 발생하는 또 다른 문제는 코드 비대화입니다. 모든 것을 추상화하려다 보면 유틸리티 클래스가 지나치게 커지거나 메서드가 지나치게 일반화되는 경우가 있습니다. 데릭은 논리를 지나치게 DRY하게 규정하는 것이 도움이 되기보다는 오히려 해가 될 수 있다고 경고합니다. 특히 대규모 시스템에서는 한 영역의 버그 수정이 공유된 의존성 때문에 다른 영역을 망가뜨릴 수 있기 때문입니다.

데릭에 따르면 핵심은 코드를 공유하지 말아야 할 때를 아는 것, 특히 공유로 인해 모듈 간 결합도가 높아지는 경우를 아는 것입니다. DRY는 규칙이 아닙니다. 이는 맥락에 맞춰 사용해야 하는 지침입니다.

DRY 원칙을 개체에 적용하기: 복잡성을 위한 레시피

데릭은 개발자들이 흔히 보이는 경향, 즉 시스템을 트럭, 주문, 운전사, 배송과 같은 요소들을 중심으로 완전히 구성하는 경향을 지적합니다. 여러 메서드에서 동일한 클래스나 객체를 재사용하고 싶은 유혹이 들지만, 이는 종종 개념의 반복과 원치 않는 결합으로 이어집니다.

그는 데이터 구조뿐 아니라 비즈니스 역량이 아키텍처를 주도해야 한다고 주장합니다. 예를 들어, "주문 발송"은 "트레일러 분리"와 관련이 있더라도 서로 다른 문제입니다.

4시 45분에 데릭은 다음과 같이 설명합니다.

"시스템 내의 단일 개체가 여러 개념을 나타낼 필요는 없습니다."

이는 더 심층적인 아키텍처적 통찰력을 보여줍니다. 즉, 동일한 이름(차량, 트레일러)을 가진 개체가 서로 다른 워크플로에서 서로 다른 역할을 나타낼 수 있다는 것입니다. 이 둘을 혼용하면 혼란을 야기하고 관련 없는 비즈니스 로직을 지나치게 결합시킵니다.

DRY 및 비즈니스 역량

이 문제를 해결하기 위해 데릭은 계층 구조 대신 비즈니스 기능을 중심으로 애플리케이션을 구성하는 패턴인 수직 슬라이스 아키텍처(VSA)를 도입했습니다. 각 "슬라이스"에는 요청부터 데이터베이스까지 특정 작업이나 사용 사례에 필요한 모든 것이 캡슐화되어 자체적으로 포함되어 있습니다.

그는 DRY 원칙이 코드의 특정 부분, 즉 단일 위치 내에서는 유용하지만, 여러 부분에 걸쳐 DRY를 적용하면 코드 간의 의존성이 복잡하게 얽힐 수 있다고 강조합니다. 6시 44분에 그는 다음과 같이 덧붙입니다.

"핵심은 결합도를 낮추고 응집도를 높이는 것입니다..." 그렇게 하는 한 가지 방법은 정해진 범위 내에서 개념을 반복하지 않는 것입니다.

이러한 경계 중심적 사고방식은 유연성을 제공합니다. 한 영역에는 전체 도메인 모델이 있고, 다른 영역에는 경량 데이터 모델만 있을 수 있습니다. 이는 해당 부분의 필요에 따라 달라지며, 실용적인 프로그래머의 철학에 부합하는 실용적인 접근 방식입니다.

마지막으로

데릭은 DRY를 법이 아닌 도구로 재해석하며 마무리합니다. 그가 7시에 말한 내용은 다음과 같습니다.

"핵심은 어떻게 적용하느냐를 이해하는 것입니다." 만약 이를 과도하게 적용한다면, 잠재적으로 결합도가 높아질 수 있습니다.

따라서 유효성 검사 로직, 연결 문자열을 추출하거나 반복적인 코드를 별도의 메서드로 변환하기 전에, 그렇게 하는 것이 실제로 전체 코드베이스의 유지 관리성을 향상시킬지, 아니면 변경하기만 더 어렵게 만들지 고려해 보세요.

결론

데릭 코마틴이 C#에서 DRY 원칙을 분석한 내용은, 겉보기에는 간단해 보이는 규칙이라도 미묘한 차이를 고려하지 않고 적용하면 어떻게 역효과를 낳을 수 있는지를 보여줍니다. 코드 예제를 살펴보고, 실제 시나리오를 논의하며, 소프트웨어 설계 원칙을 강조함으로써 그는 재사용성과 모듈성 사이의 균형이 필요하다는 것을 보여줍니다.

개발 프로세스를 크게 향상시키려면 다음 사항을 기억하세요.

• DRY 원칙을 준수하여 명확한 경계 내에서 중복되는 코드를 리팩토링하세요.

• 서로 다른 사업 목적을 수행하는 법인을 분리하지 마십시오.

• 논리를 중앙 집중화할 때는, 특히 여러 곳이나 프로젝트에 걸쳐 있을 때는 맥락을 고려해야 합니다.

• 단위 테스트와 의존성 주입이 공유 코드에 미칠 수 있는 영향을 고려하십시오.

이러한 교훈을 적용하면 더욱 효율적이고 모듈화되고 유지보수하기 쉬운 C# 코드를 작성할 수 있으며, 중복된 로직과 얽히고설킨 의존성으로 코드베이스가 엉망이 되는 것을 방지할 수 있습니다.

더 자세한 내용을 알고 싶으시면 CodeOpinion의 YouTube 채널 에서 데릭 마틴의 전체 영상을 시청하세요.