Web razvoj 10 kodiranje antipatterns morate izbjegavati
Dizajniranje arhitekture web-mjesta ili aplikacije ili postavljanje učinkovitog procesa kodiranja često nas tjera da se nosimo s problemima koji se ponavljaju. Ne moramo nužno rješavati ove probleme dizajna softvera od nule, kao rješenja na arhitektonskoj razini mogu se ponovno koristiti na isti način kao isječke koda na mikro razini.
Obrasci dizajna su općenito višekratna rješenja za određene scenarije, koji mogu dobro je riješiti uobičajene probleme, i mogu nam pomoći da optimiziramo naš kod.
Iako su dizajnerski obrasci velika sredstva za poboljšanje našeg razvojnog procesa pomoću dobro testiranih formula, ponekad možemo ići u krivu s njima. To se naziva antipatterns.
Što su antipatterns?
Uvjet “antiobrazac” skovan je u knjizi AntiPatterns iz 1998. godine ponovno korištena rješenja koja se u početku čine korisnima, ali se kasnije ispostavilo učiniti više štete nego koristi.
To se može dogoditi iz različitih razloga, na primjer ako ne koristimo obrasce u pravom kontekstu, okruženju ili vremenu (rješenja koja su bila učinkovita u prošlosti ne moraju uvijek raditi u sadašnjosti), ili u drugim slučajevima cijelu paradigmu bilo je loše od samog početka.
Često se nazivaju i antipatterns obrasci neuspjeha. Dobra vijest je da je moguće ih je prepoznati i izbjeći.
U ovom članku ćemo pogledati 10 uobičajenih antipatterns kodiranja u web razvoju koji nas mogu obmanuti u razmišljanje da imamo dobro optimiziran kod. (Imajte na umu da antipatterns navedene u ovom postu nisu nužno isti kao što možete naći u knjizi gore spomenuto.)
1. Preuranjena optimizacija
Dobro vrijeme je ključni čimbenik u optimizaciji koda. Lako možemo reproducirati antipattern od “preuranjena optimizacija”, ako obratimo pozornost na male učinkovitosti i optimiziramo ih prerano u razvojnom procesu, prije nego što točno znamo što želimo.
Prema čuvenom navodu Donalda Knutha “prerana optimizacija je korijen svega zla“, što može biti pretjerivanje, ali još uvijek pokazuje koliko ozbiljna pitanja mogu uzrokovati prijevremena optimizacija.
Ako optimiziramo performanse prije postavljanja učinkovite arhitekture, možemo niža čitljivost koda, napraviti debagging i održavanje teže, i dodati suvišne dijelove u naš kod.
Da bi se spriječila preuranjena optimizacija, dobro je slijediti princip programiranja YAGNI (nije vam potreban) koji savjetuje “uvijek provodite stvari kada ih zapravo trebate, nikad kada samo predvidite da ih trebate.”
2. Ponovno otkrivanje kotača
“otkrijte točak” antipattern se ponekad naziva i “projektiranje u vakuumu”. To se događa kada to želimo činite sve sami i napisati sve od nule, bez traženja već postojećih metoda, API-ja ili knjižnica.
Ponovno otkrivanje kotača nije samo stvar koja troši vrijeme, nego prilagođena rješenja, posebno za osnovne funkcionalnosti, rijetko su dobri kao standardna koje su već testirali mnogi programeri i korisnici.
3. Pakao ovisnosti
Suprotno od “otkrijte točak” antipattern je još jedan uobičajeni antipattern koji se zove “pakao zavisnosti”.
Ako, umjesto da pišemo sve ispočetka, koristimo previše knjižnica trećih strana koje se oslanjaju na određene verzije drugih knjižnica, lako možemo naići na teško upravljivu situaciju kada želimo ažurirati, jer su ovisne ovisnosti u mnogim slučajevima nespojive jedna s drugom.
Ovisnost o paklu može se riješiti korištenjem paket menadžera koji mogu pametno ažurirajte međuovisne ovisnosti. Ako nas problem preplavi previše, refactoring također može biti dobra ideja.
4. Kod špageta
“Špageti kod” je vjerojatno najpoznatiji antipattern kodiranja. Ona opisuje aplikacija koju je teško ispraviti ili izmijeniti zbog nedostatka odgovarajuće arhitekture.
Rezultat lošeg dizajna softvera je hrpa koda koja je po strukturi slična zdjeli špageta, tj. zamršen i zamršen. Čitljivost špagetskog koda je vrlo niska, i obično je gotovo nemoguće shvatiti kako točno funkcionira.
Špageti kod obično proizlazi iz kombinacija različitih praksi lošeg kodiranja, kao što je kod koji ne sadrži blokove ispravnih uvjeta, s puno goto izraza, iznimaka i niti, koji sadrže dijelove koji pripadaju negdje drugdje, ima minimalne veze između objekata, ima funkcije ili metode koje se ne mogu ponovno upotrijebiti, ili nije dokumentiran ispravno ili uopće.
5. Programiranje pomoću permutacije
“Programiranje pomoću permutacije” ili “slučajno programiranje” se događa kada pokušamo pronaći rješenje za problem sukcesivnim eksperimentiranjem s malim izmjenama, testiranjem i procjenom jednog po jednog, i na kraju implementacijom onoga koji radi na početku.
Programiranje pomoću permutacije može lako uvesti nove bugove u naš kod, još gore, to su greške koje ne prepoznajemo odmah. U mnogim slučajevima također je nemoguće predvidjeti hoće li rješenje funkcionirati za sve moguće scenarije ili ne.
6. Programiranje kopiranja i lijepljenja
“Programiranje kopiranja i lijepljenja” pojavljuje se kada ne slijedimo načelo Ne ponovi sebe (DRY), a umjesto stvaranja generičkih rješenja umetnemo već postojeće isječke koda na različita mjesta, a kasnije ih uredimo kako bi se uklopili u navedeni.
Ova praksa rezultira kodom koji se jako ponavlja, budući da se umetnuti dijelovi koda obično razlikuju samo u manjim odstupanjima.
Programiranje kopiranja i lijepljenja ne obavljaju samo programeri novaka, već i iskusni programeri, jer mnogi od njih su skloni tome koristiti vlastite unaprijed napisane, dobro testirane isječke koda za određene zadatke, do kojih lako može doći nenamjerna ponavljanja.
7. Programiranje tereta-kulta
Ime od “programiranje u kultima tereta” dolazi iz specifičnog etnografskog fenomena koji se naziva “teretni kult”. Teretni kultovi pojavili su se u južnom Pacifiku nakon Drugog svjetskog rata, kada prisilni kontakt s naprednim civilizacijama naveo domorodce da pomisle da su proizvedeni proizvodi, kao što su Coca-Cola, televizori i hladnjaci koje su donijeli teretni brodovi na otoke, stvoreni nadnaravnim metode; i ako obavljaju čarobne obrede slične običajima zapadnjaka, teret ispunjen robom ponovno će doći.
Kada počinimo antipattern za programiranje kulta tereta, u osnovi činimo isto. Koristimo okvire, knjižnice, rješenja, obrasce dizajna, itd. Koji su dobro funkcionirali za druge, bez razumijevanja zašto to činimo, ili kako te tehnologije točno funkcioniraju.
U mnogim slučajevima programeri samo Ritualno činite ono što je u to vrijeme bez ikakve svrhe. Ova praksa nije samo loša jer čini našu prijavu suviše nadutom, ali također može lako uvesti nove bugove u naš kod.
8. Lava Flow
Govorimo o “tok lave” antipattern kada trebamo baviti se kodom koji ima suvišne ili niskokvalitetne dijelove da čini se integralnim programa, ali ne razumijemo u potpunosti što radi ili kako utječe na cijelu aplikaciju. To ga čini rizičnim za uklanjanje.
To se obično događa naslijeđeni kod, ili kada Kod je napisao netko drugi (obično bez odgovarajuće dokumentacije), ili kada je projekt prešao iz razvoja u fazu proizvodnje.
Naziv antipattern dolazi iz njegove sličnosti s lavom koja dolazi iz vulkana, tj. Najprije se kreće brzo i fluidno bez preduzimanja previše mjera opreza, ali se kasnije učvršćuje i postaje teško ukloniti.
U teoriji, možemo se riješiti tokova lave opsežno testiranje i refactoring, ali u praksi, provedba je često teška ili čak nemoguća. Budući da tokovi lave obično imaju visoke troškove izvedbe, bolje ih je spriječiti postavljanjem dobro dizajnirane arhitekture i dobrog radnog procesa od samog početka..
9. Tvrdo kodiranje
“Tvrdo kodiranje” je dobro poznati antipattern protiv kojeg nas većina knjiga o razvoju weba upozorava upravo u predgovoru. Teško kodiranje je nesretna praksa u kojoj pohranjujemo konfiguracijske ili ulazne podatke, kao što je put datoteke ili naziv udaljenog hosta, u izvornom kodu umjesto dobivanja iz konfiguracijske datoteke, baze podataka, korisničkog unosa ili drugog vanjskog izvora.
Glavni problem s tvrdim kodom je taj radi ispravno samo u određenom okruženju, i na kad se uvjeti promijene, trebamo modificirati izvornog koda, obično na više odvojenih mjesta.
10. Soft Coding
Ako se jako potrudimo izbjeći zamku tvrdog kodiranja, lako možemo upasti u drugi antipattern koji se zove “soft kodiranje”, što je upravo suprotno.
Kod soft kodiranja, stavljamo stvari koje bi trebale biti u izvornom kodu u vanjske izvore, na primjer pohranjujemo poslovnu logiku u bazu podataka. Najčešći razlog zašto to činimo je strah da će se poslovna pravila u budućnosti promijeniti, stoga ćemo morati prepisati kod.
U ekstremnim slučajevima, soft program može postali tako apstraktni i zamršeni da je gotovo nemoguće shvatiti (posebno za nove članove tima) i iznimno teško održavati i ispravljati.
