Kui eelmises blogipostituses sai räägitud "puhtast" koodist, mille olemasolu puudumisest annab märku code smell, siis antud kirjutises räägiksin antipatternitest, mille vaste eesti keeles võiks olla nurimustrid. Code smell on umbes nagu see, kui külmkapis on midagi halvaks läinud - koodis on mingid ebakõlad, alati ei ole võimalik öelda, mis need täpselt on, aga annab märku sellest, et kood ei ole ilmselt kõige paremini kirjutatud.
Nurimuster on pigem vastand disainimustritele. Disainimustrid on tüüplahendused enamlevinud probleemidele programmeerimises - näiteks abstract factory loob klasside perekonnast objekti, prototüüp on initsialiseeritud objekt, mida saab kopeerida või kloonida jne.
Nurimustrid tekivad olukorras, kus disainimustreid ei implementeerita või implementeeritakse neid vigaselt. Kuna neil kõigil on sellised toredad nimed ja neid on hea teada, siis tooksin siinkohal mõned välja:
Spagetikood
Spagetikood on ilmselt väljend, mida paljud on kuulnud. Täpsemalt tähendab see koodi, millel on väga vähe struktuuri, selle sisust ei pruugi aru saada isegi algne arendaja, kui on koodist veidi aega eemal olnud, objektid ja meetodid ei ole taaskasutatavad ning objektorienteeritust ei ole kas üldse või on halvasti implementeeritud. Tavaliselt põhjustab seda vähene kogemus objektorienteeritud programmeerimises, ebaefektiivne koodiülevaatus, arendajate eraldi töötamine ning disainiprotsessi puudumine enne implementeerimist.
Kuldne haamer
Ehk kui sul on haamer käes, siis paistavad kõik asjad nagu naelad. Ilmselt kõige levinum nurimuster valdkonnas. Enamasti näeb see välja selline, et arendusmeeskond on saavutanud teatava kompetentsi mingi tööriista/raamistiku kasutamises. Tulemusena näeb iga uus toode või arendus välja kui midagi, mida saab nende tööriistade/raamistikega lahendada, isegi kui see ei pruugi antud juhul olla parim lahendus.
Laavavool
Laavavool, sest laava on alguses voolav, kuid ajapikku taheneb ning muutub raskesti eemaldatavaks. Laavavoolu võib tihti näha projektides, mis on algselt loodud eksperimentaalsetena, kuid on hiljem siiski kasutusele võetud. Tihti on kood täis erinevaid eksperimentaalseid lahendusi, ebaselgeid muutujaid ja funktsioone, mille puhul keegi ei saagi enam aru, miks need seal on, sest algsed loojad on ammu lahkunud, kuid mida keegi ka enam eemaldada ei julge, kartes midagi ära lõhkuda, ehk siis need on "tahenenud". Koodis võib olla väljakommenteeritud osi või kohti, mida tegelikult kunagi ei käivitu.
Ankur
Ankur on tükk tark- või riistvara, millest ei ole projekti juures tegelikku kasu. Tihti oli selle omandamine ka kallis ja omandamise hetkel olid kindlasti selleks head põhjused, kuid lõpuks kulutavad arendajad aega, et kuidagigi ankrut kasulikuks muuta. Kui see ei õnnestu, võib ankur ka lihtsalt seisma jääda. Lahendusena oleks hea praktika omada tehnilist tagavaravarianti, mida saaks minimaalsete koodimuudatustega kasutusele võtta.
Selliseid mustreid on veel palju ning kokkuvõtteks tasub neid kindlasti programmeerimisel silmas pidada - nii nurimustreid ära tunda, disainimustreid kasutusele võtta kui ka koodiülevaatusel aru saada, millest vanemarendajad räägivad. :)
https://agiil.github.io/sonastik/#nurimuster
https://refactoring.guru/design-patterns
https://sourcemaking.com/antipatterns/software-development-antipatterns
https://blog.codacy.com/code-smells-and-anti-patterns
Comments
Post a Comment