Web izstrāde 10 kodēšanas antivielas, kuras jums jāizvairās
Mājas lapas vai lietojumprogrammas arhitektūras izstrāde vai efektīva kodēšanas darbplūsmas izveide bieži padara mūs par atkārtojamām problēmām. Mums nav obligāti jāatrisina šīs programmatūras izstrādes problēmas no jauna, kā risinājumus arhitektūras līmenī var izmantot atkārtoti tāpat kā koda fragmenti mikro līmenī.
Dizaina modeļi parasti ir izmantojamiem risinājumiem dažiem scenārijiem noderēs, lai atrisinātu bieži sastopamas problēmas, un var ļoti palīdzēt mums optimizēt mūsu kodu.
Lai gan dizaina modeļi ir lielisks līdzeklis, lai uzlabotu mūsu attīstības procesu, izmantojot labi pārbaudītas formulas, dažreiz mēs varam arī nepareizi ar tiem. Tos sauc par antipatterniem.
Kas ir Antipatterns?
Termiņš “antipattern” 1998. gadā tā tika veidota grāmatā ar nosaukumu AntiPatterns atkārtoti izmantotie risinājumi, kas sākotnēji šķiet noderīgi, bet vēlāk izrādās darīt vairāk kaitējuma nekā laba.
Tas var notikt dažādu iemeslu dēļ, piemēram, ja mēs neizmantojam modeļus pareizajā kontekstā, vidē vai laikā (pagātnē spēkā esošie risinājumi ne vienmēr darbojas tagad), vai citos gadījumos visa paradigma bija tikai slikti no paša sākuma.
Bieži tiek saukti arī pretparaugi neveiksmes modeļi. Labā ziņa ir tā, ka tā ir iespējams tos atpazīt un izvairīties.
Šajā amatā mēs apskatīsim 10 kopīgus kodēšanas antipatternus tīmekļa izstrādē, kas var mūs maldināt domājot, ka mums ir labi optimizēts kods. (Ņemiet vērā, ka šajā postenī uzskaitītie pretparaugi ne vienmēr ir tādi paši kā tas, kas atrodams iepriekš minētajā grāmatā.)
1. Priekšlaicīga optimizācija
Labs laiks ir būtisks faktors kodu optimizācijā. Mēs varam viegli atveidot antipatternu “priekšlaicīga optimizācija”, ja mēs pievēršam uzmanību maziem efektivitātes ieguvumiem un optimizējam tos pārāk agri attīstības procesā, pirms mēs precīzi zinām, ko mēs vēlamies darīt.
Saskaņā ar Donald Knuth slaveno citātu “priekšlaicīga optimizācija ir visu ļaunumu sakne“, kas var būt pārspīlējums, bet joprojām parāda, cik nopietnas problēmas var izraisīt priekšlaicīga optimizācija.
Ja mēs optimizējam veiktspēju pirms efektīvas arhitektūras izveides, mēs varam zemāka kodu lasāmība, veidot atkļūdošana un apkope, un pievienot nevajadzīgas daļas mūsu kodu.
Lai novērstu priekšlaicīgu optimizāciju, ieteicams ievērot YAGNI (jums nav nepieciešams to) plānošanas principu, kas iesaka “vienmēr īstenojiet lietas, kad tās tiešām ir nepieciešamas, nekad, kad jūs tikai paredzat, ka jums tās vajag.”
2. Riteņa atjaunošana
The “no jauna izgudrot riteni” antipattern dažreiz tiek saukts arī par “projektēšana vakuumā”. Tas notiek, kad mēs vēlamies darīt visu ar sevi un uzrakstiet visu no nulles, bez jau esošām metodēm, API vai bibliotēkām.
Riteņa izgudrošana nav tikai laika izšķērdoša lieta, bet pasūtījuma risinājumi, īpaši pamata funkcijām, reti ir tikpat labi kā standarta ko jau ir pārbaudījuši daudzi izstrādātāji un lietotāji.
3. Atkarība Hell
Pretējs “no jauna izgudrot riteni” antipattern ir vēl viens kopīgs antipattern sauc “atkarības ellē”.
Ja tā vietā, lai rakstītu visu no nulles, mēs izmantojam pārāk daudz trešo pušu bibliotēku, kas balstās uz citu bibliotēku konkrētām versijām, mēs varam viegli nokļūt grūti pārvaldāmā situācijā, kad mēs vēlamies atjaunināt, jo šīs papildu atkarības ir daudzos gadījumos nesaderīgi.
Atkarības elli var atrisināt, izmantojot paketes pārvaldniekus, kas spēj gudri atjauniniet savstarpēji atkarīgās atkarības. Ja mēs pārāk daudz pārdzīvosim problēmu, refaktorēšana var būt arī laba ideja.
4. Spageti kods
“Spageti kods” iespējams, ir slavenākais kodēšanas antipatterns. Tā apraksta lietojumprogrammu, kuru ir grūti atkļūdot vai modificēt, jo nav pienācīgas arhitektūras.
Sliktas programmatūras izstrādes rezultāts ir koda ķekars, kas pēc struktūras ir līdzīgs spageti bļodai, t.i.. jucis un salocīts. Spageti koda lasāmība ir ļoti zema, un parasti tas ir gandrīz neiespējams uzdevums saprast, kā tas tieši darbojas.
Spageti kods parasti izriet no dažādu sliktu kodēšanas praksi, piemēram, kods, kas nesatur atbilstošus nosacījumu blokus, ar daudziem goto paziņojumiem, izņēmumiem un pavedieniem, kuros ir daļas, kas pieder kaut kur citur, ar minimālām attiecībām starp objektiem, ir funkcijas vai metodes, kuras nevar atkārtoti izmantot vai nav pareizi dokumentētas vai nav pareizi dokumentētas vai pavisam.
5. Programmēšana ar Permutāciju
“Programmēšana ar permutāciju” vai “programmēšana nejauši” notiek, kad mēs cenšamies rast risinājumu problēmai, secīgi eksperimentējot ar nelielām izmaiņām, pārbaudot un novērtējot tās pa vienam, un visbeidzot īstenojot to, kas darbojas vispirms.
Programmēšana ar permutāciju var viegli ieviest jaunus kļūdas mūsu kodā, vēl sliktāk, tās ir kļūdas, kuras mēs ne vienmēr atpazīstam uzreiz. Daudzos gadījumos nav iespējams paredzēt, vai risinājums darbosies visiem iespējamiem scenārijiem, vai ne.
6. Kopējiet un ielīmējiet programmēšanu
“Kopējiet un ielīmējiet programmēšanu” notiek, ja mēs neizpildām kodēšanas principu „Neatkārtojiet sevi (DRY)”, bet nevis ģenerējot vispārējus risinājumus, mēs ievietojam jau esošos koda fragmentus dažādās vietās un vēlāk tos rediģējam, lai tie atbilstu attiecīgajam kontekstam.
Šī prakse rezultāts ir kods, kas ir ļoti atkārtojas, jo ievietotās koda daļas parasti atšķiras tikai nelielās neatbilstībās.
Kopēšanu un ielīmēšanu programmē ne tikai iesācēju izstrādātāji, bet arī pieredzējuši programmētāji, jo daudzi no viņiem ir pakļauti izmantot savus iepriekš sagatavotus, labi pārbaudītus koda fragmentus īpašiem uzdevumiem, kas var viegli novest pie neparedzētas atkārtošanās.
7. Kravu un kultūru programmēšana
Nosaukums “kravu kultu programmēšana” nāk no konkrētas etnogrāfiskās parādības “kravas kulta”. Pēc otrā pasaules kara Klusā okeāna dienvidu daļā parādījās kravas kulti, kad piespiedu kontakts ar progresīvām civilizācijām noveda vietējos iedzīvotājus domāt, ka ražoti produkti, piemēram, Coca-Cola, televizori un ledusskapji, ko kravas kuģi ieveda salās, tika radīti pārdabiskā veidā. metodes; un, ja viņi veiks maģiskus rituālus, kas līdzīgi rietumnieku paradumiem, preces, kas piepildītas ar precēm, atkal nonāks.
Kad mēs apņemamies īstenot kravu-kultu programmēšanas antipatternāciju, mēs to pašu darām. Mēs izmantojam ietvarus, bibliotēkas, risinājumus, dizaina modeļus uc, kas labi darbojās citiem, nesaprotot, kāpēc mēs to darām, vai kā šīs tehnoloģijas precīzi darbojas.
Daudzos gadījumos izstrādātāji vienkārši rituāli darīt to, kas ir gūžas tajā laikā bez jebkāda reāla mērķa. Šī prakse ir ne tikai slikta, jo tas padara mūsu pieteikumu pārmērīgi uzpampis, bet arī var viegli ievadīt jaunus kļūdas mūsu kodā.
8. Lavas plūsma
Mēs runājam par “lavas plūsma” antipattern, kad mums ir nepieciešams nodarbojas ar kodu, kam ir liekas vai zemas kvalitātes detaļas to šķiet neatņemama tomēr mēs pilnībā nesaprotam, ko tas dara vai kā tas ietekmē visu pieteikumu. Tas padara to riskantu noņemt.
Tas parasti notiek ar mantojuma kods, vai kad kodu rakstīja kāds cits (parasti bez pienācīgas dokumentācijas), vai tad, kad projekts pārāk strauji virzījās no izstrādes uz ražošanas posmu.
Antipatterna nosaukums rodas no tā, ka tā ir no vulkāniem iegūta lava, t. I., Sākumā tā kustas ātri un bez šķēršļiem, neņemot vērā pārāk daudz piesardzības pasākumu, bet vēlāk tas sacietē un kļūst grūti noņemams.
Teorētiski mēs varam atbrīvoties no lavas plūsmām plašas pārbaudes un refactoring, bet praksē, īstenošana bieži ir grūti vai pat neiespējama. Tā kā lavas plūsmām parasti ir augstas veiktspējas izmaksas, labāk ir novērst tās, izveidojot labi izstrādātu arhitektūru un pareizu darbplūsmu no sākuma.
9. Cietā kodēšana
“Cietā kodēšana” ir labi pazīstams antipatterns, pret kuru lielākā daļa tīmekļa izstrādes grāmatu mūs brīdina priekšvārda vietā. Cietā kodēšana ir neveiksmīga prakse mēs glabājam konfigurācijas vai ievades datus, piemēram, faila ceļš vai attālais resursdatora nosaukums, pirmkodā nevis iegūt to no konfigurācijas faila, datu bāzes, lietotāja ievades vai cita ārēja avota.
Galvenā problēma ar cieto kodu ir tā, ka tas darbojas tikai noteiktā vidē, un pie jebkurā laikā mainās apstākļi, mums ir jāmaina avota kodu, parasti vairākās atsevišķās vietās.
10. Mīkstā kodēšana
Ja mēs ļoti cenšamies izvairīties no cietās kodēšanas, mēs varam viegli nokļūt citā pretpatternā, ko sauc par “mīksto kodēšanu”, kas ir tieši pretējs.
Mīkstajā kodēšanā, mēs ievietojam lietas, kas būtu jāiekļauj pirmkodā ārējos avotos, piemēram, datu bāzē glabājam biznesa loģiku. Visbiežākais iemesls, kāpēc mēs to darām, ir bailes, ka uzņēmējdarbības noteikumi nākotnē mainīsies, tāpēc mums būs nepieciešams pārrakstīt kodu.
Ārkārtējos gadījumos var veikt mīksto kodu kļūt tik abstrakts un apgriezts, ka to gandrīz nav iespējams saprast (īpaši jauniem komandas locekļiem) un ļoti grūti uzturēt un atkļūdot.
