GN⁺: 코드를 성급하게 DRY하지 마세요
(testing.googleblog.com)코드 중복 제거를 너무 일찍 하지 말아야 하는 이유
- DRY(Don't Repeat Yourself) 원칙을 너무 엄격하게 적용하면 "Premature" 추상화를 유발하여 미래의 변경이 더 복잡해질 수 있음
- 중복이 진짜로 불필요한지, 아니면 시간이 지나면서 독립적으로 발전할 기능인지 생각해야 함
- 함수나 클래스가 동일해 보여도 서로 다른 맥락과 비즈니스 요구사항을 가질 수 있음
- 코드를 짧게 만드는 것보다 함수의 목적이 시간이 지나도 유지되는지 생각해야 함
-
추상화의 위험: 기능이 다르게 발전할 가능성이 있는 경우, 추상화가 오히려 해로울 수 있음.
- 추상화를 설계할 때, 장기적으로 별도로 발전할 수 있는 동작을 조기에 결합하지 말아야 함
- 의심스러울 때는 시간이 지나면서 결합을 정당화하는 충분한 공통 패턴이 나타날 때까지 동작을 분리해 두어야 함
- 작은 규모에서는 Premature 추상화의 복잡성을 해결하는 것보다 중복을 관리하는 것이 더 간단할 수 있음
- 개발 초기에는 약간의 중복을 허용하고 추상화를 기다려야 함
- 미래의 요구사항은 종종 예측할 수 없음
- YAGNI(You Aren't Gonna Need It) 원칙에 대해 생각해 보아야 함
- 중복이 문제가 되지 않을 것이거나, 시간이 지나면서 충분히 고려된 추상화의 필요성을 분명히 나타낼 것임
애초에 DRY 의 적용은 Repeat 하고 있다면 이를 줄이는 식으로 적용해야하는데,
DRY 을 앞선 기준으로 코드를 생각하면 잘못된 적용인 것 같습니다.
Hacker News 의견 중
DRY 원칙의 오해: DRY는 코드 중복이 아닌 정보/지식 중복을 방지하는 것임. 코드 중복에만 집중하면 불필요한 최적화로 이어질 수 있음.
이 의견이 가장 공감되네요.
추상화도가 높은 구조에 대한 회의적인 시선을 담은 글이 최근 종종 올라오네요.
MSA, 클린 코드, SOLID, DRY 등등...
사람들이 저런 단어들에 피로감을 느끼는 게 아닌가 싶습니다.
사실 저것들은 읽기 쉽고, 이해하기 쉽고, 메모리 안 새고, 에러 없이, 빠른 코드를 짜려고 고민할때, 참고할 이정표일 뿐인데...
적당히, 지금 내가 처한 비즈니스 상황에 잘 맞춰 적용하면 되겠지요.
Hacker News 의견
-
DRY 원칙의 초기 적용: 처음부터 DRY 원칙을 적용하는 것이 좋음. 비슷한 데이터를 별도로 처리하는 대신 공통 코드베이스를 사용하는 것이 효율적임.
-
베스트 프랙티스의 우선순위: 모든 베스트 프랙티스가 동일하지 않음. 가독성과 응집성을 우선시하는 것이 중요함. 코드 작성은 최선의 프랙티스를 선택하는 과정임.
-
DRY 원칙의 오해: DRY는 코드 중복이 아닌 정보/지식 중복을 방지하는 것임. 코드 중복에만 집중하면 불필요한 최적화로 이어질 수 있음.
-
재사용성 문제: 특정 기능이 다른 상황에서 재사용되지 않는 경우가 있음. 중복 작업을 피하기 위해 더 나은 접근법이 필요함.
-
복잡한 DRY 솔루션의 문제: 반복 코드가 복잡한 DRY 솔루션보다 나을 때가 있음. 너무 빠르게 DRY를 적용하면 예상치 못한 구조적 문제를 초래할 수 있음.
-
DRY는 베스트 프랙티스가 아님: 반복은 종종 추상화가 필요한 신호임. 무분별한 DRY 적용은 중급 엔지니어들이 자주 저지르는 실수임.
-
간단한 코드 예시: 두 함수가 하나의 함수로 통합될 수 있음. 리팩토링의 장단점을 명확히 설명하는 것이 중요함.
-
DRY 코드의 유지보수 문제: DRY 코드는 복잡해져서 유지보수가 어려워질 수 있음. 반면, WET 코드는 단순하지만 변경이 예측 가능함.
-
DRY 원칙의 부작용: DRY 원칙이 코드베이스를 복잡하게 만들어 유지보수가 어려워질 수 있음. 일부 클린 코드 책들이 산업에 부정적인 영향을 미쳤음.
-
일반화와 성능: 일반화는 성능에 부정적인 영향을 미칠 수 있음. 특정 데이터 패턴에 맞춘 코드 중복이 성능 최적화에 도움이 될 수 있음.