Én autodidakta, újonc kódoló vagyok, ezért elnézést kérek, ha nem szögezem le a programozó nyelvet.
Egy olyan projekten dolgozom, amelyben folyamatosan frissülő adatokat szolgáltatok a fejlesztőknek, akik lényegében létrehoznak egy eszközt, amely jelentéseket generál az adatokra vonatkozó lekérdezésekből.
Úgy tűnik, hogy az összes érintett gondolkodik hogy az adatértékeket (nem a sémát, hanem magukat a domaineket / értékeket) be kell kódolniuk a jelentéskészítő programba.
Például tegyük fel, hogy a személyzetről számoltunk be; a jelentés fel lesz osztva kategóriákba sorolva, az egyes részlegek címsorával, majd az egyes részlegek címsorai alatt a munkakörök alcímei, majd az egyes alcímek alatt az alkalmazottak listája lesz. A fejlesztők keményen be akarják kódolni az osztályokat és a munkaköröket. másrészt azt gondolnám, hogy futás közben tudnák / megkérdeznék ezeket a dolgokat, válogatnák a rekordokat ezek szerint, és dinamikusan generálnának jelentésfejléceket az érték alapján vannak.
Mivel a potenciális értékek listája az idő múlásával megváltozik (pl. osztályok jönnek létre / neveznek át, új munkaköröket adunk hozzá), ezért a kódot folyamatosan frissíteni kell. Úgy tűnik számomra, hogy kihagyhatnánk a kódkarbantartás lépéseit és dinamikusan rendezhetnénk a jelentéseket.
Mivel nem vagyok fejlesztő, kíváncsi vagyok, mi hiányzik. Milyen előnyei lehetnek annak, ha keményen kódolják az értékeket egy ilyen eszközbe? Általában így készülnek a programok?
Megjegyzések
- a lehetséges másolata értékek és védekező kialakítás vs YAGNI
- A jelentés keresztfülű, vagyis a sorokban szereplő értékeknek oszlopként kell megjelenniük?
- @Brendan – Ha kemény kódot ad meg a jelentésben , ‘ KÉT helyen kell módosítania a listát (adatforrás és jelentés), míg ha a jelentés dinamikus, akkor csak egy helyen kell megváltoztatnia (a jelentés) .
- @Brendan miért kerülne három helyre? Talán megértésem téves, de ‘ egy sql lekérdezést képzelek el, hogy adatokat lehessen lekérni egy adatbázisból, az alkalmazás összesíti / csoportosítja a visszaadott értékeket, pl. Ha ‘ hajlandó több db db lekérdezés fölött állni, akkor különálló részlegeket / szerepcímeket választhat, ha nagyon szeretné. Az adatok egyetlen helyen sem léteznek egynél több helyen – a jelentést az adatok vezérlik.
- @Brendan Nem értek egyet azzal sem, hogy Ön egy helyen van – ahogy leírja ‘ s több helyen, szétszórva a forráskódban.
Válasz
Wikipédia:
Kemény a kódolás (hardkódolás vagy hardkódolás is) a szoftverfejlesztési gyakorlatra utal, amely beágyazást jelent, ami talán csak utólag tekinthető bemeneti vagy konfigurációs adatnak közvetlenül egy program vagy más futtatható objektum forráskódjába, vagy a adatokat, ahelyett, hogy ezeket az adatokat külső forrásokból szereznénk, vagy adatokat generálnánk vagy formáznánk magában a programban az adott bemenettel.
A keménykódolás antipatternek minősül. .
Tekinthető a n anti-minta, kemény kódolás megköveteli a program forráskódjának megváltoztatását, amikor a bemeneti adatok vagy a kívánt formátum megváltozik, amikor a végfelhasználó számára kényelmesebb lehet a részleteket valamilyen módon a programon kívül megváltoztatni.
Néha nem kerülheti el, de ideiglenesnek kell lennie.
A kemény kódolás gyakran szükséges. Előfordulhat, hogy a programozók nem rendelkeznek dinamikus felhasználói felület-megoldással a kidolgozott végfelhasználók számára, de továbbra is el kell adniuk a funkciót, vagy el kell engedniük a programot. Ez általában ideiglenes, de rövid távon megoldja a kód átadására nehezedő nyomást. Később softkódolás történik, hogy a felhasználó átadhassa azokat a paramétereket, amelyek lehetőséget adnak a végfelhasználónak az eredmények vagy az eredmény módosítására.
- Hardcoding az üzenetek megnehezítik a program nemzetközivé tételét.
- A keménykódolású utak megnehezítik az alkalmazkodást egy másik helyhez.
Úgy tűnik, hogy a keménykódolás egyetlen előnye a gyors kódküldés.
Megjegyzések
- OK , de a ” egyetlen előnye ” gyakran rendkívül fontos. A programozással kapcsolatos tervezési döntések gyakran a jövőbeni igazolás és a gyors kézbesítés közötti kompromisszumról szólnak, és mint ilyen, a kemény kódolás tökéletesen elfogadható választás lehet. Néha a nem kemény kódolás rossz választás.
- -1 Nem hiszem, hogy ez hasznos válasz.
Lényegében azt mondja, hogy ‘ az értékek nem megfelelő beágyazása a forráskódba ‘ nem megfelelő. Úgy gondolom, hogy az OP útmutatást szeretne arról, hogy a dolgok mikor tartozhatnak a forráskódba, és ezért kívül eshetnek a Wikipédia definíciójában.
Válasz
Tényleg? Nincsenek érvényes felhasználási esetek?
Bár egyetértek azzal, hogy a keménykódolás általában anti-pattern vagy legalábbis nagyon rossz kódszag , rengeteg olyan eset van, ahol van értelme. Íme néhány.
-
Egyszerűség / YAGNI .
-
Valódi konstansok, amelyek valójában soha nem változnak.
azaz az állandó egy természetes vagy üzleti állandó, vagy annak közelítése . (pl. 0, PI, …)
-
Hardver vagy szoftver környezeti korlátai
A beágyazott szoftverekben a memória és az allokáció korlátai jutnak eszünkbe.
-
Biztonságos szoftver
Ezek az értékek nem elérhetőek és / vagy könnyen dekódolhatók, vagy visszafejthetőek, pl. kriptográfiai tokenek és sók. (Ne feledje, hogy kemény kódolásuknak nyilvánvaló hátrányai is vannak …)
-
Generált kód
Az előprocesszor vagy generátor konfigurálható, de kiköpi a kódot keményen kódolt értékekkel. Nem szokatlan a szabálymotorokra támaszkodó kódoknál, vagy ha modell-vezérelt architektúrával rendelkezik.
-
Nagy teljesítményű kód
Ez bizonyos értelemben ” generált ” kód , bár még specializáltabb. például. előre meghatározott keresési / számítási táblázat valószínűtlen változásokkal. Ez például egyáltalán nem szokatlan a grafikus programozásban.
-
Konfiguráció és visszaesések
Mind a tényleges kódban, mind a konfigurációs fájlokban valószínűleg vannak konfigurációs értékei, és több esetben is vannak tartalékai (amikor a konfiguráció nem érhető el, amikor egy összetevő nem válaszol várható, stb …). Ennek ellenére általában a legjobb, ha a kódon kívül marad, és utánanéz, de előfordulhat, hogy feltétlenül egy adott műveletre / kérdésre / helyzetre szeretne konkrét értéket / reakciót adni.
-
És valószínűleg még néhány …
Még mindig Anti-Pattern ? Így van ez a túlmérnöki munkával is ! Ez a szoftverének várható élettartamáról szól!
Nem mintha azt mondanám mindennek nagy okai vannak, és általában elutasítom a szigorúan kódolt értékeket. De vannak, akik érvényes okokból könnyedén megszerezhetik az igazolást.
És az elsőt ne felügyeljék az egyszerűség / YAGNI vagy úgy, hogy triviálisnak gondolja: valószínűleg nincs oka egy őrült elemző és értékellenőrző megvalósítására egy egyszerű szkript számára, amely egy feladatot végez keskeny használati esetekben nagyon jól.
Nehéz megtalálni a balat ász. Néha nem látja előre, hogy egy szoftver növekedni fog, és tovább fog tartani, mint az egyszerű szkript, amellyel elindult. Sokszor mégis fordítva van: túltervezzük a dolgokat, és egy projekt gyorsabban áll be, mint amennyire csak lehet olvassa el a Pragmatikus Programozót. Időt és erőfeszítést pazarolt dolgokra, mint amire egy korai prototípusnak nem volt szüksége.
Ez az anti-minták jelentését jelenti: a spektrum mindkét szélsőségében jelen vannak, és megjelenésük a A kódját ellenőrző személy érzékenysége.
Személy szerint hajlamos vagyok mindig az általános utat választani, amint látom, hogy valami megváltozhat , vagy ha “Nem egyszer kellett megtennünk. De pontosabb megközelítés az lenne, ha gondosan értékelnénk a kemény kódolás költségeit, szemben a kód előállításával vagy előállításával az adott helyzethez.Ugyanaz, mint annak meghatározása, hogy egy feladatot érdemes-e automatizálni, nem pedig manuálisan. Csak vegye figyelembe az időt és a költségeket.
Megjegyzések
- Ez ‘ vicces, mert ezt én magam pilotáltam, és sokkal könnyebb, gyorsabb és tisztább volt az értékeket dinamikusan kezelnem. Python, bár úgy gondolom, hogy a végtermék Java-ban lesz kódolva – ha ez megváltoztatja a dolgot. Túlzottan megtervezettnek tűnt, amikor keményen kódoltam az értékeket, mert minden beérkező oszlopot több helyen kellett követni. / li>
- @Tom: Azt mondod, hogy ‘ azt mondod, hogy könnyebb és gyorsabb megvalósítani (vagy akár újrafelhasználni) a konfigurációs keresési könyvtárat, mint kemény kódolású értéket használni? számomra. Továbbá nem látom, hogy ‘ hogyan látja az utolsó mondatod, hogy illeszkedik-e a túlmérnöki tevékenység definíciójához. az angolna nyilván rendetlen, és nyilvánvaló, hogy ha ‘ kemény kódolással és másolással ‘ még rosszabb (ami nem a te lényeged volt kérdéses kérdés, valószínűleg félreértettem, de nekem úgy tűnt, mintha azt értetted volna, hogy az értéket nem minden esetben helyesen kódolták, hanem a program egyetlen pontjában).
- Egyébként I ‘ m csak rámutat azokra az esetekre, amikor ‘ d érvényes. m arra is rámutatok, hogy ‘ ez ellentmondásos az utolsó mondatomban. ‘ Nem kérheti, hogy mindenkinek és a csapatoknak különböző készségű emberek legyenek.
- @Tom, ne ‘ t adj el magadnak túl rövidet. ‘ határozottan folytat valamit. Könnyebben és kevésbé időigényesnek tűnik egy gyors algoritmus megírása az adatok rendszerezéséhez a Tanszék és a Munkakör mezők megnézésével szemben a kemény kódolással
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Sokkal nehezebb lenne fenntartani a kemény kódolású tömböt abban az esetben, ha új részleget vagy címet vezetnének be. - Bonyolultabb dolgokat is megtehet, amelyeket még mindig ésszerű hardveres kódolni. Eszembe jut, amit néhány évvel ezelőtt írtam, az egy értékkészlet összes lehetséges átalakítása volt. Meg kellett találnom egy véletlenszerű érvényes irányt, egy véletlenszerű permutáció kiválasztásával, majd az első érvényes eredmény megszerzésével messze a leghatékonyabb megoldás volt, és mivel O (N ^ 3) hurokban volt, a hatékonyság számított.
Válasz
Bizonyos esetekben rendben vannak a hard-code értékek. Például vannak olyan számok, mint 0, vagy egy, vagy különféle n ^ 2-1 értékek a bitmaszkok számára, amelyeknek algoritmikus célból bizonyos értékeknek kell lenniük. Ha ilyen értékeket adunk a konfigurálhatónak, akkor nincs értékük, és csak a problémák lehetőségét nyitja meg. Más szavakkal, ha egy érték megváltoztatása csak megszakítaná a dolgokat, valószínűleg hardveresen kell kódolni.
Az Ön által adott példában nem látom, hol lenne hasznos a hardkódolás. Minden, amit említ, már szerepelne / kellene az adatbázisban, beleértve a fejléceket is. Még a prezentációt vezérlő dolgok (például rendezési sorrend) is hozzáadhatók, ha nincsenek ott.
Megjegyzések
- Köszönöm. A rendezési sorrend az egyetlen aggodalmam volt. Azonban esetünkben ez nem számít ‘, és nem is gondoltam, hogy ‘ hozzáadva egy másik táblaként az adatbázisba.
- Meg kell jegyeznem, hogy mindezek kezelése a DB-ben egy lehetőség. Használhat konfigurációs fájlokat vagy más megoldásokat is, de a keménykódolás rossz választásnak tűnik. Az opciót gyakran használják, mert ‘ könnyen létrehozható egy felület, amely lehetővé teszi a felhasználók számára az opciók kezelését. Vannak olyan eszközök is, mint a ezt , amelyeket kifejezetten erre a célra terveztek.
Válasz
Robusztus megoldás bevezetése, amely lehetővé teszi, hogy az egyébként nehezen kódolt értékek helyett a végfelhasználók igényei szerint konfigurálhatók legyenek ezen értékek erőteljes ellenőrzése. Üres húrot raktak be? Tettek be valami nem numerikus számot, ahol számnak kellett volna lennie? SQL injekciót végeznek? Stb.
A keménykódolás elkerüli ezeket a kockázatokat.
Ami nem azt jelenti, hogy a keménykódolás mindig, sőt gyakran jó ötlet. Ez csak az egyik figyelembe veendő tényező.