Jsem samouk, nováček, kodér, takže se omlouvám, pokud programátora nezarazím.
Pracuji na projektu, ve kterém poskytuji data, která budou průběžně aktualizována, vývojářům, kteří v podstatě vytvoří nástroj pro generování reportů z dotazů na data.
Zdá se, že si všichni zúčastnění myslí že musí naprogramovat datové hodnoty napevno (nikoli schéma, ale samotné domény / hodnoty) do programu generování přehledů.
Předpokládejme například, že bychom podávali zprávy o personálu; zpráva by byla rozdělena do kategorií s nadpisem pro každé oddělení a poté pod každým nadpisem oddělení budou podnadpisy názvů pracovních pozic a pak pod každou podnadpisem bude seznam zaměstnanců. Vývojáři chtějí naprogramovat oddělení a názvy pracovních míst napevno. na druhou stranu bych si myslel, že mohou / budou tyto věci vyhledávat za běhu, třídit podle nich záznamy a generovat záhlaví zpráv dynamicky podle toho, jakou hodnotu Jsou tam.
Jelikož se seznam potenciálních hodnot bude v průběhu času měnit (např. budou vytvořena / přejmenována oddělení, budou přidány nové názvy pracovních pozic), bude nutné tento kód neustále aktualizovat. Zdá se mi, že bychom mohli přeskočit kroky údržby kódu a dynamicky uspořádat přehledy.
Protože nejsem vývojář, zajímalo by mě, co mi chybí. Jaké výhody by mohly být při pevném kódování hodnot do takového nástroje? Je to tak, jak jsou obvykle navrženy programy?
Komentáře
- možný duplikát Odstranění napevno hodnoty a obranný design vs. YAGNI
- Jsou křížové karty přehledu, což znamená, že hodnoty v řádcích by se měly zobrazovat jako sloupce?
- @Brendan – Pokud v přehledu zadáte hodnoty pevného kódu , budete ‚ muset změnit seznam na DVOU místech (zdroj dat a přehled), zatímco pokud je přehled dynamický, stačí jej změnit pouze na jednom místě (přehled) .
- @Brendan, proč byste skončili na třech místech? Možná moje chápání není správné, ale ‚ m si představuji dotaz sql pro načtení dat z databáze, aplikace agreguje / seskupí vrácené hodnoty, např. Oddělení. Pokud ‚ jste ochotni mít režii několika dotazů db, můžete si vybrat konkrétní oddělení / názvy rolí, pokud opravdu chcete. Data v žádném okamžiku neexistují na více než jednom místě – přehled je založen na datech.
- @Brendan Také nesouhlasím s vaší definicí toho, že jsou na jednom místě – tak, jak je popisujete ‚ s na více místech, roztroušených po zdrojovém kódu.
Odpovědět
Wikipedia:
Tvrdý coding (hard-coding or hardcoding) odkazuje na praxi vývoje softwaru pro vkládání toho, co může být, snad jen zpětně, považováno za vstupní nebo konfigurační data přímo do zdrojového kódu programu nebo jiného spustitelného objektu, nebo pevné formátování namísto získávání těchto dat z externích zdrojů nebo generování dat nebo formátování v samotném programu s daným vstupem.
Tvrdé kódování je považováno za antipattern .
Považováno za a n Anti-pattern, tvrdé kódování vyžaduje změnu zdrojového kódu programu při každé změně vstupních dat nebo požadovaného formátu, kdy by pro koncového uživatele mohlo být pohodlnější změnit detail nějakým způsobem mimo program.
Někdy se mu nemůžete vyhnout, ale mělo by to být dočasné.
Tvrdé kódování je často vyžadováno. Programátoři nemusí mít vypracované řešení dynamického uživatelského rozhraní pro koncového uživatele, ale přesto musí tuto funkci dodat nebo uvolnit program. To je obvykle dočasné, ale v krátkodobém smyslu to vyřeší tlak na doručení kódu. Později se provádí softcoding, který umožňuje uživateli předat parametry, které koncovému uživateli umožňují upravit výsledky nebo výsledek.
- Hardcoding zpráv znesnadňuje internacionalizaci programu.
- Cesty s pevným kódováním ztěžují přizpůsobení jinému umístění.
Jedinou výhodou hardcodingu se zdá být rychlé dodání kódu.
Komentáře
- OK , ale “ jediná výhoda “ je často nesmírně důležitá. Rozhodování o návrhu v programování jsou často o kompromisu mezi budoucím nátiskem a rychlým doručením hned teď, a proto může být tvrdé kódování naprosto přijatelnou volbou. Někdy ne tvrdé kódování je špatná volba designu.
- -1 Nemyslím si ‚, že je to užitečná odpověď. V podstatě říká, že ‚ vkládání hodnot do zdrojového kódu nevhodně ‚ je nevhodné. Myslím, že OP chce pokyny ohledně toho, kdy věci mohou patřit do zdrojového kódu, a proto nespadají do definice vaší Wikipedie.
- Tvrdé kódování by mělo být důležitou součástí vašeho procesu a vzhledem k tomu, že anti-vzor je v doba mikroslužeb, přičemž výukový program Angular Tour of Heroes je významným příkladem obrovského softwarového domu přímo kódujícího nebo dokonce nařizujícího jako mezikrok. Navíc, když přejdete na dynamická data, měli byste si stále ponechat některá pevně zakódovaná data jako záložní, možná řízená proměnnou prostředí nebo dokonce booleovským přepínáním samotného kódu, takže chyby a bezpečnostní problémy lze správně izolovat řádek.
Odpověď
Opravdu? Nejsou možné případy platného použití?
I když souhlasím s tím, že pevné kódování je obecně anti-vzor nebo alespoň velmi špatný vůně kódu , existuje spousta případů, kdy to dává smysl. Zde je několik.
-
Jednoduchost / YAGNI .
-
Skutečné konstanty, které se ve skutečnosti nikdy nezmění.
tj. konstanta představuje přirozený nebo obchodní konstanta nebo aproximace jedné. (např. 0, PI, …)
-
Hardwarové nebo softwarové environmentální omezení
Ve vestavěném softwaru přicházejí na mysl omezení paměti a přidělení.
-
Zabezpečený software
Tyto hodnoty nejsou k dispozici a / nebo se nedají snadno dekódovat nebo zpětně analyzovat, např. kryptografické tokeny a soli. (Pamatujte, že jejich pevné kódování má také zjevné nevýhody …)
-
Generovaný kód
Váš preprocesor nebo generátor je konfigurovatelný, ale vyplivne kód s pevně zakódovanými hodnotami. Není to neobvyklé pro kód, který se spoléhá na motory pravidel, nebo pokud máte architekturu založenou na modelu.
-
Vysoce výkonný kód
Tímto způsobem je “ generován “ kód , i když ještě specializovanější. např. předem určená vyhledávací / výpočetní tabulka s nepravděpodobnými změnami. To například není vůbec neobvyklé v grafickém programování.
-
Konfigurace a záložní řešení
Jak ve vašem skutečném kódu, tak v konfiguračních souborech pravděpodobně budete mít konfigurační hodnoty a záložní řešení pro několik případů (když je konfigurace nedostupná, když komponenta nereaguje jako očekávané atd.). Obecně je nejlepší ponechat jej mimo kód a vyhledat ho, ale mohou nastat případy, kdy chcete mít konkrétní hodnotu / reakci na konkrétní akci / problém / situaci.
-
A pravděpodobně ještě pár …
Stále Anti-Pattern ? Takže Over-Engineering ! Jde o průměrnou délku života vašeho softwaru !!
Ne, že to říkám existují všechny skvělé důvody a obecně se bráním pevně zakódovaným hodnotám. Někteří však mohou z platných důvodů snadno získat povolení.
A na první z nich, co se týká jednoduchosti / YAGNI buď tím, že si myslíte, že je to triviální: pravděpodobně není důvod implementovat šílený analyzátor a kontrolu hodnoty pro jednoduchý skript, který dělá jednu práci pro úzký případ použití dobře.
Je těžké najít bal ance. Někdy nepředvídáte, že software poroste a vydrží déle než jednoduchý skript, ve kterém začínal. Často je to ale naopak: věci přeinstruujeme a projekt se odloží rychleji, než můžete přečtěte si programátor Pragmatic. Ztratili jste čas a úsilí na věci, než jaký raný prototyp nepotřeboval.
To je průměrná věc s Anti-Patterns: jsou přítomny v obou extrémech spektra a jejich vzhled závisí na citlivost osoby, která kontroluje váš kód.
Osobně bych měl tendenci vždy jít obecnou cestou, jakmile zjistím, že se něco může změnit nebo pokud „Musel jsem to udělat více než jednou. Ale přesnějším přístupem by bylo pečlivě vyhodnotit náklady na hard-coding vs. generování nebo generování kódu pro konkrétní situaci.Je to stejné jako určit, zda má úkol automatizaci, na rozdíl od manuálního provedení. Berte v úvahu čas a náklady.
Komentáře
- To ‚ je vtipné, protože jsem to sám pilotoval a bylo pro mě mnohem snazší, rychlejší a čistší dynamicky zpracovávat hodnoty. Udělal jsem to v Python, zatímco já věřím, že konečný produkt bude kódován v Javě – pokud to bude mít rozdíl. Cítil jsem se přepracovaný, když jsem naprogramoval hodnoty, protože každý příchozí sloupec musel být sledován na více místech.
- @Tom: Říkáte ‚, že je snazší a rychlejší implementovat (nebo dokonce znovu použít) konfigurační vyhledávací knihovnu, než použít pevně zakódovanou hodnotu? Skvělé pro vás. Také nechápu ‚, jak vaše poslední věta odpovídá definici over-engineeringu. úhoř zjevně chaotický a samozřejmě pokud je ‚ pevně zakódován a duplikován otázka otázka, pravděpodobně jsem nepochopil, ale zdálo se mi, jako byste mysleli, že hodnota nebyla pokaždé pevně zakódována, ale v jediném bodě programu).
- Každopádně jsem ‚ m jen upozorňuji na případy, kdy ‚ d je platný. Také ‚ m poukazuji na to, že ‚ d je v mé poslední větě kontroverzní. Nemůžete ‚ potěšit všechny a týmy lidí s různou úrovní dovedností.
- @Tom, ned ‚ t prodávejte se příliš krátce. Jste ‚ určitě na něčem. Zní to snadněji a méně časově náročné napsat rychlý algoritmus pro uspořádání dat, když se podíváte na pole Oddělení a Název úlohy na rozdíl od pevného kódování
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Bylo by také mnohem obtížnější udržovat pevně zakódované pole pro případ, že by bylo zavedeno nové oddělení nebo titul. - Můžete mít složitější věci, které jsou stále citlivé na pevný kód. Jeden, který mi přijde na mysl, který jsem napsal před několika lety, byly všechny možné obměny souboru hodnot. Potřeboval jsem najít náhodný platný směr, vybrat náhodnou permutaci a poté vzít první platný výsledek byl zdaleka nejúčinnějším řešením a protože to bylo v účinnosti smyčky O (N ^ 3).
Odpověď
Někdy je v pořádku naprogramovat hodnoty napevno. Například existují některá čísla jako 0 nebo jedna nebo různé hodnoty n ^ 2-1 pro bitové masky, které musí být určitými hodnotami pro algoritmické účely. Povolení těchto hodnot konfigurovatelnému nemá žádnou hodnotu a otevírá pouze možnost problémů. Jinými slovy, pokud by změna hodnoty jen porušila věci, pravděpodobně by měl být napevno.
V příkladu, který jste uvedli, nechápu, kde by bylo užitečné pevné kódování. Všechno, co zmiňujete, by již mělo / mělo být v databázi, včetně nadpisů. Lze přidat i věci, které řídí prezentaci (například pořadí řazení), pokud tam nejsou.
Komentáře
- Díky. Pořadí řazení bylo ten jediný problém, který jsem měl. V našem případě to však nezáleží ‚ t a ani jsem ‚ neuvažoval, že by to mohlo být přidáno jako další tabulka v databázi.
- Všiml bych si, že správa tohoto všeho v DB je jednou z možností. Můžete také použít konfigurační soubory nebo jiná řešení, ale hardcoding se zdá být špatnou volbou. DB možnost se často používá, protože ‚ je snadné vytvořit rozhraní, které uživatelům umožní spravovat možnosti. K dispozici jsou také nástroje jako toto , které jsou speciálně navrženy pro tento účel.
Odpověď
Implementace robustního řešení, které umožňuje, aby hodnoty, které by jinak mohly být pevně zakódovány, byly konfigurovatelné podle požadavků koncových uživatelů robustní validace těchto hodnot. Vložili prázdný řetězec? Vložili něco nečíselného, kde to mělo být číslo? Dělají SQL injection? Atd.
Tvrdé kódování se vyhýbá mnoha těmto rizikům.
Což neznamená, že tvrdé kódování je vždy nebo dokonce často dobrý nápad. To je jen jeden z faktorů, které je třeba vzít v úvahu.