3의 규칙에서 세 번째까지 기다릴 이유가 있습니까?

Wikipedia에서 " Rule of Three "라는 기사 를 보았습니다.

3의 규칙은 복제 된 코드 조각이 새로운 프로 시저로 대체되어야하는시기를 결정하기위한 코드 리팩토링 경험 법칙입니다. 코드를 한 번 복사 할 수 있지만 동일한 코드를 세 번 사용하면 새 프로 시저로 추출되어야합니다. 이 규칙은 Martin Fowler가 리팩토링에 도입했으며 Don Roberts에 귀속되었습니다.

나는 이것이 단지 경험의 법칙이라는 것을 알고 있지만 왜 두 번째 복제 후에 만 리팩토링하는 것이 권장됩니까? 첫 복제를 작성할 때 리팩토링에 단점이 있습니까?

refactoring dry rule-of-three

— 루이스리스
소스

다른 관점 세트에 대해서는 불가능한 숫자 및 0- 무한도 규칙 이 2를 참조하십시오 .

— AakashM

소프트웨어 개발에 관해 이야기 할 때, 원래 Wiki는 종종 Wikipedia보다 훨씬 좋은 소스입니다. 결국 Ward Cunningham 은 소프트웨어 개발에 관해 이야기하기위한 수단으로 Wiki를 발명했습니다 . 참조 C2.Com/cgi/wiki?RuleOfThree

— 요 르그 W MITTAG

재사용을위한 두 가지 시나리오가있는 경우 로직을 쉽게 분기 할 수 있습니다 (있는 경우). 3 개의 가능한 경로에 도달하면 복제 및 유지 관리하는 것보다 리팩토링하기가 쉬워집니다.

— 앤드류 루이스

코드 재사용 비용 대비 비용 절감을위한 경험 법칙

— gnat

실제로 리팩토링하고 일반화 할 수있는 복사 붙여 넣기에 대한 편리한 변명이라고 생각합니다. 세 번째 사례를 받으면 더 일반화 할 수 있습니다.

— Alexey

이 경험 법칙은 코드를 처음 또는 처음 복제 할 때 "If if ..."를 연주하기가 쉽기 때문에 존재한다고 생각합니다. 사람들이 나중에 필요할 수있는 기능 설계를 시작했기 때문에 일부 경우 심각한 분석 마비가 발생했습니다. 그러나 당면한 문제에 대해서는 필요하지 않습니다.

미래의 리팩토링에 코드를 유지하면서 필요한 것만 디자인 / 작성하는 기술이 있습니다.

— EdH
소스

그건 좋은 지적이야. 내 경험상 세 번째 사본을 사용하면 두 개보다 공통점과 차이점이 조금 더 선명 해집니다.

— Daniel B