Webfejlesztés A 10 kódoló antipatternát el kell kerülni
Egy weboldal vagy alkalmazás architektúrájának megtervezése, vagy egy hatékony kódolási munkafolyamat beállítása gyakran ismétlődő problémákkal foglalkozik. Nem feltétlenül kell megoldani ezeket a szoftvertervezési problémákat, mint a építészeti szinten megoldásokat lehet újra felhasználni ugyanúgy, mint kódrészletek a mikro-szinten.
A tervezési minták általában újrafelhasználható megoldások bizonyos forgatókönyvek esetében ez lehet hasznos lehet a gyakran előforduló problémák megoldásához, és rendkívül segíthet nekünk a kód optimalizálásában.
Míg a tervezési mintázatok nagyszerű módja a fejlesztési folyamatok javításának, jól tesztelt képletek használatával, néha hibásak is lehetnek velük. Ezeket antipatterneknek nevezik.
Mik azok az antipatternek??
A kifejezés “antipattern” 1998-ban egy AntiPatterns nevű könyvben készült újra hasznosított megoldások, amelyek kezdetben hasznosnak tűnnek, de később kiderül hogy többet ártson, mint jó.
Ez különböző okokból is megtörténhet, például ha nem használjuk a megfelelő kontextusban, környezetben vagy időben használt mintákat (a múltban hatékony megoldások nem mindig működnek a jelenben), vagy más esetekben az egész paradigma csak rossz volt a kezdetektől.
Gyakran nevezik az antipatternákat is a kudarc mintái. A jó hír az, hogy ez felismerhető és elkerülhető.
Ebben a hozzászólásban 10 közös kódolású antipatternot fogunk megnézni a webfejlesztésben, amelyek elgondolkodhatnak bennünket arra, hogy jól optimalizált kódot kapjunk. (Ne feledje, hogy az ebben a bejegyzésben felsorolt antipatternek nem feltétlenül azonosak a fent említett könyvben találhatóakkal.)
1. Korai optimalizálás
A jó időzítés döntő tényező a kód optimalizálásában. Könnyen reprodukálhatjuk az antipatternát “korai optimalizálás”, ha figyelmet fordítunk a kis hatékonyságra és optimalizáljuk őket a fejlesztési folyamat korai szakaszában, mielőtt pontosan tudnánk, mit akarunk tenni.
Donald Knuth híres idézete szerint “a korai optimalizálás minden gonosz gyökere“, ami túlzás lehet, de még mindig megmutatja, hogy a korai optimalizálás későbbi okai milyen komoly problémákat okozhatnak.
Ha egy hatékony architektúra létrehozása előtt optimalizálunk teljesítményt, mi is alacsonyabb kód olvashatóság, csinál hibakeresés és karbantartás nehezebb, és felesleges részeket adjon hozzá kódunkhoz.
A korai optimalizálás megakadályozása érdekében jó ötlet, hogy kövessük a YAGNI (You Aren Gonna Need) programozási elvet, amely azt tanácsolja, hogy “mindig hajtsa végre a dolgokat, amikor valóban szüksége van rájuk, soha, amikor csak azt tervezi, hogy szüksége van rájuk.”
2. A kerék újra feltalálása
A “a kerék újra feltalálása” az antipattern néha más néven “vákuumban történő tervezés”. Ez akkor történik, ha akarjuk tegyünk meg mindent magunknak és írj mindent a semmiből, már meglévő módszerek, API-k vagy könyvtárak keresése nélkül.
A kerék újbóli feltalálása nemcsak időt pazarló dolog, hanem az egyedi megoldások, különösen az alapvető funkciók esetében, ritkán olyan jóak, mint a standardok amelyeket sok fejlesztő és felhasználó már tesztelt.
3. Függőségi pokol
Az ellenkezője a “a kerék újra feltalálása” az antipattern egy másik közös antipattern “függőségi pokol”.
Ha ahelyett, hogy mindent a semmiből írnánk, használjuk túl sok harmadik fél könyvtár, amely más könyvtárak bizonyos verzióira támaszkodik, könnyen frissíthetünk egy könnyen kezelhető helyzetet, mivel ezek a másodlagos függőségek sok esetben összeegyeztethetetlen egymással.
A függő pokol megoldható a csomagkezelők segítségével okosan frissítse az egymástól függő függőségeket. Ha túlságosan túl nagy a problémája, a refaktorálás is jó ötlet lehet.
4. Spagetti kód
“Spagetti kód” talán a leghíresebb kódoló antipattern. Leírja egy olyan alkalmazás, amelyet a megfelelő architektúra hiánya miatt nehéz hibakeresni vagy módosítani.
A rossz szoftvertervezés eredménye olyan kódcsomó, amely struktúrában hasonló egy spagetti tálhoz, vagyis egy csomó kódhoz. kusza és összecsavarodott. A spagetti kód olvashatósága nagyon alacsony, és általában szinte lehetetlen feladat megérteni, hogy pontosan hogyan működik.
A spagetti kód általában a különböző rossz kódolási gyakorlatok kombinációja, mint például a megfelelő kondíciós blokkokat nem tartalmazó kód, amely sok goto-nyilatkozatot, kivételt és szálat tartalmaz, amelyek máshol található részeket tartalmaznak, az objektumok között minimális kapcsolatban állnak, olyan funkciókkal vagy módszerekkel rendelkeznek, amelyeket nem lehet újra felhasználni, vagy amelyek nem használhatók fel megfelelően, vagy nem megfelelően dokumentáltak egyáltalán.
5. Programozás perforálással
“Programozás permutációval” vagy “véletlenszerű programozás” akkor történik meg, amikor megpróbálunk megoldást találni egy problémára úgy, hogy egymás után kísérletezünk kisebb módosításokkal, teszteljük és értékeljük őket, és végre végre kell hajtani azt, amely az elsődlegesen működik.
A permutációval történő programozás könnyen elvégezhető vezessen be új hibákat a kódunkba, ami még rosszabb, azok a hibák, amelyeket nem feltétlenül ismerünk egyszerre. Sok esetben nem is lehet megjósolni, hogy a megoldás minden lehetséges forgatókönyv esetén működik-e vagy sem.
6. Programozás másolása és beillesztése
“Programozás másolása és beillesztése” akkor fordul elő, ha nem követjük a nem ismétlődő (DRY) kódolási elvet, és az általános megoldások létrehozása helyett már meglévő kódrészleteket helyezünk különböző helyekre, és később szerkeszthetjük, hogy illeszkedjenek az adott környezetbe.
Ez a gyakorlat olyan kódot eredményez, amely nagyon ismétlődő, mivel a beillesztett kódrészek általában csak kisebb eltérések esetén különböznek egymástól.
A programozás másolását és beillesztését nemcsak a kezdő fejlesztők, hanem a tapasztalt programozók is követik, mivel sokan hajlamosak rá saját feladataikhoz saját, előre megírt, jól tesztelt kódrészleteket használjon, ami könnyen vezethet nem szándékos ismétlések.
7. Cargo-Cult programozás
A neve “rakomány-kultúra programozás” egy meghatározott néprajzi jelenségből származik “rakománykultúra”. A második világháború után a dél-csendes-óceánban megjelentek a teherkultúrák, amikor a fejlett civilizációkkal való kényszerkontaktusok arra ösztönzik a bennszülötteket, hogy a gyártott termékeket, mint például a Coca-Cola, a televíziókat és a hajók által a szigetekre hozott hűtőszekrényeket, természetfeletti mód; és ha mágikus rítusokat végeznek a nyugati emberek szokásaihoz hasonlóan, az árukkal töltött rakomány újra meg fog jönni.
Amikor elkötelezzük a rakomány-kultúra programozását, alapvetően ugyanezt tesszük. Olyan kereteket, könyvtárakat, megoldásokat, tervezési mintákat stb. Használunk, amelyek mások számára jól működtek, anélkül, hogy megértenénk, miért csináljuk, vagy hogy az említett technológiák pontosan működnek.
Sok esetben csak a fejlesztők rituálisan csináld azt, ami abban az időben csípő, valódi cél nélkül. Ez a gyakorlat nemcsak rossz, mert az alkalmazásunk túlzottan dagadt, de könnyen be is vezethet új hibákat a kódunkba.
8. Láva áramlás
Beszélünk a “lávafolyam” antipattern, ha kell kezelni kell a redundáns vagy alacsony minőségű alkatrészeket hogy úgy tűnik, hogy szerves a programhoz, de nem értjük teljesen, hogy mit csinál, vagy hogyan hat az egész alkalmazásra. Ez kockázatos az eltávolításához.
Ez általában történik Legacy kód, vagy amikor a kódot valaki más írt (általában nem megfelelő dokumentáció nélkül), vagy amikor a projekt túl gyorsan mozog a fejlesztésből a gyártási szakaszba.
Az antipattern neve a vulkánokból származó láva felfogásából származik, vagyis először gyorsan és folyékonyan mozog anélkül, hogy túl sok óvintézkedést hozna, de később megszilárdul és nehezen eltávolítható.
Elméletileg megszabadulhatunk a láva áramlásoktól kiterjedt tesztelés és újraírás, de a gyakorlatban, a végrehajtás gyakran nehéz vagy akár lehetetlen. Mivel a lávafolyások általában nagy teljesítményűek, jobb, ha megakadályozzák őket úgy, hogy egy jól megtervezett architektúrát és egy megbízható munkafolyamatot állítanak be a kezdetektől.
9. Kemény kódolás
“Kemény kódolás” egy jól ismert antipattern, amely ellen a legtöbb webfejlesztési könyv figyelmeztet minket az előszóban. A kemény kódolás a szerencsétlen gyakorlat tároljuk a konfigurációs vagy bemeneti adatokat, például elérési utat vagy távoli gazdanevet, a forráskódban ahelyett, hogy egy konfigurációs fájlból, egy adatbázisból, egy felhasználói bemenetből vagy egy másik külső forrásból szerezné azt.
A legnagyobb probléma a kemény kóddal csak egy bizonyos környezetben működik megfelelően, és a bármikor a feltételek megváltoznak, módosítanunk kell a forráskódot, általában több különálló helyen.
10. Lágy kódolás
Ha nagyon keményen próbáljuk elkerülni a kemény kódolás csapdáját, könnyen eljuthatunk egy másik antipatternhez “lágy kódolás”, ami pontosan ellentétes.
Lágy kódolásban, külső forrásokba helyezzük a forráskódban lévő dolgokat, például az üzleti logikát tároljuk az adatbázisban. A leggyakoribb oka annak, hogy miért tesszük ezt, az a félelem, hogy az üzleti szabályok a jövőben megváltoznak, ezért át kell írnunk a kódot.
Szélsőséges esetekben egy puha kódolású program lehet annyira elvont és meggyőző, hogy szinte lehetetlen megérteni (különösen az új csapat tagjai számára), és rendkívül nehéz karbantartani és hibakeresni.
