Czy wynalezienie koła naprawdę tak źle?

Jego powszechna wiedza w programowaniu, które wymyśla na nowo koło, jest złe lub złe .

Ale dlaczego tak jest?

Nie sugeruję, że to dobrze. Uważam, że to źle. Jednak kiedyś przeczytałem artykuł, w którym napisano, że jeśli ktoś robi coś złego (mądre programowanie), wyjaśnij mu, dlaczego to źle, jeśli nie możesz, to może powinieneś zadać sobie pytanie, czy to naprawdę źle.

To prowadzi mnie do pytania:

Jeśli widzę, że ktoś wyraźnie wymyśla koło, budując własną metodę czegoś, co jest już wbudowane w język / framework. Po pierwsze, dla samej argumentacji, załóżmy, że ich metoda jest tak samo wydajna jak metoda wbudowana. Również programista, świadomy wbudowanej metody, woli własną metodę.

Dlaczego miałby używać wbudowanego w swoim własnym?

Jak już pisałem na StackOverflow, odkrycie koła jest często bardzo dobrym wyborem , wbrew powszechnemu przekonaniu. Główną zaletą jest to, że masz pełną kontrolę nad oprogramowaniem, co często jest niezbędne. Aby uzyskać pełną dyskusję, zobacz mój oryginalny post .

Zależy..

Jak w przypadku wszystkiego, chodzi o kontekst:

Dobrze, gdy:

• Struktura lub biblioteka jest zbyt ciężka i potrzebujesz tylko ograniczonej funkcjonalności. Lepszym rozwiązaniem jest stworzenie własnej, wyjątkowo lekkiej wersji, która spełni Twoje wymagania.
• Kiedy chcesz zrozumieć i nauczyć się czegoś złożonego, rozwijanie własnego ma sens.
• Masz coś innego do zaoferowania, czego nie mają implementacje innych. Może być nowy zwrot akcji, nowa funkcja itp.

Jest źle, gdy:

• Funkcjonalność już istnieje i wiadomo, że jest stabilna i dobrze znana (popularna).
• Twoja wersja nie dodaje nic nowego.
• Twoja wersja wprowadza błędy lub ograniczenia (np. Twoja wersja nie jest bezpieczna dla wątków).
• W Twojej wersji brakuje funkcji.
• Twoja wersja ma gorszą dokumentację.
• W twojej wersji brakuje testów jednostkowych w porównaniu do tego, co zastępuje.

Myślę, że przypadek dewelopera świadomie wymyślającego na nowo koło „ponieważ woli swoją własną metodę” jest dość rzadki. Przeważnie dzieje się tak z niewiedzy, a czasem z uporu.

Czy to wszystko takie złe? Tak. Dlaczego? Ponieważ istniejące koło zostało najprawdopodobniej wykonane z biegiem czasu i zostało już przetestowane w wielu okolicznościach i pod kątem wielu różnych rodzajów danych. Deweloperzy istniejącego koła napotkali już przypadki skrajne i trudności, których nowy wynalazca nawet sobie nie wyobraża.

Kwadratowe koła muszą zostać wynalezione na nowo. Wysiłki, które są do bani, muszą być powielone. Może brakuje dokumentacji dla tej metody, a drugi programista uważa, że ​​łatwiej jest po prostu napisać własną, niż próbować ją rozgryźć. Być może sposób wywoływania metody jest niewygodny i nie pasuje do idiomu języka programowania.

Zapytaj go, co to za niedobór.

Ogólnie rzecz biorąc, unikam ponownego wynalezienia koła, jeśli pożądana funkcjonalność lub coś zbliżonego istnieje w standardowej bibliotece używanego przeze mnie języka.

Jeśli jednak muszę włączyć biblioteki stron trzecich, jest to wezwanie do oceny w zależności od tego, jak szeroko używana i ceniona jest biblioteka. Chodzi mi o to, czy mówimy o Boost czy Boba Kick-ass String-Parsing Tools 1.0?

Nawet jeśli biblioteka jest ogólnie znana i ceniona w branży, nadal jest zależna od strony trzeciej . Programiści zasadniczo kładą duży nacisk na zalety ponownego użycia kodu, często jednak rozmyślając nad niebezpieczeństwem zależności. Projekt ze zbyt wieloma zależnościami stron trzecich prawdopodobnie rozpadnie się na dłuższą metę, ponieważ powoli przekształca się w koszmar utrzymania.

Zatem wykorzystanie istniejącego kodu jest dobre - ale zależności są złe . Niestety, te dwa stwierdzenia są ze sobą sprzeczne, więc sztuczka polega na znalezieniu właściwej równowagi. Dlatego musisz zidentyfikować akceptowalne zależności. Jak powiedziałem, wszystko w Bibliotece standardowej języka jest najprawdopodobniej akceptowalną zależnością. Przechodząc stamtąd, biblioteki, które są wysoko cenione w całej branży są także ogólnie do zaakceptowania (jak Boost C ++ lub jQuery dla JavaScript) - ale nadal są mniej pożądane niż biblioteki standardowej, ponieważ nie wydają się być mniej stabilna niż standardowych bibliotek .

Jeśli chodzi o biblioteki, które są stosunkowo nieznane, (np. Najnowsze przesyłanie do SourceForge), są to bardzo ryzykowne zależności, i generalnie zalecałbym unikanie ich w kodzie produkcyjnym, chyba że znasz kod źródłowy, aby samemu je zachować.

Więc to naprawdę wszystko jest równoważeniem. Ale chodzi o to, że po prostu ślepo powiedzą: „Kod ponownie dobrze wykorzystuje! Nowe odkrycie koła źle!” to niebezpieczne podejście. Korzyści wynikające z wykorzystania kodu innej firmy należy porównać z wadami związanymi z wprowadzaniem zależności.

Gdyby ludzie nie wymyślili na nowo kół, świat byłby wypełniony tymi ...

Oto dialog z mojego miejsca pracy:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

Istnieją dwie opcje: albo wymyśl na nowo koło LUB użyj Colorama. Oto, do czego doprowadziłaby każda opcja:

Korzystanie z Colorama

• Może trochę szybciej
• Dodanie zależności strony trzeciej do czegoś trywialnego
• Nadal jesteś tak głupi, jak przed użyciem Coloramy

Nowe podejście do koła

• Rozumiesz, jak niektóre programy mogą wyświetlać kolory
• Dowiesz się, że znaków specjalnych można używać do kolorowania na dowolnym terminalu
• Możesz pokolorować w dowolnym języku programowania, którego będziesz używać w przyszłości
• Twój projekt ma mniejsze szanse na awarię

Jak widać, wszystko zależy od kontekstu. Odkrywanie koła jest czymś, co robię bardzo często, ponieważ chcę być w stanie i myśleć samodzielnie, a nie polegać na innych, którzy myślą za mnie. Jeśli jednak biegniesz w terminie lub to, co próbujesz wdrożyć, jest ogromne i już istnieje, lepiej skorzystaj z tego, co tam jest.

Jednym z użytecznych powodów, aby wymyślić koło na nowo, jest nauka - ale polecam to zrobić w swoim własnym czasie. W miarę pojawiania się większej liczby gotowych rozwiązań i zapewniania większej liczby poziomów abstrakcji, stajemy się o wiele bardziej produktywni. Możemy skupić się na problemie biznesowym, a nie na ogólnych rzeczach, które były wielokrotnie ulepszane. ALE z tego powodu możesz wyostrzyć swoje umiejętności i wiele się nauczyć, próbując samodzielnie wdrożyć rozwiązanie. Po prostu niekoniecznie do użytku produkcyjnego.

Jeszcze jedno - jeśli problemem jest zależność od biblioteki strony trzeciej od firmy, która może zniknąć, upewnij się, że istnieje opcja uzyskania kodu źródłowego lub przynajmniej kilka innych opcji, na których można polegać.

Nawiasem mówiąc, jeśli zdecydujesz się na wdrożenie własnego, unikaj robienia tego w przypadku kryptografii lub innych funkcji związanych z bezpieczeństwem. Dostępne są do tego sprawdzone narzędzia (w pełni przetestowane), aw dzisiejszych czasach zbyt ryzykowne jest tworzenie własnych. To nigdy nie jest tego warte i przerażające jest to, że wciąż słyszę o zespołach, które to robią.

Istnieją dwa rodzaje wydajności - przetwarzanie / szybkość (czyli jak szybko się wykonuje), które mogą się zgadzać i szybkość programowania, której prawie na pewno nie będzie. To pierwszy powód - dla każdego problemu o rozsądnej złożoności, w którym dostępne są istniejące rozwiązania, prawie na pewno szybsze będzie zbadanie i wdrożenie istniejącej biblioteki niż kodowanie własnej .

Drugi powód jest taki, że istniejąca biblioteka (zakładając, że jest dojrzała) została przetestowana i udowodniono, że działa - prawdopodobnie w znacznie szerszym zakresie scenariuszy niż programista i zespół testowy będzie w stanie wprowadzić nowo napisaną procedurę i tak się dzieje zero wysiłku.

Po trzecie, jest o wiele łatwiejsze do obsługi. Nie tylko ktoś go obsługuje i ulepsza (ktokolwiek napisał bibliotekę / komponent), ale znacznie bardziej prawdopodobne jest, że inni programiści się z nim zapoznają i będą w stanie zrozumieć i utrzymać kod do przodu , co minimalizuje ciągłe zmiany koszty

A wszystko to zakłada funkcjonalną równoważność, co zwykle nie jest prawdą. Biblioteki często oferują funkcjonalność, która byłaby dla ciebie przydatna, ale nigdy nie uzasadniałaby wbudowania się w nią, z których wszystkie nagle stały się darmowe.

Istnieją powody, aby rzucić własne - głównie tam, gdzie chcesz zrobić coś, czego wbudowana funkcja nie może zrobić i gdzie można uzyskać prawdziwą przewagę, lub gdy łatwo dostępne opcje nie są dojrzałe - ale są są mniej popularne niż wielu deweloperów byś uwierzył.

Poza tym, dlaczego miałbyś chcieć spędzać czas na rozwiązywaniu problemów, które już zostały rozwiązane? Tak, to świetny sposób na naukę, ale nie powinieneś robić tego kosztem odpowiedniego rozwiązania dla kodu produkcyjnego, o którym, jak zakładam, mówimy.

Oczywiście wynalezienie koła na kaprys, z powodu ignorancji i arogancji może być złą rzeczą, ale IMHO wahadło za bardzo się skręciło. Koło, które robi dokładnie to , co chcesz i nic więcej , ma ogromną zaletę .

Często, gdy patrzę na istniejące koło, albo robi o wiele więcej, niż jest to potrzebne, cierpi na efekt wewnętrznej platformy, a zatem jest niepotrzebnie skomplikowany, lub brakuje mu jakiejś kluczowej cechy, której potrzebuję i którą trudno byłoby wdrożyć na tym, co już tam jest.

Ponadto używanie istniejących kół często powoduje ograniczenia w moim projekcie, których nie chcę. Na przykład:

• Istniejące koło wymaga innego języka i / lub stylu programowania niż wolałbym użyć.
• Istniejące koło działa tylko ze starszą wersją języka (na przykład Python 2 zamiast Python 3).
• Tam gdzie występują kompromisy między wydajnością, elastycznością i prostotą, istniejące koło dokonuje wyborów, które nie są optymalne dla mojego przypadku użycia. (W tych przypadkach odkryłem na nowo nawet funkcjonalność bibliotek, które sam napisałem. Zazwyczaj dzieje się tak dlatego, że napisałem bibliotekową wersję funkcji, aby była ogólna i dość wydajna, kiedy potrzebuję czegoś, co jest bardzo szybkie w mojej specyfice walizka.)
• Istniejące koło ma mnóstwo starszego crufta, który jest zupełnie bezużyteczny w przypadku nowego kodu, ale mimo to utrudnia życie (na przykład używana przeze mnie biblioteka Java, która zmusza mnie do korzystania z jej kiepskich klas kontenerów, ponieważ została napisana przed generycznymi itp.) .
• Sposób, w jaki istniejące koła modelują problem, jest zupełnie inny niż wygodny dla mojego przypadku użycia. (Na przykład może dla mnie wygodnie jest mieć skierowany wykres reprezentowany przez obiekty węzłów i odniesienia, ale istniejące koło korzysta z macierzy przyległości lub odwrotnie. Może wygodnie jest mi ułożyć dane w głównej kolejności kolumn, istniejące koło nalega na wiersz większy lub odwrotnie.)
• Biblioteka dodaje ogromną, kruchą zależność, która byłaby poważnym kłopotem przy uruchamianiu wszędzie tam, gdzie chcę wdrożyć mój kod, gdy wszystko, czego potrzebuję, to niewielki podzbiór jego funkcji. Z drugiej strony, w tym przypadku czasami po prostu wyodrębniam wybraną funkcję do nowej, mniejszej biblioteki lub po prostu kopiuję / wklejam, jeśli biblioteka jest open source, a baza kodów czyni to wystarczająco prostym. (Zrobiłem to nawet ze stosunkowo dużymi bibliotekami, które sam napisałem, nie tylko bibliotekami innych osób).
• Istniejące koło próbuje być pedantycznie zgodne z jakimś standardem, który jest zarówno niewygodny, jak i nieistotny w moim przypadku użycia.

Często używam własnego, ponieważ zbudowałem go, zanim odkryłem wcześniej istniejący, i jestem zbyt leniwy, aby znaleźć i zastąpić każdą instancję. Ponadto w pełni rozumiem własną metodę, chociaż może nie rozumiem wcześniej istniejącej. I wreszcie, ponieważ nie do końca rozumiem wcześniejszy, nie mogę zweryfikować, czy robi absolutnie wszystko, co robi mój obecny.

Jest dużo do kodowania i nie mam dużo czasu, aby wrócić i ponownie kodować coś, chyba że ma to wpływ na produkcję.

W rzeczywistości jedna aplikacja internetowa asp, która jest nadal używana, ma w pełni funkcjonalny wykres, który wyświetla dane w formacie tabelarycznym i umożliwia sortowanie / edycję, jednak nie jest to siatka danych. Został zbudowany kilka lat temu, kiedy uczyłem się asp.net i nie wiedziałem o datagridach. Boję się trochę kodu, ponieważ nie mam pojęcia, co wtedy robiłem, ale działa, jest dokładny, łatwy do modyfikacji, nie ulega awarii, a użytkownicy go uwielbiają

Ponowne wynalezienie koła to świetny sposób, aby dowiedzieć się, jak działa koło, ale nie jest to dobry sposób na zbudowanie samochodu.

Obecnie pracuję dla kilku tanich łyżew.

Kiedy podejmowana jest decyzja „zbuduj lub kup”, zamiast podejmować racjonalną decyzję opartą na ekonomii, menedżerowie zdecydowali się „budować”. Oznacza to, że zamiast płacić kilka tysięcy dolarów za komponent lub narzędzie, spędzamy osobo-miesiące budując własne. Zakup koła od innej firmy kosztuje pieniądze, które wychodzą z budżetu - co wlicza się do złych premii na koniec roku. Czas programistów jest darmowy i dlatego nie wlicza się do premii na koniec roku (z dodatkową korzyścią polegającą na tym, że programiści nie wykonają wszystkiego „na czas”), dlatego wymyślone koło jest kołem wolnym .

W racjonalnej firmie koszt w porównaniu do korzyści związanych z zakupem kół wyprodukowanych przez innych kontra wymyślenie własnych kół opierałby się na krótkoterminowych i długoterminowych kosztach, a także utraconych kosztach alternatywnych, ponieważ nie można tworzyć nowych widżetów wynalezienie kół. Każdy dzień, w którym spędzasz odkrywanie koła, to kolejny dzień, w którym nie możesz napisać czegoś nowego.

Prezentacja na temat kompilacji vs zakupu .
Artykuł na temat kompilacji vs zakupu .

Jeśli widzę, że ktoś wyraźnie wymyśla koło, budując własną metodę czegoś, co jest już wbudowane w język / framework. Po pierwsze, dla samej argumentacji, załóżmy, że ich metoda jest tak samo wydajna jak metoda wbudowana. Również programista, świadomy wbudowanej metody, woli własną metodę.

Dlaczego miałby używać wbudowanego w swoim własnym?

Wbudowana wersja sprawi, że więcej osób będzie się na niej dudniło - w ten sposób znajdując i naprawiając więcej błędów niż Twój domowy kod kiedykolwiek może mieć.

Wreszcie, kiedy twój lokalny programista odejdzie, a ktoś inny będzie musiał zachować kod, który napisał, zostanie on całkowicie przebudowany i zastąpiony tym, co jest w ramach. Wiem, że tak się stanie, ponieważ mój obecny pracodawca ma kod, który przez lata był migrowany do nowszych wersji VB (najstarszy produkt istnieje na rynku od około 20 lat) i tak właśnie się stało. Deweloper z najdłuższym zatrudnieniem w moim biurze jest tutaj od 17 lat.

Rzecz w ponownym wynalezieniu koła polega na tym, że czasami nie ma standardowego, gotowego koła, które zrobi to, czego potrzebujesz. Istnieje wiele dobrych kół, w wielu rozmiarach, kolorach, materiałach i trybach budowy. Ale w niektóre dni musisz po prostu mieć naprawdę lekkie koło, które jest anodowane na zielono aluminium, i nikt go nie produkuje. W takim przypadku musisz stworzyć własny.

Nie oznacza to, że powinieneś tworzyć własne koła do każdego projektu - większość rzeczy może korzystać ze standardowych części i być lepsza. Ale od czasu do czasu okazuje się, że standardowe części po prostu nie działają, więc tworzysz własne.

Najważniejszą rzeczą jest wiedza KIEDY stworzyć własną. Musisz mieć dobre pojęcie o tym, co mogą zrobić standardowe części, a czego nie, zanim zaczniesz projektować własne.

To, czy ponowne wynalezienie koła jest opłacalne, czy nie. Koszty są dość oczywiste ...

• Wymyślenie tego na nowo zajmuje dużo czasu.
• Jeszcze więcej czasu zajmuje udokumentowanie tego, co sam wymyśliłeś.
• Nie możesz zatrudnić ludzi, którzy już rozumieją, co wynalazłeś.
• Zbyt łatwo jest coś na nowo wymyślić, powodując ciągłe koszty problemów spowodowanych złym projektem.
• Nowy kod oznacza nowe błędy. Stary kod zwykle usuwa już większość błędów i może zawierać subtelne obejścia problemów, o których nie wiesz, a zatem nie możesz obejść nowego projektu.

Ostatnia jest ważna - gdzieś jest wpis na blogu ostrzegający o tendencji do „wyrzucania starego kodu i rozpoczynania od zera” na podstawie tego, że wiele starych cruft, których nie rozumiesz, jest w rzeczywistości niezbędnymi poprawkami błędów. Jest opowieść ostrzegawcza o Netscape, IIRC.

Korzyści mogą być ...

• Możliwość dodawania funkcji, których nie mają istniejące biblioteki. Na przykład mam pojemniki, które „utrzymują” swoje wystąpienia iteratora / kursora. Wstawienia i usunięcia nie unieważniają iteratorów. Iterator wskazujący na wektor będzie nadal wskazywał ten sam element (nie ten sam indeks) niezależnie od wstawek i usuwa wcześniej w wektorze. Po prostu nie możesz tego zrobić ze standardowymi kontenerami C ++.
• Bardziej wyspecjalizowany projekt ukierunkowany na twoje szczególne wymagania i szanujący twoje priorytety (ale strzeż się tendencji do efektu wewnętrznej platformy).
• Pełna kontrola - niektóre firmy zewnętrzne nie mogą zdecydować o przeprojektowaniu interfejsu API w sposób, który oznacza, że ​​musisz przepisać połowę aplikacji.
• Pełne zrozumienie - zaprojektowałeś to w ten sposób, więc mam nadzieję, że w pełni rozumiesz, jak i dlaczego to zrobiłeś.
• EDYCJA Możesz wyciągać wnioski z innych bibliotek, nie wpadając w te same pułapki, wybiórczo pod względem ich naśladowania.

Jedno - użycie biblioteki innej firmy może być liczone jako wynalezienie koła. Jeśli masz już swoją starożytną, dobrze używaną, dobrze przetestowaną bibliotekę, zastanów się, zanim ją odrzucisz, zamiast tego użyj biblioteki innej firmy. Na dłuższą metę może to być dobry pomysł - ale zanim tam dotrzesz, może być dużo pracy i wiele nieprzyjemnych niespodzianek (z subtelnych różnic semantycznych między bibliotekami). Rozważmy na przykład efekt przejścia z własnych kontenerów na standardowe biblioteki. Naiwne tłumaczenie kodu wywołującego nie pozwoliłoby na fakt, że standardowe kontenery bibliotek nie utrzymują swoich iteratorów. Przypadki, w których zapisuję iterator na później jako „zakładkę”, nie mogły zostać zaimplementowane przy użyciu prostego tłumaczenia - ja ”

Jeśli istnieje działający komponent, który robi to, czego potrzebujesz, to po co tracić czas na pisanie i debugowanie własnej wersji? Podobnie, jeśli już napisałeś kod w celu spełnienia podobnej funkcji, po co go ponownie pisać?

Joel napisał artykuł o Nie-wymyślonym tutaj, który mówi wiele o tym, kiedy przepisywanie kodu i oprogramowania nie jest i nie jest przydatne.

Ponowne wynalezienie koła może być świetnym sposobem, aby dowiedzieć się, jak coś działa - i zalecam ponowne wymyślenie tylko w tym celu w swoim własnym czasie - ale pisząc aplikację, po co wymyślać, jeśli istnieją dobrze ugruntowane rozwiązania, które już robią to samo?

Na przykład nigdy nie pisałbym kodu JavaScript od zera; zamiast tego zacznę od jQuery i zbuduję aplikacje na tym frameworku.

Moja osobista zasada:

Nowe odkrywanie koła jest dobre, gdy dopiero się uczysz. Jeśli masz termin, możesz użyć istniejących kół.

Bycie „złym” lub nawet „złym” to raczej mocne słowa.

Jak zawsze istnieją powody, dla których warto wybrać implementację osobistą zamiast wbudowanej. W dawnych czasach program C mógł napotykać błędy w bibliotece wykonawczej i dlatego musiał po prostu zapewnić własną implementację.

Nie dotyczy to programów Java, ponieważ JVM jest bardzo ściśle zdefiniowane, ale niektóre algorytmy są nadal bardzo trudne do uzyskania. Na przykład Joshua Bloch opisuje, w jaki sposób zwodniczo prosty algorytm wyszukiwania binarnego w bibliotece wykonawczej Java zawiera błąd, którego ujawnienie zajęło dziewięć lat:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Został znaleziony, naprawiony i rozpowszechniony w przyszłych dystrybucjach Java.

Jeśli korzystasz z wbudowanego wyszukiwania binarnego, właśnie zaoszczędziłeś czas i pieniądze, ponieważ Sun wykonał ciężką pracę w znalezieniu, naprawieniu i rozpowszechnieniu tej poprawki. Możesz wykorzystać ich pracę, mówiąc „potrzebujesz co najmniej aktualizacji Java 6 10”.

Jeśli używasz własnej implementacji - która najprawdopodobniej zawierałaby również ten błąd - najpierw musisz ujawnić błąd. Biorąc pod uwagę, że ten konkretny pojawia się tylko w LARGE zestawach danych, na pewno nastąpi gdzieś w produkcji, co oznacza, że ​​wpłynie to na co najmniej jednego z Twoich klientów i najprawdopodobniej straci prawdziwe pieniądze podczas wyszukiwania, naprawiania i rozpowszechniania poprawki.

Dlatego preferowanie własnej implementacji jest całkowicie słuszne, ale powód powinien być naprawdę dobry, ponieważ musi być droższy niż wykorzystywanie pracy innych.

Niedawno napisałem na blogu swoje przemyślenia na ten temat. Podsumowując:

1. To prawie zawsze zło zbudować własną rękę, zwłaszcza jeśli jest to ów funkcyjne wbudowane w język. Ale jeśli oceniasz niedojrzałe / wątpliwie utrzymane / źle udokumentowane ramy, które znalazłeś w Internecie pod kątem możliwości pisania własnych, może to być oczywiste.

2. Myślę, że wynalezienie koła jest dość okropną analogią do programowego anty-wzoru. Oznacza to, że oryginalnego rozwiązania nigdy nie można ulepszyć. To nonsens. Tak zwane koło może stać się z dnia na dzień przestarzałe lub jego właściciele mogą przestać go utrzymywać. Koło ma inną wartość w każdym systemie, w którym jest używany. Tak więc często jest całkowicie możliwe wynalezienie lepszego koła.

3. Jedną z głównych zalet tworzenia własnego frameworka jest to, że nie będziesz musiał brać odpowiedzialności za błędy innych osób. (To jest filozofia Amazon .) Pomyśl o tym w ten sposób: który z nich lepiej powiedzieć klientowi? -

   „Nasza strona się zepsuła. To była czyjaś wina, a my stworzyliśmy błąd w jej twórcy. Nic nie możemy na to poradzić, tylko czekać. Będziemy cię informować na bieżąco”.

   „Nasza strona się zepsuła i byliśmy w stanie to naprawić natychmiast”.

Może jest tak samo wydajny, ale czy tak solidny? Myślę, że najbardziej przekonującym powodem do korzystania z biblioteki przy rozwijaniu własnej jest to, że framework ma tak wielu ludzi, którzy go używają, że mogą szybko znaleźć i naprawić błędy. Własnie opracowana biblioteka, choć może zapewniać tyle samo (lub więcej) funkcji, nie może konkurować z biblioteką z milionami użytkowników, aby zapewnić testowanie w prawie każdym przypadku użycia. Po prostu nie można pokonać tego rodzaju testów we własnym zakresie.

Cóż, jego własna metoda jest tak skuteczna jak framework, byłaby dość rzadka, ponieważ większość frameworków wciąż ma błędy i żadna framework nie może dać ci rozwiązania od razu po wyjęciu z pudełka. Większość programistów, którzy nie mogą myśleć, nigdy nie spróbują napisać niczego na poziomie frameworka; będą po prostu wyszukiwać w Google gotowe rozwiązanie. Każdy mądry programista najpierw zobaczy, czy istnieje wolna platforma, która ma funkcjonalność, której potrzebuje, a następnie sam napisze rozwiązanie, jeśli nie ma. Czasami jest zbyt trudno wyjaśnić obecną sytuację projektu, a deweloper jest najlepszym sędzią.

Ponowne wynalezienie koła nie jest złe, jest to oświadczenie leniwych ludzi, aby uniknąć ciężkiej pracy. Nawet autorzy frameworków wymyślają na nowo; cała platforma .Net została wymyślona na nowo, aby robić to, co oferowała COM.

Choć dla niektórych może to być obraźliwe, zawsze uważałem ten termin za nieprecyzyjny, gdy używał go jakikolwiek inżynier lub w odniesieniu do tematu tworzenia lub projektowania rzeczy. W rzeczywistości nie mogę powstrzymać się od postrzegania tego jako nieuczciwego, biorąc pod uwagę presję na innowacje w dzisiejszym szybkim świecie. Powtarzanie siebie (lub ignorowanie odpowiednich, wcześniej istniejących rozwiązań) nigdy nie jest mądre, ale tak naprawdę istnieje powód, dla którego nie wszyscy wciąż patrzymy na czarne ekrany pełne zielonych liter.

Rozumiem „Jeśli to nie jest zepsute, nie naprawiaj tego”, ale myślę, że takie zdanie może brzmieć dla niektórych nieświadomie. Jednak przy obecnych wysiłkach zmierzających do ponownego wynalezienia koła na potrzeby podróży kosmicznych, wyścigów, żeglugi itp. „Nie wymyślaj ponownie koła” jest również dość ignoranckie i nie jest tak mądre, jak się wydaje.

Moje doświadczenie polega na prowadzeniu wielu projektów i musiałem współpracować z wieloma stażystami i innymi formami zielonych deweloperów, musiałem też stawić czoła wielu naiwnym pytaniom, które niektórzy nazwaliby „głupimi”, a także musiałem odwodzić ludzi od ścigania królika całości poza zakresem ich zadań. Jednak nigdy nie zniechęcałbym się do innowacji ani kreatywności i widziałem, że wspaniałe rzeczy wynikają z „ponownego wynalezienia koła”.

Moja faktyczna odpowiedź na pytanie: są tylko dwie sytuacje, w których ponowne wynalezienie koła jest czymś złym:

1. Jeśli nie jest to naprawdę potrzebne
2. Jeśli to inny facet robi to, kiedy możesz

Edycja: Widzę po głosowaniu za odrzuceniem, że musiałem trochę urazić. Jedno, co chciałbym dodać, to to, że to zdanie zawsze było moim głównym wkurzeniem. Rozumiem, że moje dwa centy mogą brzmieć raczej trollicznie, ale nie mam zamiaru trollować, powodować pożarów ani obrażać.

Argumenty o „ponownym odkryciu koła” są często używane w niewłaściwym kontekście wyboru biblioteki, ale nie jest to bardzo podobne.

Załóżmy, że oceniam bibliotekę „form-plus”, która niedawno stała się popularna i pomaga radzić sobie z formularzami. Ma ładną stronę docelową, nowoczesną fajną grafikę i otaczającą ją kulturę (ups, mam na myśli społeczność), która przysięga, że ​​sprawia, że ​​tworzenie form jest znów świetne. Ale „form-plus” to abstrakcja na „formach”. „formy” były możliwe, ale kłopotliwe w obsłudze, więc abstrakcja, która ułatwia, staje się popularna.

Ciągle pojawiają się nowe abstrakcje. Trudno je porównać do kół. To bardziej jak nowe urządzenie sterujące i nowa instrukcja dla każdego, już bardzo skomplikowanego, urządzenia, które musisz uruchomić.

Wycena tego nowego urządzenia „form-plus” będzie wyglądać inaczej w zależności od osobistych doświadczeń. Jeśli nigdy wcześniej nie budowałem formularzy, wówczas „form-plus” będzie bardzo przekonujący, ponieważ łatwiej jest zacząć. Minusem jest to, że jeśli „form-plus” okaże się nieszczelną abstrakcją, i tak będę musiał nauczyć się „form”. Jeśli budowałem formularze bez „form-plus”, będę musiał wziąć pod uwagę czas potrzebny na nauczenie się nowego narzędzia. Plusem jest to, że już znam „formy”, więc nie boję się abstrakcji. Krótkoterminowe korzyści często będą większe dla początkujących, ponieważ prawdopodobnie nie byłoby nowej biblioteki, gdyby coś się nie poprawiło. Korzyści długoterminowe będą się znacznie różnić w zależności od jakości abstrakcji, wskaźnika adopcji,

Po dokładnej ocenie korzyści i negatywów wynikających z zastosowania nowej formy „formy plus” w porównaniu z użyciem formy „gołą kość” podejmuję decyzję. Decyzja w dużej mierze opiera się na moich osobistych doświadczeniach, a różni ludzie podejmują inną decyzję. Mógłbym użyć „form” z gołej kości. Może później formy plus zyskały większy ruch i stały się standardem defacto. I może moja własna implementacja z czasem stała się owłosiona i zaczęła dużo opowiadać o tym, co robi teraz formularze plus. Ludzie, którzy przyjadą w tym czasie, zostaną skłaniani do krytykowania tego, że chętnie wymyślam na nowo koło i powinienem był skorzystać z istniejącej biblioteki. Ale możliwe jest również, że w czasie, gdy musiałem podjąć decyzję o „formach plus”, istniało również wiele innych alternatyw dla „formularzy plus”,

Ostatecznie wybór odpowiednich narzędzi jest skomplikowaną decyzją, a „wynalezienie koła” nie jest bardzo pomocną perspektywą.

Napisałem o tym mały artykuł - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

Z mojego doświadczenia wynika, że ​​odkrycie na nowo było naprawdę świetne - choć bardzo długie i żmudne. Powiedziałbym, że jeśli nie znasz dokładnie modeli programowania, których zamierzasz użyć, napisz je sam (jeśli masz czas i energię). To nauczy Cię, co dokładnie oznaczają te modele programowania i ostatecznie staniesz się lepszym programistą. Oczywiście, jeśli pracujesz dla klienta i po prostu potrzebujesz szybko coś zrobić, prawdopodobnie po prostu zechcesz przeprowadzić badania i znaleźć odpowiednie oprogramowanie dla siebie.