Як називається антипатерн, протилежний "винахід колесу"? [зачинено]

Антипатерн " Нагадуй колесо " досить поширений - замість того, щоб використовувати готове рішення, пишіть своє з нуля. База коду зростає непотрібно, трохи різні інтерфейси, які роблять те саме, але трохи інакше рясніють, витрачається час на написання (і налагодження!) Функцій, які легко доступні. Ми всі це знаємо.

Але є щось на протилежному кінці спектра. Коли замість того, щоб записати власну функцію, яка складається з двох рядків коду, ви імпортуєте рамку / API / бібліотеку, інстанціюєте її, налаштовуєте, конвертуєте контекст у тип даних як прийнятний рамкою, а потім викликаєте одну єдину функцію, яка робить саме те, що вам потрібно, два рядки ділової логіки під гігабайт шарів абстракції. І тоді вам потрібно буде постійно оновлювати бібліотеку, керувати побудови залежностей, синхронізувати ліцензії, і ваш код цього примірника в десять разів довший і складніший, ніж якби ви просто «винаходили колесо».

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

Чи є загальна назва цього типу антипатернів?

_{(Я не намагаюся розпочати дискусію, коли це правильно чи неправильно, або якщо це справжня антипатрія чи що-небудь, на основі думки , це просте просте і об'єктивне номенклатурне питання.)}

Редагувати: запропонований "дублікат" говорить про переобладнання власного коду, щоб зробити його "готовим до всього", повністю крім зовнішніх систем. Ця річ може в деяких випадках випливати з неї, але загалом вона походить від "відрази до винахідництва колеса" - повторне використання коду за будь-яку ціну; якщо "готове" рішення нашої проблеми існує, ми будемо використовувати її, незалежно від того, наскільки вона погано підходить і за яку ціну вона надійде . Догматично виступає за створення нових залежностей від дублювання коду, з повним ігноруванням витрат на інтеграцію та підтримку цих залежностей порівняно з витратами на створення та обслуговування нового коду.

Ні. Немає загальновживаної назви анти візерунка, яка б охоплювала те, що ви описуєте.

Золотий молоток

Золотий молоток - це інструмент, обраний лише тому, що він фантазійний. Він не є ні економічно вигідним, ні ефективним у виконанні наміченого завдання.

джерело: xkcd 801

(Незважаючи на голосування "за", я стою проти цієї відповіді. Це може бути не протилежною повторному винайденню колеса семантично, але це відповідає кожному прикладу, згаданому в питанні)

Роберт Мартін використовує термін " Рамковий зв'язаний " для позначення найбільш очевидних негативних наслідків цього антидіаграму. Оскільки я не думаю, що існує загальна назва самого шаблону, посилання на цей наслідок може бути достатньою для більшості цілей.

На цій сторінці вікіпедії на " Винайденому тут " описана дещо інша ситуація, але з дуже схожими кінцевими результатами. Описується неприязнь команди до створення власного коду, коли там можна знайти еквівалентну функціональність.

Я б стверджував, що це ім'я трохи вводить в оману. Створює сенс, коли його ставлять у контекст із протилежним Not Invented Here, що IMHO є синонімом переосмислення колеса.

Я чув " Купити Versus Build " та " Invented Here " як назви анти-шаблонів для упередження щодо розвитку речей у себе, навіть коли це може мати сенс робити. (І хоча словосполучення "купувати проти будівництва" повинно вказувати на вибір між життєздатними альтернативами, я вважаю, що це зазвичай згадується тоді, коли хтось вважає, що "купити" - це правильний вибір.)

Не використовуйте гармати для вбивства комара

Конфуцій

AKA Overkill

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

Якщо ми хочемо, ми могли б уточнити таким терміном, як роздуті залежності .

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

Перевага також має перевагу в тому, що це не обчислення жаргону, тому може бути дуже корисним у наданні поняття тому, у кого його немає.

До речі, існує відмінність, яку слід намалювати в пеклі залежності . Якщо хтось уже завернув усі складності всередині інкапсуляції, яка створює прості, зрозумілі, прості у користуванні інтерфейси та за умови, що штраф в циклах процесора або використання пам'яті не є надмірним, і за умови подальшої модифікації інкапсульованого коду навряд чи буде необхідний, то залишився аргумент проти його використання - це пекло залежності, яке воно може спричинити.

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

Принаймні, я б заперечував, що саме це насправді відбувалося, коли я стикався з чимось подібним до того, що ви описуєте.

Використання бібліотеки замість написання власного коду для реалізації тієї ж функціональності майже ніколи не шкідливо.

Навіть у вашому гіпотетичному прикладі використання бібліотеки для заміни "двох рядків коду" може не знадобитися, але це навряд чи спричинить вам багато горя - якщо це дійсно бібліотека, призначена зробити те саме, що і два ваші рядки коду .

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

Використання складної бібліотеки для того, щоб зробити щось просте, ймовірно, означає, що ви намагаєтеся зробити більше, ніж реалізувати необхідну функціональність.

Такі, як побудувати функції, які не потрібні, підготуватися до майбутнього, яке може ніколи не настати тощо.

Проблема тут насправді не в тому, щоб винаходити колесо як таке .

Якщо ви ще не придумали колесо, швидше за все, використовуєте наявний набір коліс, наданий постачальником або третьою стороною.

Якщо це анти-шаблон, то його зазвичай називають блокуванням постачальників.

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