Jak nazywa się antipattern przeciwny „wynalezieniu koła”? [Zamknięte]

Antypattern „ Reinvent the wheel ” jest dość powszechny - zamiast używać gotowego rozwiązania, napisz własne od zera. Baza kodu rośnie niepotrzebnie, nieco inne interfejsy, które robią to samo, ale nieco inaczej obfitują, marnuje się czas na pisanie (i debugowanie!) Funkcji, które są łatwo dostępne. Wszyscy to wiemy.

Ale jest coś na drugim końcu spektrum. Kiedy zamiast pisać własną funkcję, która składa się z dwóch wierszy kodu, importujesz platformę / interfejs API / bibliotekę, tworzysz jej instancję, konfigurujesz, konwertujesz kontekst na typ danych jako akceptowalny przez platformę, a następnie wywołujesz tę pojedynczą funkcję, która robi dokładnie to, czego potrzebujesz, dwie linie logiki biznesowej pod gigabajtem warstw abstrakcji. A potem musisz aktualizować bibliotekę, zarządzać zależnościami kompilacji, synchronizować licencje, a kod jej tworzenia jest dziesięć razy dłuższy i bardziej złożony niż w przypadku „ponownego wynalezienia koła”.

Przyczyny mogą być różne: kierownictwo ściśle przeciwstawiające się „nowemu wynalezieniu koła” bez względu na koszty, ktoś popychający swoją ulubioną technologię pomimo marginalnego nakładania się na wymagania, malejąca rola dawnego głównego modułu systemu lub oczekiwanie rozszerzenia i szerszego użycie frameworka, który po prostu nigdy nie nadchodzi, lub po prostu niezrozumienie „wagi” kilku instrukcji importu / włączenia / załadowania zawiera „za kulisami”.

Czy istnieje wspólna nazwa dla tego rodzaju antypatternu?

_{(Nie próbuję rozpoczynać dyskusji, gdy jest to dobre lub złe, lub jeśli jest to prawdziwe antypattern lub cokolwiek oparte na opiniach , jest to proste, proste i obiektywne pytanie dotyczące nomenklatury.)}

Edycja: sugerowany „duplikat” mówi o nadinstruowaniu własnego kodu, aby był „gotowy na wszystko”, całkowicie poza systemami zewnętrznymi. To może w niektórych przypadkach wynikać z tego, ale generalnie pochodzi od „niechęci do ponownego wynalezienia koła” - ponowne użycie kodu za wszelką cenę; jeśli „gotowe” rozwiązanie naszego problemu istnieje, my będziemy go używać, bez względu na to, jak słabo to pasuje i jakim kosztem chodzi. Dogmatycznie faworyzuje tworzenie nowych zależności niż powielanie kodu, z całkowitym lekceważeniem kosztów integracji i utrzymania tych zależności w porównaniu z kosztami tworzenia i utrzymania nowego kodu.

Nie. Nie ma powszechnie używanej nazwy anty-wzorca obejmującej to, co opisujesz.

Złoty Młot

Złoty młot jest narzędziem wybranym tylko dlatego, że jest fantazyjne. Wykonanie zamierzonego zadania nie jest ani opłacalne, ani wydajne.

źródło: xkcd 801

(Pomimo głosów negatywnych, podtrzymuję tę odpowiedź. To może nie być dokładnie odwrotnością semantycznego ponownego wynalezienia koła, ale pasuje do każdego przykładu wymienionego w pytaniu)

Robert Martin używa terminu „ Framework Round ” w odniesieniu do najbardziej oczywistej negatywnej konsekwencji tego anty-wzoru. Ponieważ nie sądzę, aby istniał jakaś wspólna nazwa dla samego wzorca, odniesienie do tej konsekwencji może wystarczyć do większości celów.

Ta strona Wikipedii na „ Wymyślono tutaj ” opisuje nieco inną sytuację, ale z bardzo podobnymi efektami końcowymi. Opisuje awersję zespołu do tworzenia własnego kodu, gdy można tam znaleźć równoważne funkcje.

Twierdziłbym jednak, że nazwa ta jest nieco myląca. Ma sens, gdy jest umieszczony w kontekście z jego przeciwieństwem Not Invented Here, który IMHO jest właściwie synonimem Reinventing the wheel.

Słyszałem słowa „ Kup kontra buduj ” i „ Wymyślono tutaj ” jako nazwy anty-wzorcowe, mające na celu zapobieganie tworzeniu własnych rozwiązań, nawet jeśli może to mieć sens. (I chociaż wyrażenie „kup kontra buduj” ma wskazywać na wybór między realnymi alternatywami, to zwykle jest wspomniane, gdy ktoś uważa, że ​​„kup” jest właściwym wyborem).

Nie używaj armaty do zabijania komara

Konfucjusz

AKA Overkill

Wzdęcie jest szerokim pojęciem, ale może obejmować to, co opisujesz. Nasze oprogramowanie staje się nadmiernie złożone (rozdęte) z powodu wszystkich dodatkowych wymaganych transformacji i abstrakcji, a zarówno złożoność, jak i same zależności przyczyniają się do niższej wydajności / mniejszej wydajności i wyższego zużycia zasobów (dysku, przepustowości).

Jeśli chcielibyśmy, moglibyśmy wyjaśnić terminem takie jak rozdęte zależności .

Myślę, że użycie młota do roztrzaskania orzecha jest dość zbliżone. Jest to coś, co jest możliwe, ale wymaga nadmiernej ilości pracy, aby złamać w ten sposób jednego orzecha, bez żadnych możliwych niepożądanych efektów ubocznych. (I jest cała torebka orzechów do zgryzienia ...)

Wyrażenie ma również tę zaletę, że nie jest obliczeniem żargonu, więc może być bardzo pomocne w przekazywaniu wskazówek komuś, kto go nie zna.

Nawiasem mówiąc, należy wyróżnić piekło uzależnienia . Jeśli ktoś zawinął już wszystkie zawiłości wewnątrz enkapsulacji, która tworzy proste, jasne i łatwe w użyciu interfejsy, i pod warunkiem, że kara w cyklach procesora lub zużyciu pamięci nie jest nadmierna, i pod warunkiem, że w przyszłości modyfikacja enkapsulowanego kodu nie będzie prawdopodobnie potrzebne, następnie pozostałym argumentem przeciwko jego użyciu jest piekło zależności, które może powodować.

Nie sądzę, że istnieje dokładny analog, ale powiedziałbym, że nadprojektowanie lub nadinżynieria są najbliższe.

Przynajmniej będę argumentować, że to, co się naprawdę dzieje, kiedy napotkały coś podobnego do tego, co można opisać.

Korzystanie z biblioteki zamiast pisania własnego kodu w celu wdrożenia tej samej funkcjonalności prawie nigdy nie jest szkodliwe.

Nawet w twoim hipotetycznym przykładzie użycie biblioteki do zastąpienia „dwóch linii kodu” może nie być konieczne, ale jest mało prawdopodobne, aby wywołało u ciebie wiele smutku - jeśli tak naprawdę jest to biblioteka przeznaczona do robienia tego samego, co twoje dwie linie kodu .

Biblioteka do wykonywania prostych czynności będzie również prosta. Prawdopodobnie nie sprawi Ci bólu głowy, który sugeruje twoje pytanie.

Korzystanie ze skomplikowanej biblioteki w celu zrobienia czegoś prostego prawdopodobnie oznacza, że ​​próbujesz zrobić więcej niż zaimplementować wymaganą funkcjonalność.

Takie jak wbudowane funkcje, które nie są potrzebne, przygotuj się na przyszłość, która może nigdy nie nadejść itp.

Problemem tutaj nie jest to awaria wyważać otwartych drzwi per se .

Jeśli nie wynalazłeś koła na nowo, najprawdopodobniej używa ono istniejącego zestawu kół dostarczonego przez dostawcę lub firmę zewnętrzną.

Jeśli jest to anty-wzorzec, zwykle nazywa się to blokowaniem dostawcy.

Bezpieczeństwo pracy?
Wspominasz o wysiłkach związanych z utrzymywaniem synchronizacji itp. Niektórzy wolą zarządzać kodem innych ludzi niż pisać własny. Zwłaszcza menedżerowie.