Veebiarendus 10, mida peate vältima

Veebisaidi või rakenduse arhitektuuri kujundamine või tõhusa kodeerimisprotsessi loomine tihti panevad meid toime korduvate probleemidega. Me ei pea tingimata neid tarkvaraprobleeme lahendama nullist, nagu lahendusi arhitektuurilisel tasandil saab taaskasutada samamoodi nagu koodilõigud mikrotasandil.

Disainimustrid on üldiselt korduvkasutatavad lahendused teatud stsenaariumide puhul kätte toimetada tavaliselt esinevate probleemide lahendamiseks, ja aitab meil meie koodi optimeerida.

Ehkki disainimustrid on suurepärased vahendid meie arendusprotsessi parandamiseks, kasutades selleks hästi testitud valemeid, siis mõnikord saame nendega ka valesti minna. Neid nimetatakse antipatternideks.

Mis on Antipatternid?

Termin “antipattern” see loodi 1998. aastal raamatus nimega AntiPatterns korduvkasutatud lahendused, mis algselt tunduvad olevat kasulikud, kuid hiljem selgub teha rohkem kahju kui kasu.

See võib juhtuda erinevatel põhjustel, näiteks kui me ei kasuta mustreid õiges kontekstis, seades või ajal (minevikus efektiivsed lahendused ei pruugi alati toimida) või muudel juhtudel kogu paradigma oli algusest peale halb.

Samuti nimetatakse sageli antipatternatsioone rikkeid. Hea uudis on see, et see on võimalik neid ära tunda ja vältida.

Selles postituses vaatame veebiarenduses 10 tavalist kodeerivat antipatternsiooni, mis võivad meid mõtlema, et meil on hästi optimeeritud kood. (Pange tähele, et selles postituses loetletud antipatternid ei pruugi olla samad, mis eespool mainitud raamatus.)

1. Enneaegne optimeerimine

Hea ajastus on koodide optimeerimise oluline tegur. Me võime kergesti paljuneda “enneaegne optimeerimine”, kui me pöörame tähelepanu väikestele tõhusustele ja optimeerime neile liiga vara arenguprotsessis, enne kui me täpselt teame, mida me tahame teha.

Donald Knuthi kuulsa tsitaadi järgi “enneaegne optimeerimine on kogu kurja juur“, mis võib olla liialdus, kuid siiski näitab, kui tõsised probleemid enneaegne optimeerimine võib hiljem põhjustada.

Kui me optimeerime jõudluse enne tõhusa arhitektuuri loomist, võime madalam koodide loetavus, tegema silumine ja hooldus raskem, ja lisage üleliigsed osad meie koodile.

Enneaegse optimeerimise vältimiseks on hea järgida programmeerimispõhimõtet YAGNI (Sa ei vaja seda), mis soovitab “rakendage asju alati, kui neid tegelikult vajate, mitte kunagi, kui te lihtsalt ette näete, et neid vajate.”

2. Ratta uuendamine

The “ratta leiutamine” antipatternit nimetatakse mõnikord ka kui “projekteerimine vaakumis”. See juhtub siis, kui tahame teha kõike ise ja kirjutage kõike nullist, otsimata juba olemasolevaid meetodeid, API-sid või raamatukogusid.

Ratta taaselustamine ei ole ainult aeganõudev asi, vaid kohandatud lahendused, eriti põhifunktsioonide puhul, on harva nii head kui tavalised mida paljud arendajad ja kasutajad on juba katsetanud.

3. Sõltuvuse põrgu

Vastupidi “ratta leiutamine” antipattern on veel üks levinud antipattern “sõltuvuse põrgu”.

Kui selle asemel, et kirjutada kõike nullist, kasutame seda liiga palju kolmanda osapoole raamatukogusid, mis toetuvad teiste raamatukogude spetsiifilistele versioonidele, kui me soovime seda värskendada, saame kergesti sattuda vaevalt juhitavasse olukorda, kuna need kõrvalised sõltuvused on paljudel juhtudel omavahel kokkusobimatu.

Sõltuvuse põrgu saab lahendada pakettide haldajate abil, kes suudavad värskendage üksteisest sõltuvaid sõltuvusi. Kui probleem on liiga palju, võib hea idee olla ka refaktoriseerimine.

4. Spageti kood

“Spageti kood” on ilmselt kõige kuulsam kodeeriv antipattern. See kirjeldab rakendus, mida on raske üles ehitada või muuta, kuna puudub õige arhitektuur.

Halva tarkvarakujunduse tulemus on kood, mis on struktuurilt sarnane spagetidega, s.t.. segamini ja keerdunud. Spagetikoodide loetavus on väga madal ja tavaliselt on peaaegu võimatu mõista, kuidas see täpselt toimib.

Tavaliselt tuleneb spageti kood erinevate halbade kodeerimismeetodite kombinatsioon, nagu kood, mis ei sisalda õigeid tingimusi sisaldavaid plokke, millel on palju goto-avaldusi, erandeid ja niidid, mis sisaldavad kusagil mujal asuvaid osi, on objektide vahel minimaalsed, neil on funktsioone või meetodeid, mida ei saa korduvalt kasutada, või mis ei ole dokumenteeritud või ei ole dokumenteeritud õigesti või üleüldse.

5. Programmeerimine Permutatsiooniga

“Programmeerimine permutatsiooniga” või “programmeerimine” juhtub siis, kui püüame leida probleemile lahenduse, katsetades üksteise järel väikeseid muudatusi, katsetades ja hinnates neid ning lõpuks rakendades selle, mis algselt toimib.

Programmeerimine permutatsiooni abil on lihtne tutvustage meie koodis uusi vigu, veel hullem, nad on vead, mida me ei pruugi kohe ära tunda. Paljudel juhtudel on ka võimatu ette näha, kas lahendus töötab kõigi võimalike stsenaariumide puhul või mitte.

6. Programmeerimise kopeerimine ja kleepimine

“Programmeerimise kopeerimine ja kleepimine” tekib siis, kui me ei järgi kodeerimispõhimõtet „Ära korda ennast” (DRY) ja geneeriliste lahenduste loomise asemel lisame erinevatesse kohtadesse juba olemasolevad koodilõigud ja hiljem redigeerime neid vastavalt antud kontekstile..

See praktika tulemuseks on kood, mis on väga korduv, kuna sisestatud koodiosad erinevad tavaliselt ainult väikestes erinevustes.

Programmeerimise kopeerimine ja kleepimine on mitte ainult algajate arendajate, vaid ka kogenud programmeerijate poolt, sest paljud neist on kalduvad kasutage oma ülesannete jaoks oma eelnevalt kirjutatud, hästi kontrollitud koodilõiguid, mis võib kergesti kaasa tuua tahtmatud kordused.

7. Cargo-Cult programmeerimine

Selle nimi “kaubakultuuri programmeerimine” pärineb konkreetsest etnograafilisest nähtusest “kaubakult”. Pärast 2. maailmasõda ilmnesid Vaikse ookeani lõunaosas kaubakultuurid, kui sunnitud kontakt arenenud tsivilisatsioonidega viisid kohalikke inimesi mõtlema, et toodetud tooted, nagu Coca-Cola, televiisorid ja külmikud, mille kaubalaevad toovad saartele, loodi üleloomuliku meetodid; ja kui nad täidavad maagilisi rituaale, mis sarnanevad lääneriikide tavadele, tuleb kaubaga täidetud kaubad uuesti.

Kui me paneme toime kauba-kultuuri programmeerimise antipatteri, teeme põhimõtteliselt sama. Me kasutame raamistikke, raamatukogusid, lahendusi, disainimustreid jne, mis toimisid teiste jaoks hästi, mõistmata, miks me seda teeme, või kuidas nimetatud tehnoloogiad täpselt töötavad.

Paljudel juhtudel on arendajad lihtsalt rituaalselt tehke seda, mis sel ajal on puhas, ilma tegeliku eesmärgita. See praktika ei ole mitte ainult halb, sest see muudab meie taotluse üleliiaga paisunuks, kuid see võib meie koodis ka uusi vigu tutvustada.

8. Lava voog

Me räägime sellest “laava vool” antipattern, kui me seda vajame tegeleda koodiga, millel on üleliigsed või madala kvaliteediga osad seda näib olevat lahutamatu programmi, kuid me ei mõista täielikult, mida ta teeb või kuidas see kogu rakendust mõjutab. See muudab selle eemaldamise ohtlikuks.

Tavaliselt juhtub pärandkood, või kui koodi kirjutas keegi teine (tavaliselt ilma nõuetekohase dokumentatsioonita) või kui projekt liikus arengust tootmisetappi liiga kiiresti.

Antipatterni nimi tuleneb selle vulkaanidest pärineva laavaga, st alguses liigub see kiiresti ja vedelikult, võtmata liiga palju ettevaatusabinõusid, kuid hiljem tahkestub ja muutub raskeks ja eemaldatavaks..

Teoreetiliselt saame laavavoogudest vabaneda ulatuslik testimine ja refactoring, kuid praktikas, rakendamine on sageli raske või isegi võimatu. Kuna laavavoogudel on tavaliselt kõrged jõudluskulud, on parem neid ennetada, luues algusest peale hästi kavandatud arhitektuuri ja töökorralduse..

9. Kõva kodeerimine

“Kõva kodeerimine” on tuntud antipattern, mille vastu enamik veebiarenduskirju hoiatab meid eessõnas. Kõva kodeerimine on kahetsusväärne praktika salvestame konfiguratsiooni- või sisendandmed, näiteks faili tee või serveri nimi, lähtekoodi selle saamine konfiguratsioonifailist, andmebaasist, kasutaja sisendist või mõnest muust allikast.

Peamine probleem kõva koodiga on see see toimib ainult kindlas keskkonnas, ja kell tingimused muutuvad, me peame muutma lähtekoodi, tavaliselt mitmes erinevas kohas.

10. Pehme kodeerimine

Kui me püüame kõvade kodeerimise lõksu vältida, saame kergesti sattuda teise nimega antipattern “pehme kodeerimine”, mis on selle täpselt vastupidine.

Pehme kodeeringus, paneme asjad, mis peaksid olema lähtekoodi, välistesse allikatesse, näiteks salvestame andmebaasi äriloogika. Kõige tavalisem põhjus, miks me seda teeme, on hirm, et ärireeglid tulevikus muutuvad, seetõttu peame koodi ümber kirjutama.

Äärmuslikel juhtudel võib pehme kodeeritud programm muutunud nii abstraktseks ja keeruliseks, et seda on peaaegu võimatu mõista (eriti uute meeskonnaliikmete puhul) ja äärmiselt raske hooldada ja siluda.