it-swarm-eu.dev

Je znovuobjevování kola opravdu tak špatné?

Jeho běžné znalosti v programování, že objevování kola je špatné nebo zlo .

Ale proč?

Netvrdím, že je to dobré. Věřím, že to bylo špatně. Jednou jsem si však přečetl článek, který řekl, že pokud někdo dělá něco špatného (programování moudrého), vysvětlím jim, proč je to špatné, pokud nemůžete, pak byste se měli ptát sami sebe, jestli je to opravdu špatně.

To mě vede k této otázce:

Pokud vidím, někdo jasně objevuje kolo budováním vlastní metody něčeho, co je již zabudováno do jazyka/rámce. Za prvé, kvůli argumentům, můžeme předpokládat, že jejich metoda je stejně účinná jako vestavěná metoda. Také vývojář, který si je vědom zabudované metody, dává přednost vlastní metodě.

Proč by měl použít vestavěný nad svůj vlastní?

104
JD Isaacks

Jak jsem kdysi zveřejnil na StackOverflow, objevování volantu je často velmi dobrá volba, na rozdíl od všeobecného přesvědčení. Hlavní výhodou je, že máte plná kontrola přes software, což je často nezbytné. Pro úplnou diskuzi viz můj původní příspěvek .

73
Dimitri C.

Závisí ..

Stejně jako u všeho, jde o kontext:

Je dobré, když:

  • Framework nebo knihovna je příliš těžká a potřebujete pouze omezenou funkčnost. Lepší přístup spočívá v tom, že budete mít svou vlastní verzi s velmi nízkou hmotností, která vyhovuje vašim požadavkům.
  • Pokud chcete porozumět a naučit se něco složitého, má vaše vlastní smysl smysl.
  • Máte co nabídnout něco jiného, ​​implementace jiných nemají. Může to být nový zvrat, nová funkce atd.

Je to špatné, když:

  • Funkčnost již existuje a je známo, že je stabilní a dobře známý (populární).
  • Vaše verze nepřidává nic nového.
  • Vaše verze zavádí chyby nebo omezení (např. Vaše verze není bezpečná pro podprocesy).
  • Ve vaší verzi chybí funkce.
  • Vaše verze má horší dokumentaci.
  • Ve vaší verzi chybí jednotkové testy ve srovnání s tím, co nahrazuje.
83
Darknight

Myslím, že případ vývojáře, který vědomě znovuobjevuje kolo „protože dává přednost své vlastní metodě“, je docela vzácný. Většinou se to děje z nevědomosti a někdy z tvrdohlavosti.

Je to všechno tak špatné? Ano. Proč? Protože stávající kolo bylo s největší pravděpodobností vytvořeno v průběhu času a bylo již testováno za mnoha okolností a proti mnoha různým druhům dat. Vývojáři stávajícího kola již narazili na Edgeovy případy a potíže, které si vynálezce ještě nedokáže představit.

56
Dan Ray

Čtvercová kola musí být znovuobjevena. Úsilí, které saje, musí být zdvojeno. Možná pro tuto metodu chybí dokumentace a další programátoři se domnívají, že je snazší psát vlastní, než se ji snažit zjistit. Možná způsob, jakým je tato metoda volána, je nepříjemný a nezapadá do idiomu programovacího jazyka.

Jen se ho zeptejte, co je to nedostatek.

22
user8865

Obecně se vyhýbám znovuobjevování kola, pokud funkčnost, kterou chci, nebo něco podobného, ​​existuje ve standardní knihovně jazyka jazyka, který používám.

Pokud však musím začlenit knihovny třetích stran, je to úsudek v závislosti na tom, jak je knihovna široce využívána a vážena. Mluvíme o Boost nebo o Bobově Kick-ass String-Parsing Tools 1.0?

I když je knihovna obecně známá a vysoce uznávaná v celém odvětví, stále je to závislost třetí strany . Programátoři obecně kladou značný důraz na výhody opakovaného použití kódu, přičemž často upozorňují na nebezpečí závislostí. Projekt s příliš velkým počtem závislostí třetích stran se z dlouhodobého hlediska pravděpodobně rozpadne, protože se pomalu přeměňuje v noční můru údržby.

Využití existujícího kódu je tedy dobré - ale závislosti jsou špatné . Bohužel tato dvě tvrzení jsou ve vzájemném rozporu, takže trik se snaží najít správnou rovnováhu. Proto musíte identifikovat přijatelné závislosti. Jak jsem řekl, cokoli ve standardní knihovně jazyka je s největší pravděpodobností přijatelnou závislostí. Odtud odtud jsou obecně akceptovatelné knihovny, které jsou v tomto odvětví vysoce hodnoceny (jako Boost pro C++ nebo jQuery pro Javascript) - ale jsou stále méně žádoucí než Standardní Knihovna, protože nemá tendenci být méně stabilní než standardizované knihovny.

Pokud jde o knihovny, které jsou relativně neznámé (např. Nejnovější nahrání na SourceForge), jedná se o velmi riskantní závislosti, a obecně bych doporučil vyhnout se jim ve výrobním kódu, pokud nejste dostatečně obeznámeni se zdrojovým kódem, abyste je udrželi sami.

Takže je to opravdu vše za vyvažování. Jde ale o to, že slepě říkají: „Opakované použití kódu v pořádku! je nebezpečný postoj. Výhody využití pákového kódu třetí strany musí být zváženy oproti nevýhodám zavádění závislostí.

17
Charles Salvia

Kdyby lidé neobnovili kola, svět by byl naplněn těmito. enter image description here

Zde je dialog z mého pracoviště:

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

Existují dvě možnosti: buď znovuobjevit kolečko OR použít Colorama. Zde by každá možnost měla za následek:

Používám Colorama

  • Možná trochu rychleji
  • Přidání závislosti třetí strany pro něco bezvýznamného
  • Stále používáte hloupost jako před použitím Coloramy

Objevit Ameriku

  • Chápete, jak některé programy dokážou ukázat barvu
  • Dozvíte se, že speciální znaky lze použít k barvení na jakémkoli terminálu
  • Jste schopni obarvit jakýkoli programovací jazyk, který byste mohli v budoucnu použít
  • Je méně pravděpodobné, že se váš projekt rozbije

Jak vidíte, vše je v kontextu. Znovuobjevování kola je něco, co dělám velmi často, protože chci být schopen a myslet na sebe a nespoléhat se na jiné lidi, kteří na mě myslí. Pokud však běžíte do termínu nebo to, co se snažíte implementovat, je obrovské a již existuje, pak je lepší použít to, co je tam.

14
Pithikos

Jedním z užitečných důvodů pro znovuobjevení kola je pro účely učení - ale doporučil bych to udělat ve svůj vlastní čas. Jakmile bude k dispozici více předem připravených řešení a bude zajištěno více úrovní abstrakce, staneme se mnohem produktivnější. Můžeme se zaměřit spíše na obchodní problém než na obecné věci, které byly znovu a znovu vylepšovány. Ale z tohoto důvodu můžete své dovednosti naostřit a naučit se hodně tím, že se pokusíte re-implementovat řešení sami. Pro produkční použití to nemusí být nutně.

Jedna další věc - pokud jde o závislost na knihovně třetích stran od společnosti, která může zmizet, ujistěte se, že existuje možnost získat zdrojový kód, nebo alespoň pár dalších možností, na které se můžete vrátit.

Mimochodem, pokud se rozhodnete implementovat svůj vlastní, vyhněte se tomu pro kryptografii nebo jiné funkce související s bezpečností. K tomu jsou k dispozici zavedené (a plně vyzkoušené) nástroje a v dnešním dni a věku je příliš riskantní, než se s vámi spojit. To nikdy nestojí za to, a je to děsivé, že stále slyším o týmech, které to dělají.

13
Mark Freedman

Existují dva druhy účinnosti - zpracování/rychlost (to je, jak rychle se provádí), které se mohou shodovat, a rychlost vývoje, kterou téměř určitě nebude. To je první důvod - pro jakýkoli problém přiměřené složitosti, kde jsou dostupná stávající řešení, bude téměř jistě rychlejší zkoumat a implementovat existující knihovnu než kódovat vlastní.

Druhým důvodem je to, že existující knihovna (za předpokladu, že je zralá) je testována a je prokázáno, že funguje - pravděpodobně v mnohem širší škále scénářů než vývojář a testovací tým bude moci dát nový písemná rutina a to přichází s nulovým úsilím.

Zatřetí, je to jednodušší podpora. Nejenže někdo jiný jej podporuje a vylepšuje (kdokoli napsal knihovnu/komponentu), ale je mnohem pravděpodobnější, že ostatní vývojáři s ní budou seznámeni a budou schopni porozumět a udržovat kód do budoucna, což minimalizuje průběžné náklady.

A to vše předpokládá funkční ekvivalenci, což obvykle není pravda. Knihovny často nabízejí funkce, které byste považovali za užitečné, ale nikdy nemohli ospravedlnit vestavbu, a to vše je najednou k dispozici zdarma.

Existují důvody k tomu, abyste se mohli sami věnovat - většinou tam, kde chcete udělat něco, co vestavěná funkce nemůže udělat a kde je skutečná výhoda, kterou tím získáte, nebo kde snadno dostupné možnosti nejsou zralé - ale oni jsou méně obyčejní, než byste věřili mnoha vývojářům.

Kromě toho, proč byste chtěli trávit čas řešením problémů, které již byly vyřešeny? Ano, je to skvělý způsob, jak se učit, ale neměli byste to dělat za cenu správného řešení pro výrobní kód, o kterém předpokládám, že mluvíme.

9
Jon Hopkins

Samozřejmě znovuobjevení kola na rozmaru, z nevědomosti a arogancie může být špatná věc, ale IMHO kyvadlo se otočilo příliš daleko. Je tu obrovská výhoda, že máte kolo, které dělá přesně to, co chcete a nic víc.

Často, když se podívám na existující kolo, buď to udělá mnohem víc, než to potřebuji, trpí efekt vnitřní platformy, a je tedy zbytečně složité nebo chybí některá klíčová funkce, kterou dělám potřeby a to by bylo obtížné implementovat nad to, co už existuje.

Navíc používání stávajících kol často zvyšuje můj projekt, který nechci. Například:

  • Stávající kolečko vyžaduje jiný jazyk a/nebo styl programování, než bych jinak raději používal.
  • Stávající kolo funguje pouze se starší verzí jazyka (například Python 2 místo Python 3)).
  • Tam, kde existují kompromisy mezi efektivitou, flexibilitou a jednoduchostí, stávající kolečko dělá volby, které nejsou vhodné pro můj případ použití. (Bylo mi známo, že v těchto případech jsem znovu objevil i funkčnost z knihoven, které jsem původně napsal. Obvykle je to proto, že jsem psal knihovní verzi funkce, aby byla obecná a přiměřeně účinná, když v současné době potřebuji něco, co je v mém konkrétním případě velmi rychlé případ.)
  • Stávající kolo má spoustu starých cruftů, které jsou v případě nového kódu naprosto zbytečné, přesto však život komplikují (například knihovnu Java, kterou používám, která mě nutí, abych použil své mizerné třídy kontejnerů, protože bylo napsáno před generiky atd.).
  • Způsob, jakým stávající modely kol problém je zcela odlišný od toho, co je vhodné pro můj případ použití. (Například, možná je pro mě výhodné mít orientovaný graf reprezentovaný uzlovými objekty a odkazy, ale existující kolo používá sousedící matici nebo obráceně. Možná je pro mě výhodné rozložit data ve sloupci hlavní pořadí, ale existující kolo trvá na řadě major nebo naopak.)
  • Knihovna přidává masivní, křehkou závislost, která by byla velkým problémem, kdy se budu chovat a chovat všude, kam chci implementovat svůj kód, když vše, co potřebuji, je malá podmnožina jeho funkcí. Na druhou stranu v tomto případě občas extrahuji funkci, kterou chci, do nové, menší knihovny nebo pouze zkopíruji/vložte, pokud je knihovna otevřeným zdrojovým kódem a kódová základna je tak dostatečně jednoduchá. (Dokonce jsem to udělal s relativně velkými knihovnami, které jsem napsal sám, nejen s jinými lidmi.)
  • Stávající kolo se pokouší pedanticky vyhovovat nějaké normě, která je pro můj případ použití jak nepohodlná, tak i irelevantní.
9
dsimcha

Často používám svůj vlastní, protože jsem jej postavil dříve, než jsem objevil ten již existující, a jsem příliš líný na to, abych našel a nahradil každou instanci. Také plně chápu svou vlastní metodu, i když možná nerozumím dříve existující. A konečně, protože úplně nerozumím tomu předchozímu, nemohu si ověřit, že dělá absolutně všechno, co dělá můj současný.

Je toho hodně na kód a nemám dost času na to, abych se vrátil a něco znovu kódoval, pokud to neovlivní výrobu.

Ve skutečnosti má jedna asp webová aplikace, která se stále používá, dnes plně funkční graf, který zobrazuje data v tabulkovém formátu a umožňuje třídění/úpravy, nejde však o datovou mřížku. Byl postaven před několika lety, když jsem se poprvé učil asp.net a nevěděl jsem o datových mřížkách. Jsem trochu vystrašený z kódu, protože nemám ponětí, co jsem tehdy dělal, ale funguje to, je přesný, snadno upravitelný, nerozpadá se a uživatelé ho milují

5
Rachel

To, zda znovu vynalézat kolo, je věcí nákladů a přínosů. Náklady jsou zcela zřejmé ...

  • Trvá hodně času, než se znovuobjeví.
  • Dokumentování toho, co jste vynalezli, trvá ještě déle.
  • Nemůžete najmout lidi, kteří již chápou, co jste vynalezli.
  • Je až příliš snadné něco špatně objevovat, což způsobuje pokračující náklady na problémy způsobené špatným designem.
  • Nový kód znamená nové chyby. Starý kód obvykle odstranil většinu chyb a může mít drobná řešení problémů, o nichž si nejste vědomi, a proto se v novém designu nemohou obejít.

Poslední je důležitý - někde je blogový příspěvek, který varuje před tendencí „vyhodit starý kód pryč a začít od nuly“ na základě toho, že mnoho starých křižáků, kterým nerozumíte, jsou ve skutečnosti zásadní opravy chyb. O Netscape, IIRC je varovný příběh.

Výhody mohou být ...

  • Možnost přidat funkce, které stávající knihovny nemají. Mám například kontejnery, které „udržují“ jejich instance iterátoru/kurzoru. Vložení a odstranění nečiní iterátory. Iterátor směřující do vektoru bude i nadále ukazovat na stejnou položku (nikoli na stejný index) bez ohledu na vložení a odstranění dříve ve vektoru. To jednoduše nemůžete udělat se standardními kontejnery C++.
  • Specializovaný design zaměřený na vaše konkrétní požadavky a respektující vaše priority (pozor na tendenci k efektu vnitřní platformy).
  • Úplná kontrola - některá třetí strana se nemůže rozhodnout přepracovat API tak, že budete muset přepsat polovinu aplikace.
  • Úplné porozumění - vytvořili jste to tak, takže doufejme, že plně pochopíte, jak a proč jste to udělali.
  • EDITOVAT Můžete se poučit z jiných knihoven, aniž byste byli chyceni ve stejných pastích tím, že budete selektivní, jak je napodobujete.

Jedna věc - použití knihovny třetích stran může být považováno za znovuobjevení kola. Pokud již vlastníte starou, dobře používanou a dobře otestovanou knihovnu, pečlivě zvažte, než ji zahodíte, abyste místo toho použili knihovnu třetích stran. To může být z dlouhodobého hlediska dobrý nápad - ale může se stát, že před tím, než se tam dostanete, může být velké množství práce a spousta ošklivých překvapení (z jemných sémantických rozdílů mezi knihovnami). Zvažte například účinek přechodu z vlastních kontejnerů na standardní knihovny. Naivní překlad volacího kódu by neumožnil skutečnost, že standardní kontejnery knihovny neudržují své iterátory. Případy, kdy si iterátor uložím na později jako „záložku“, nelze vůbec implementovat pomocí jednoduchého překladu - potřebuji nějaké netriviální alternativní způsoby označování pozic záložek.

4
Steve314

Znovuobjevení kola je skvělý způsob, jak se naučit, jak kolo funguje, ale není to dobrý způsob, jak postavit auto.

4
Dima

V současné době pracuji pro spoustu levných lodí.

Když se rozhoduje mezi „vybudováním nebo koupí“, místo aby se racionálně rozhodovalo na základě ekonomiky, rozhodli se manažeři „stavět“. To znamená, že místo toho, abychom platili několik tisíc dolarů za součást nebo nástroj, utrácíme člověk-měsíce budováním vlastního. Nákup kola od jiné společnosti stojí peníze, které pocházejí z rozpočtu - což se počítá proti špatně spravovaným bonusům na konci roku. Čas programátorů je volný, a proto se nezapočítává do bonusů na konci roku (s další výhodou, že programátoři jsou nuceni všechno udělat „včas“), proto je znovuobjevené kolo volné kolo .

V racionální společnosti by přínosy nákladů a nákladů na nákup kol vyrobených jinými vs revoluce vlastních kol byly založeny na krátkodobých a dlouhodobých nákladech a na ztrátách příležitostných nákladů, protože člověk nemůže vyrábět nové widgety, zatímco jeden je objevování kol. Každý den, který strávíte objevováním kola, je jiný den, že nemůžete psát něco nového.

Prezentace o sestavení vs koupit .
Článek o sestavení versus nákup .

Pokud vidím, že někdo jasně objevuje kolo budováním své vlastní metody něčeho, co je již zabudováno do jazyka/rámce. Za prvé, kvůli argumentům, můžeme předpokládat, že jejich metoda je stejně účinná jako vestavěná metoda. Také vývojář, který si je vědom zabudované metody, dává přednost vlastní metodě.

Proč by měl používat vestavěný nad svůj vlastní

Vestavěná verze bude mít mnohem více lidí bouchání na to - tak najít a opravit více chyb, než váš homebrew kód může kdy mít.

A konečně, když váš místní vývojář odejde a někdo jiný musí udržovat kód, který napsal, bude zcela přepracován a nahrazen tím, co je v rámci. Vím, že se to stane, protože můj současný zaměstnavatel má kód, který byl během let migrován na novější verze VB (nejstarší produkt je na trhu již 20 let)) a to je to, co Vývojář s nejdelším zaměstnáním v mé kanceláři byl tady 17 let.

4
Tangurena

Věc o znovuobjevení kola spočívá v tom, že někdy neexistuje žádný standardní, off-the-shelf kolo, které bude dělat to, co potřebujete. Je tam spousta dobrých kol, v mnoha velikostech, barvách, materiálech a způsobech konstrukce. Ale někdy musíte mít opravdu lehké kolo, které je eloxováno z hliníku, a nikdo ho nevyrábí. V takovém případě musíte vytvořit svůj vlastní.

Nyní to neznamená, že byste si měli pro každý projekt vytvořit vlastní kola - většina věcí může používat standardní díly a být pro ně lepší. Ale občas zjistíte, že standardní díly prostě nefungují, takže si vytvoříte vlastní.

Nejdůležitější věcí je vědět, KDE si vytvořit svůj vlastní. Než začnete navrhovat své vlastní, musíte mít dobrou představu o tom, co mohou standardní díly udělat a co nemohou.

4
Michael Kohne

Být „špatný“ nebo dokonce „zlý“ je poměrně silná slova.

Jako vždy existují důvody pro výběr osobní implementace před vestavěnou. Ve starých časech se program C mohl setkat s chybami v runtime knihovně, a proto jednoduše musí poskytovat svou vlastní implementaci.

To neplatí pro programy Java), protože JVM je velmi přesně definováno, ale některé algoritmy jsou stále velmi obtížné napravit. Například Joshua Bloch popisuje, jak klamně jednoduchý algoritmus binárního vyhledávání v Java runtime knihovna obsahovala chybu, kterou trvalo devět let na povrch:

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

Bylo nalezeno, opraveno a distribuováno v budoucnu Java distribuce).

Pokud používáte vestavěné binární vyhledávání, právě jste ušetřili čas a peníze tím, že společnost Sun udělala těžkou práci při hledání, opravě a distribuci této opravy chyb. Jejich práci můžete využít pouhým vyslovením „potřebujete alespoň Java 6 aktualizace 10“).

Pokud používáte vlastní implementaci - která by tuto chybu pravděpodobně také obsahovala - musíte se nejprve projevit jako chyba. Vzhledem k tomu, že tento konkrétní se zobrazuje pouze na souborech LARGE, je třeba se někde stát ve výrobě, což znamená, že alespoň jeden z vašich zákazníků bude zasažen a pravděpodobně ztratí skutečné peníze, zatímco najdete, opravíte a distribuujete opravu chyb.

Takže je naprosto platné upřednostňovat vaši vlastní implementaci, ale důvod je lepší být opravdu dobrý, protože to musí být dražší než využití práce ostatních.

3
user1249

Pokud existuje funkční komponenta , která dělá to, co potřebujete , tak proč trávit čas psaním a laděním své vlastní verze? Podobně, pokud jste již napsali kód, který plní podobnou funkci dříve, proč jej přepsat?

Joel napsal článek na Not-invented-here, který mluví svazky o tom, kdy přepis kódu a softwaru není a není užitečný.

3
Dave

Znovuobjevení kola může být skvělý způsob, jak se naučit, jak něco funguje - a já doporučuji znovuobjevovat jen za tímto účelem ve svůj vlastní čas - ale když píšete aplikaci, proč objevovat, pokud existují dobře zavedená řešení, která již dělají to samé?

Například bych nikdy nenapsal kód JavaScript od nuly; místo toho bych začal s jQuery a budoval své aplikace na vrcholu toho rámce.

3
Justin Ethier

Moje osobní pravidlo:

Znovuobjevení kola je dobré, když se právě učíte. Pokud máte termín, možná budete chtít použít stávající kola.

3
John

Nedávno jsem blogoval mé myšlenky na toto téma. Shrnout:

  1. Je téměř vždy zlo vybudovat si vlastní, zejména pokud je to funkce, která je zabudována do jazyka. Ale pokud hodnotíte nezralý/pochybně udržovaný/špatně zdokumentovaný rámec, který jste našli na internetu, proti možnosti napsat svůj vlastní, mohlo by to být neomylné.

  2. Myslím, že znovuobjevuje kolo je docela hrozná analogie pro softwarový anti-pattern. To znamená, že původní řešení nelze nikdy vylepšit. To je nesmysl. Takzvané kolo se může stát zastaralou přes noc, nebo jeho majitelé by ho mohli přestat udržovat. Kolo má v každém systému, kde je použito, jinou hodnotu. Takže je často zcela možné vymyslet lepší kolo.

  3. Jednou z hlavních výhod tvorby vlastního rámce je, že nebudete muset převzít odpovědnost za chyby někoho jiného. (Toto je Amazonova filozofie .) Přemýšlejte o tom tímto způsobem: Který z nich je lepší říct zákazníkovi? -

    „Náš web se zlomil. Byla to chyba někoho jiného, ​​a my jsme zaznamenali chybu s jejím tvůrcem. S tím se nedá nic dělat, jen čekat. Budeme vás informovat.“

    "Náš web se zlomil a my jsme to dokázali okamžitě opravit."

3
realworldcoder

Možná je to stejně efektivní, ale je to tak robustní? Myslím, že nejpřesvědčivějším důvodem, proč používat knihovnu, než je vlastní, je, že rámec používá tolik lidí, že mohou rychle najít a opravit chyby. Vnitřní knihovna vyvinutá, i když může poskytovat stejně mnoho (nebo více) funkcí, nemůže konkurovat knihovně s miliony uživatelů, aby provedla testování téměř ve všech případech použití. Prostě nemůžete porazit tento druh testování in-house.

0
Michael K

No, jeho vlastní metoda by byla stejně účinná jako framework by byla docela vzácná, protože většina frameworků stále obsahuje chyby a žádný rámec vám nemůže poskytnout řešení mimo krabici. Většina programátorů, kteří nedokážou myslet, se nikdy nepokusí napsat něco na úrovni rámce; oni prostě hledají Google pro hotové řešení. Jakýkoli moudrý programátor nejprve uvidí, zda existuje volná struktura, která má funkčnost, kterou potřebuje, a pak řešení sám napíše, pokud tam není. Někdy je příliš obtížné vysvětlit současnou situaci projektu a vývojář je nejlepším soudcem.

Znovuobjevení kola není špatné, je to prohlášení od líných lidí, aby se vyhnuli tvrdé práci. Dokonce i autoři rámců se znovu objevují; celý rámec .Net byl znovuobjeven, aby udělal to, co COM nabízí.

0
Akash Kava

Jakkoli to může být pro některé urážlivé, vždy jsem zjistil, že tento pojem je strýcnější, když ho používá jakákoli forma inženýra nebo v souvislosti s tématem vytváření nebo navrhování věcí. Ve skutečnosti nemůžu pomoci, ale považuji to za neobvyklé, když uvažuji o tlacích na inovaci v dnešním rychle se rozvíjejícím světě. Opakování sebe sama (nebo ignorování adekvátních, již existujících řešení) není nikdy moudré, ale ve skutečnosti existuje důvod, proč stále ne všichni zíráme na černé obrazovky plné zelených písmen.

Chápu „Pokud se to nezlomí, neopravujte to“, i když myslím, že taková věta může pro některé znít ignorantsky. Přesto se současným úsilím znovu vynalézat kolo pro potřeby kosmického cestování, závodění, přepravy atd., „Nevynalézat kolo“ je také docela nevědomé a není zdaleka tak chytré, jak to zní.

Mé zázemí spočívá v vedení mnoha projektů a musel jsem spolupracovat s mnoha stážisty a dalšími formami zelených vývojářů a musel jsem řešit mnoho naivních otázek, které by někteří nazvali „hloupí“, a také jsem musel odvrátit lidi od pronásledování králíků celky mimo rozsah jejich úkolů. Nicméně bych nikdy odradil inovaci nebo kreativitu a viděl jsem, jak velké věci pocházejí z „znovuobjevování kola“.

Moje skutečná odpověď na otázku: Existují pouze dvě situace, které způsobují, že opětovné vynalezení kola je špatná věc:

  1. Pokud to opravdu není potřeba
  2. Jestli to dělá ten druhý, když jsi mohl

Úpravy: Vidím, při hlasování o jízdě dolů, že jsem některé urazil. Jednu věc, kterou bych chtěl dodat, je, že tato věta byla vždy velkým mazlíčkem. Chápu, že moje dva centy by mohly znít poněkud trolly, ale nemám v úmyslu troll, způsobit oheň nebo urazit.

0
JSON

Argumenty o „znovuobjevení kola“ se často používají v nesprávném kontextu, kdy se rozhodly používat knihovnu, ale je to jen stěží podobné.

Řekněme, že hodnotím knihovnu „forms-plus“, která se nedávno stala populární a která pomáhá vypořádat se s formuláři. Má pěknou vstupní stránku, moderní skvělou grafiku a kolem ní kulturu (oops, myslím komunitu), která přísahá, jak to zase dělá skvělé formy. Ale „formy plus“ je abstrakce nad „formami“. „formy“ bylo možné, ale těžkopádné se s nimi vypořádat, takže se stává populární abstrakce, která usnadňuje.

Neustále se objevují nová abstrakce. Je těžké je porovnat s koly. Je to spíš jako nové řídicí zařízení a nový návod k jakémukoli již velmi komplikovanému zařízení, které potřebujete spustit.

Hodnocení tohoto nového zařízení „formuláře plus“ bude vypadat jinak v závislosti na osobní zkušenosti. Pokud jsem nikdy nikdy nevytvářel formuláře, pak bude „formulář plus“ velmi přesvědčivé, protože je snazší začít. Nevýhodou je, že pokud se ukáže, že "formy plus" jsou netěsné abstrakce, budu se přesto muset "formami" naučit. Pokud buduji formuláře bez „formulářů plus“, budu muset vzít v úvahu čas, který potřebuji, abych se naučil nový nástroj. Vzhůru je, že už vím „formy“, takže se nebojím abstrakcí. Krátkodobé výhody budou často pro nové začátečníky větší, protože pravděpodobně nebude existovat nová knihovna, pokud se na něčem nezlepší. Dlouhodobé přínosy se budou velmi lišit v kvalitě abstrakce, míře adopce a dalších faktorech, které již byly uvedeny v jiných odpovědích.

Po pečlivém zhodnocení výhod a negativ použití nové abstrakce „formy plus“ oproti použití „formy holé kosti“ učiním rozhodnutí. Rozhodnutí je velmi založeno na mých osobních zkušenostech a různí lidé se budou rozhodovat jinak. Možná jsem se rozhodl použít „formy“ holých kostí. Možná později v čase formy-plus získaly více pohybu za tím a staly se defacto standardem. A možná moje vlastní implementace v průběhu času byla chlupatá a začala pokrývat hodně toho, co formy-plus teď dělá. Lidé přicházející v tuto chvíli budou přitahováni, aby kritizovali, že jsem nadšený z objevování kola a měl jsem místo toho použít existující knihovnu. Je však také možné, že v době, kdy jsem se musel rozhodovat o „formulářích plus“, existovalo také několik dalších alternativ k „formulářům plus“, většina z nich je zatím mrtvá, a možná jsem získal tím, že jsem nevybral špatné jeden.

Nakonec je výběr správných nástrojů komplikovaným rozhodnutím a „znovuobjevení kola“ není příliš užitečnou perspektivou.

0
Ski