"Don't Repeat Yourself"는 내가 소프트웨어 개발 경력 동안 읽었던 가장 가치 있는 책 중 하나에서 가장 가치 있는 아이디어 중 하나입니다. 중복 코드를 리팩터링할 수 있다면 보다 일반적이고 안정적인 코드를 생성할 수 있습니다. 그러나 코드를 DRY-ing하기 시작하면 일부 문제에 부딪히기 시작할 것입니다. 예를 들어, 극단적인 경우를 잘 처리하지 못하는 코드, 너무 일반화되어 읽기 어려운 코드, 찾기 어려운 코드 등입니다. DRYness에 대한 리팩토링이 항상 작동하지 않는 경우 언제 리팩토링해야 하는지 어떻게 알 수 있나요?
Too-DRY 코드는 어떤 종류의 중복을 제거하려고 시도해야 하는지에 대한 오해에서 비롯됩니다. 필수의 차이점을 식별할 수 있어야 합니다. 중복 및 우발적 중복.
필수 복제는 작업 중인 문제 클래스를 해결하는 코드입니다. 바로 죽여야 하는 복제품입니다.
우발적 그러나 복제는 당면한 문제와 관련이 없는 복제인 "우연의 복제"입니다. 우발적 복제를 너무 적극적으로 정리하면 새로운 사례가 추가될 때 리팩토링을 해제해야 하는 더 깨지기 쉬운 코드가 됩니다.
그러나 어떻게 그 차이를 알 수 있습니까? 경험이 있으면 이 작업을 더 잘 할 수 있지만 수십 년의 프로그래밍 후에도 여전히 절반의 시간도 제대로 수행할 수 없습니다. 다행히도 많은 도움이 되는 일반적인 규칙이 있습니다. Three Strikes and You Refactor.
<블록 인용>처음 하는 일을 하면 됩니다.
두 번째로 유사한 작업을 수행하면 복제에 움찔하지만 어쨌든 복제 작업을 수행합니다.
세 번째로 유사한 작업을 수행하면 리팩토링합니다.
이것이 왜 도움이 되는지 알 수 있습니까? 세 번째 시간에는 패턴이 어디에 있는지 보기 시작해야 합니다. 문제를 해결하기 위해 어떤 중복 코드가 필요한지, 어떤 코드가 우연히 같은 모양인지에 대한 아이디어가 있어야 합니다. 기본적으로 있는 코드만 일반화(및 건조)할 수 있습니다. 해결하려는 문제의 모든 인스턴스에서 동일합니다.
잠시 시간을 내어 마지막으로 리팩토링으로 인해 고통을 겪었는지 생각해 보십시오. 문제의 두 사본 사이에 중복된 것을 말리려고 했으나 세 번째 사본은 약간 달랐습니까?
다음에 코드를 복제해야 한다고 생각되면 세 번째 복사본이 나올 때까지 기다렸다가 리팩토링하십시오. (정말 힘들고 끔찍하지만 어쨌든 눈을 감고 시도하십시오). 그런 다음 코드를 건조하면서 그것에 대해 생각하십시오. 두 번째 사본을 작성한 직후에 리팩토링했을 때와 다르게 리팩토링하고 있습니까?