Как называется антипаттерн напротив «изобретать велосипед»? [закрыто]

Антипаттерн « Изобретай колесо » довольно распространен - ​​вместо использования готового решения напишите свое собственное с нуля. Кодовая база растет без необходимости, немного других интерфейсов, которые делают то же самое, но немного по- разному, тратится время на написание (и отладку!) Функций, которые легко доступны. Мы все это знаем.

Но есть что-то на противоположном конце спектра. Когда вместо написания своей собственной функции, состоящей из двух строк кода, вы импортируете инфраструктуру / API / библиотеку, создаете ее экземпляр, конфигурируете, конвертируете контекст в тип данных, приемлемый для инфраструктуры, а затем вызываете эту единственную функцию, которая выполняет именно то, что вам нужно, две линии бизнес-логики под гигабайтом уровней абстракции. И затем вам нужно поддерживать библиотеку в актуальном состоянии, управлять зависимостями сборки, синхронизировать лицензии, и ваш код реализации этого будет в десять раз длиннее и сложнее, чем если бы вы просто «заново изобрели колесо».

Причины могут быть разными: руководство, строго противостоящее «переосмыслению колеса», независимо от стоимости, кто-то продвигает предпочитаемую ими технологию, несмотря на незначительное совпадение с требованиями, сокращающуюся роль бывшего основного модуля системы или ожидание расширения и расширения. использование фреймворка, который никогда не приходит, или просто неправильное понимание "веса", которое пара инструкций импорта / включения / загрузки несет "за кулисами".

Есть ли общее название для такого рода антипаттернов?

_{(Я не пытаюсь начать обсуждение, когда это правильно или неправильно, или если это настоящий антипаттерн или что-то основанное на мнениях , это простой и объективный вопрос номенклатуры.)}

Редактировать: предлагаемый «дубликат» говорит о том, что нужно перерабатывать собственный код, чтобы он был «готов ко всему», совершенно отдельно от внешних систем. Эта вещь может в некоторых случаях происходить из нее, но обычно она происходит от «отвращения к изобретению колеса» - повторного использования кода любой ценой; если существует «готовое» решение нашей проблемы, мы будем его использовать, независимо от того, насколько плохо оно подходит и какой ценой оно будет. Догматически одобряет создание новых зависимостей по сравнению с дублированием кода, с полным игнорированием затрат на интеграцию и обслуживание этих зависимостей по сравнению со стоимостью создания и обслуживания нового кода.

Нет. Обычно не используется имя анти-паттерна, которое охватывает то, что вы описываете.

Золотой Молот

Золотой молоток - это инструмент, выбранный только потому, что он причудливый. Это не рентабельно и не эффективно при выполнении поставленной задачи.

источник: xkcd 801

(Несмотря на отрицательные голоса, я поддерживаю этот ответ. Возможно, это не совсем противоположно семантическому переизобретению колеса, но оно подходит для каждого примера, упомянутого в вопросе)

Роберт Мартин использует термин « рамки привязки » для обозначения наиболее очевидных негативных последствий этого анти-паттерна. Поскольку я не думаю, что существует какое-то общее название для самого шаблона, для этого может быть достаточно ссылки на это следствие.

На этой странице википедии « Придумано здесь » описывается несколько иная ситуация, но с очень похожими конечными результатами. Описывает отвращение команды к созданию собственного кода, когда там можно найти эквивалентную функциональность.

Я бы сказал, что название немного вводит в заблуждение. Имеет смысл в контексте с противоположностью « Не изобретено», которое, по моему мнению, является синонимом «Изобретать колесо».

Я слышал « Buy Versus Build » и « Invented Here » как имена против паттернов для предвзятого отношения к разработке внутри компании, даже когда это может иметь смысл. (И хотя фраза «купить против сборки» должна указывать на выбор между жизнеспособными альтернативами, я нахожу, что это обычно упоминается, когда кто-то считает, что «покупка» является правильным выбором).

Не используйте пушку, чтобы убить комара

Конфуций

AKA Overkill

Раздувание это широкий термин, но он может включать в себя то, что вы описываете. Наше программное обеспечение становится слишком сложным (раздутым) из-за всех необходимых дополнительных преобразований и абстракций, а сложность и зависимости сами по себе способствуют снижению производительности / снижению эффективности и увеличению потребления ресурсов (диск, пропускная способность).

Если мы хотим, мы могли бы уточнить с таким термином, как раздутые зависимости .

Я думаю, что использование кувалды, чтобы сломать орех довольно близко. Это то, что возможно, но для того, чтобы сломать одну гайку таким способом, требуется чрезмерное количество работы, без каких-либо многочисленных нежелательных побочных эффектов. (И есть целый мешок орехов, чтобы взломать ...)

Фраза также имеет преимущество в том, что она не вычисляет жаргон, поэтому она может быть очень полезна, когда вы даете подсказку тому, у кого ее нет.

Кстати, есть различие, которое нужно провести с адом зависимости . Если кто-то уже обернул все сложности в инкапсуляцию, которая создает простые, понятные и простые в использовании интерфейсы, и при условии, что штраф за циклы ЦП или использование памяти не является чрезмерным, и при условии, что будущая модификация инкапсулированного кода вряд ли будет необходимо, а остальным аргументом против его использования является ад зависимости, который он может вызывать.

Я не думаю, что есть точный аналог, но я бы сказал, что чрезмерный дизайн или чрезмерный инженерный подход ближе всего.

По крайней мере, я бы сказал, что это действительно происходило, когда я столкнулся с чем-то похожим на то, что вы описываете.

Использование библиотеки вместо написания собственного кода для реализации той же функциональности почти никогда не вредно.

Даже в вашем гипотетическом примере использование библиотеки для замены «двух строк кода» может быть необязательным, но вряд ли это доставит вам много горя - если это действительно библиотека, предназначенная для того же действия, что и две строки кода ,

Библиотека для выполнения простых вещей также будет простой. Это вряд ли даст вам головную боль, которую подразумевает ваш вопрос.

Использование сложной библиотеки для выполнения чего-то простого, вероятно, подразумевает, что вы пытаетесь сделать больше, чем просто реализовать необходимую функциональность.

Такие как встроенные функции, которые не нужны, подготовка к будущему, которое может никогда не наступить, и т. Д.

Проблема здесь не в том, чтобы изобрести колесо как таковое .

Если вы не изобрели колесо заново, скорее всего, вы используете существующий набор колес, предоставленный продавцом или третьей стороной.

Если это анти-шаблон, то он обычно называется блокировкой поставщика.

Безопасность работы?
Вы упоминаете все усилия по обеспечению синхронизации и т. Д. Некоторые люди предпочитают управлять кодом других людей, а не писать свой собственный. Менеджеры, особенно.