“바퀴 재개발”과 반대되는 반 패턴의 이름은 무엇입니까? [닫은]

" 바퀴를 재창조 "하는 반 패턴은 매우 일반적인 것입니다. 준비된 솔루션을 사용하는 대신 처음부터 직접 작성하십시오. 코드베이스는 불필요하게 성장하지만 약간 다른 인터페이스는 동일하지만 약간 다른 방식으로 커지 므로 쉽게 사용할 수있는 함수를 작성 (및 디버그!)하는 데 시간이 낭비됩니다. 우리는 모두 이것을 알고 있습니다.

그러나 스펙트럼의 반대쪽 끝에 무언가가 있습니다. 두 줄의 코드 인 자체 함수를 작성하는 대신 프레임 워크 / API / 라이브러리를 가져 와서 인스턴스화하고, 구성하고, 프레임 워크에서 허용하는대로 컨텍스트를 데이터 유형으로 변환 한 다음, 필요한 것을 정확히 수행하는 단일 함수를 호출하십시오. 기가 바이트의 추상화 계층에서 두 줄의 비즈니스 로직. 그런 다음 라이브러리를 최신 상태로 유지하고, 빌드 종속성을 관리하고, 라이센스를 동기화 상태로 유지해야하며, 인스턴스화 코드는 "바퀴를 재발 명"하는 것보다 10 배 길고 복잡합니다.

그 이유는 다양 할 수 있습니다. 비용과 상관없이 경영진은 "바퀴의 재창조"를 엄격히 반대하고, 요구 사항과의 겹치는 부분에도 불구하고 선호하는 기술을 추진하는 사람, 이전에 주요 시스템 모듈의 감소 역할, 확장 및 더 넓은 기대 도착하지 않은 프레임 워크를 사용하거나, 몇 가지 가져 오기 / 포함 /로드 명령이 "비하인드"를 수행하는 "무게"를 오해합니다.

이런 종류의 반 패턴에 대한 일반적인 이름이 있습니까?

_{(나는 그것이 옳고 그름 일 때 토론을 시작하려고하지 않거나 그것이 실제 반 패턴이나 의견에 근거한 것이라면 이것은 간단하고 객관적인 명명법 질문입니다.)}

편집 : 제안 된 "중복"은 외부 시스템과 완전히 분리되어 "모든 것을 준비"할 수 있도록 자체 코드를 오버 엔지니어링하는 것에 대해 이야기합니다. 어떤 경우에는이 문제가 생길 수 있지만 일반적으로 "바퀴 재개발에 대한 혐오"에서 비롯됩니다. 코드 재사용은 모든 비용으로 발생합니다. 우리의 문제에 대한 "준비된"솔루션이 존재한다면, 우리 는 그것이 얼마나 잘 맞지 않고 어떤 비용이들든지 상관없이 그것을 사용할 것입니다. 새로운 코드의 생성 및 유지 비용과 비교할 때 이러한 종속성의 통합 및 유지 관리 비용을 완전히 무시하면서 코드 복제에 비해 새로운 종속성 생성을 독단적으로 선호합니다.

아니요. 일반적으로 사용하는 안티 패턴 이름은 설명하고 있지 않습니다.

황금 망치

황금 망치는 화려하기 때문에 선택된 도구입니다. 의도 한 작업을 수행하는 데 비용 효율적이거나 효율적이지 않습니다.

출처 : xkcd 801

(다운 투표에도 불구하고, 나는이 답변을지지합니다. 그것은 바퀴를 의미 론적으로 다시 발명하는 것과 정반대가 아닐 수도 있지만, 질문에 언급 된 모든 예에 적합합니다)

Robert Martin 은이 반 패턴의 가장 명백한 부정적인 결과를 나타 내기 위해 " 프레임 워크 경계 " 라는 용어를 사용합니다 . 패턴 자체의 공통 이름이 없다고 생각하기 때문에이 결과에 대한 참조는 대부분의 목적으로 충분할 수 있습니다.

" Invented Here " 의이 wikipedia 페이지 는 약간 다른 상황이지만 매우 유사한 최종 결과를 보여줍니다. 동등한 기능을 찾을 수있을 때 자신의 코드를 작성하려는 팀의 혐오감을 설명합니다.

그래도 그 이름은 약간 오해의 소지가 있다고 주장합니다. 반대의 상황에서 문맥에 놓았을 때 감각을 느끼게합니다. 여기서 발명되지 않은 IMHO는 바퀴를 재발 명하는 것과 동의어입니다.

" 구매 대 구축 "과 " 발명 "을 사내 개발에 대한 편견의 반 패턴 이름으로 들었습니다 . (그리고 "구매 대 구축"이라는 구절이 실행 가능한 대안 중 하나를 선택한다고 가정하지만, 누군가 "구매"가 올바른 선택이라고 생각할 때 일반적으로 언급 됩니다.)

모기를 죽이는 대포를 사용하지 마십시오

공자

일명 오버 킬

블로 트는 광범위한 용어이지만 설명하는 내용을 포함 할 수 있습니다. 우리의 소프트웨어는 필요한 모든 추가 변환 및 추상화로 인해 지나치게 복잡해집니다. 복잡성과 종속성 자체는 성능 / 효율이 떨어지고 리소스 소비 (디스크, 대역폭)를 낮추는 데 기여합니다.

원하는 경우 부풀어 오른 종속성 과 같은 용어로 명확히 할 수 있습니다.

나는 망치를 사용하여 너트를 깨는 것이 꽤 가깝다고 생각합니다. 그것은 가능한 일이지만, 여러 가지 원치 않는 부작용이 발생하지 않으면 서 하나의 너트를 균열시키는 데 엄청난 양의 작업이 필요합니다. (그리고 갈라질 견과류가 가득합니다 ...)

또한이 용어는 전문 용어를 계산하지 않는다는 이점이 있으므로,없는 사람에게 단서를 제공하는 데 매우 도움이 될 수 있습니다.

그건 그렇고, 의존성 지옥 으로 그려야 할 차이점이 있습니다 . 누군가가 캡슐화 내부의 모든 복잡성을 이미 랩핑하여 단순하고 명확하며 사용하기 쉬운 인터페이스를 생성하고 CPU 사이클 또는 메모리 사용량이 과도하지 않은 경우 캡슐화 된 코드의 향후 수정이 불가능한 경우 필요한 경우, 사용에 대한 나머지 주장은 원인이 될 수있는 의존성 지옥입니다.

나는 정확한 아날로그가 없다고 생각하지만, 과도한 디자인이나 과잉 엔지니어링이 가장 가깝다고 말할 것 입니다.

적어도, 나는 이것이 당신이 묘사 한 것과 비슷한 것을 만났을 때 실제로 진행되고 있다고 주장합니다 .

동일한 기능 을 구현하기 위해 자체 코드를 작성하는 대신 라이브러리를 사용하는 것은 거의 해롭지 않습니다.

가상의 예에서도 "두 줄의 코드"를 대체하기 위해 라이브러리를 사용할 필요는 없지만, 실제로 두 줄의 코드와 같은 일을하려는 라이브러리라면 큰 슬픔을 유발하지는 않습니다. .

간단한 일을하는 라이브러리도 간단합니다. 귀하의 질문이 암시하는 두통을 줄 가능성은 없습니다.

복잡한 라이브러리를 사용하여 간단한 작업을 수행하는 것은 필요한 기능을 구현하는 것 이상을 수행하려는 것을 의미합니다.

필요하지 않은 기능을 구축하고, 앞으로 올 수없는 미래를 준비하십시오.

여기서 문제는 실제로 휠 자체 를 재창조하는 데 실패한 것이 아닙니다 .

휠을 다시 발명하지 않은 경우 공급 업체 또는 타사에서 제공 한 기존 휠 세트를 사용하고있을 가능성이 큽니다.

이것이 안티 패턴 인 경우, 일반적으로 벤더 잠금이라고합니다.

고용 안정?
동기화를 유지하려는 모든 노력을 언급합니다. 일부 사람들은 자신의 코드를 작성하는 것보다 다른 사람들의 코드를 관리하려고합니다. 특히 관리자.