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

101

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

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

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

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

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

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

Научная фантастика
источник
52
Зависимость ада . Это самое близкое, что я могу придумать.
Мачадо
5
@ Мачадо: Хорошо, хотя я бы сказал, что Ад-зависимость является прямым результатом изобилия этого анти-паттерна; в случае чрезвычайно сложных систем это может быть прямым результатом сложности.
SF.
27
Я бы назвал это « крипом зависимости», аналогом Feature_creep или Scope_creep, где в продукт добавляется все больше и больше изначально нежелательных функций.
k3b
21
Фиаско с левой стороны - реальный пример этого синдрома в действии.
SF.
13
Я рекомендую начать коллективно называть это LeftPad.
RubberDuck

Ответы:

9

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

JacquesB
источник
4
Он появляется с количеством идей, предложений и обсуждений, которые он вызвал, это действительно правильно.
SF.
3
Я чувствую себя грязно, делая это.
SF.
А? «Нет ХХХ» - очень сильное утверждение, и его очень трудно доказать, особенно учитывая, что в комментариях упоминается несколько кандидатов.
AnoE
1
@AnoE "Есть ли общее название для такого рода антипаттерна?" Доказательства в указанных комментариях и ответах в значительной степени подразумевают, что нет. Правда, он не отвечает на заголовок, но отвечает на сам вопрос.
Кролтан
@AnoE Вы не можете доказать отрицательный, дорогая. Может быть, этот термин где-то прячется под скалой на Борнео, и мы просто еще не упали? То, что есть 10 ответов вместо 1 с zillion upvotes, является достаточным доказательством для меня.
49

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

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

источник: xkcd 801

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

Мартин
источник
5
Принято голосование, и вы также можете получить его из википедии: en.wikipedia.org/wiki/Anti-pattern , en.wikipedia.org/wiki/Law_of_the_instrument
Pierre.Sassoulas
3
Я бы понизил это, если бы у меня был представитель. Он не отвечает на вопрос в целом, но предлагает один (точный) термин, который отвечает только на один из предложенных сценариев.
Дэвид
3
Об обратном спросили. Это все равно что настаивать на том, что «Беккерель» (радиация, единица измерения s ^ -1) может использоваться для музыки вместо Герц (Гц, единица измерения s ^ -1), потому что они оба означают «в секунду».
Торбьерн Равн Андерсен
@ ThorbjørnRavnAndersen Я слышал довольно опасную музыку в свое время.
34

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

Жюль
источник
1
Фреймворки существуют для ускорения процесса разработки. Они как ракета-носитель: расходуются сразу после использования. Решение - выпуск первой версии, где мы были? Это верно, разработка программного обеспечения. Следующий! Техническое обслуживание - это отдельная проблема, и я думаю, что в наши дни это не важно. Перенесите следующий фреймворк к следующему решению.
18

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

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

Newtopian
источник
13

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

wberry
источник
9

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

Конфуций

AKA Overkill

Руфус
источник
5
Распространенная (в Великобритании) английская фраза «использовать кувалду, чтобы расколоть орех».
nigel222
также: «охота на оленя с танком»
Jeutnarg
«Мухи с молотком
Не используйте молоток, чтобы убить муху
jeffmcneill
8

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

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

jpmc26
источник
5

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

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

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

nigel222
источник
5

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

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

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

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

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

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

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

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


источник
4

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

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

Джон Рейнор
источник
6
Я действительно не чувствую, что это то же самое. Привязка к поставщику является одним конкретным отрицательным результатом зависимости от решения поставщика, независимо от того, было ли использование поставщика экономически эффективным, когда был сделан выбор. ОП больше интересуется термином для выбора стороннего решения, когда стоимость интеграции выше, чем стоимость простой разработки нового решения с нуля (и, вероятно, блокировка поставщика даже не происходит, в тех случаях, когда быть дешевым в разработке нового решения вместо того, чтобы полагаться на поставщика).
Бен
@Ben - Ладно, мне больше нравится привязка Framework, а не блокировка вендора. Этот вопрос основан на мнении, и это было первое, что пришло мне в голову.
Джон Рейнор
0

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


источник