Arendusmaailma süvenedes on lihtne langeda lõksu kirjutada koodi, mis lihtsalt "töötab". Siiski on tohutu erinevus programmi töötamise ja pikaajalise hooldatavuse tagamiseks hästi struktureeritud programmi vahel . Puhta koodi kontseptsioon, mille populariseeris legendaarne Robert C. Martin, ei seisne jäikade reeglite järgimises, vaid mõtteviisi omaksvõtmises, kus selgus ja lihtsus on absoluutsed prioriteedid.
Selline kirjutamisviis on tark investeering. See mitte ainult ei tee teie elu lihtsamaks, kui projekti kuude pärast uuesti vaatate, vaid optimeerib ka meeskonnatööd ja vähendab oluliselt vigu. Lõppkokkuvõttes on tarkvara elav ja arenev üksus ning kui alus on kaootiline, võib iga väike muudatus muutuda tehniliseks õudusunenäoks.
Puhta koodi põhialused
Koodi korrastamise alustamiseks peame keskenduma loetavusele ja lihtsusele . Idee seisneb selles, et iga arendaja, olenemata oma kogemuste tasemest, saab funktsiooni või klassi eesmärgist ühe pilguga aru, ilma et peaks loogilisi mõistatusi lahti harutama või välise dokumentatsiooni lehekülgi lugema.
Kriitiline punkt on kirjeldav nimetamine . Unustage selliste muutujate nagu "x", "data" või "temp" kasutamine. Nimed peaksid selgelt väljendama objekti eesmärki. Näiteks muutuja "lv_zlsch" asemel oleks palju loomulikum kasutada nime "viaPago". Kui funktsioon vajab selguse huvides pikka nime, on see okei; pikk nimi on eelistatavam kui ebavajalik kommentaar, mis selgitab funktsiooni toimimist.
Teine oluline põhimõte on DRY (Don't Repeat Yourself ehk ära korda ennast ). Koodi dubleerimine on hooldatavuse peamine vaenlane. Kui kirjutad sama loogikat kahes erinevas kohas, on aeg see funktsionaalsus eraldada korduvkasutatavasse funktsiooni või klassi. See hoiab ära olukorra, kus muudatuse tegemisel unustad ühe punkti uuendada, vältides seeläbi kulukaid vigu tootmises.
Samuti peaksime rakendama skaudireeglit : jätke kood veidi puhtamaks, kui see algselt oli. Kui mõne funktsiooni kallal töötades märkate midagi, mis ei vasta kvaliteedistandarditele, parandage see, isegi kui see pole teie praeguse ülesande osa. See võitleb katkiste akende teooria vastu , hoides ära koodi halvenemise leviku kogu projektis.
Funktsioonide disain ja klasside korraldus
Funktsioonide puhul on kuldreegel, et need peaksid tegema ühte asja ja tegema seda hästi. Liiga pikk funktsioon on ohumärk. Kui kood ületab 20 rida või selle täielikuks nägemiseks on vaja kerida, on ilmselt aeg see väiksemateks osadeks jagada. See mitte ainult ei muuda koodi loetavamaks, vaid lihtsustab oluliselt ka ühiktestimist.
Parameetrite osas peaksite ideaalis piirama argumentide arvu kolmega . Kui vajate rohkem, on ilmselt parem edastada objekt või struktuur. Lisaks on soovitatav vältida "else" liigset kasutamist, eelistades varajasi tagastusi või kasutades lihtsate tingimuste jaoks kolmekomponentseid operaatoreid, mis muudab programmi voo palju lineaarsemaks ja otsesemaks.
Klassi korraldamisel on oluline järgida loogilist järjekorda. Soovitatav on alustada staatiliste ja eksemplari omadustega (järgides järjekorda: privaatne, kaitstud ja avalik), millele järgnevad konstruktorid ning lõpuks meetodid, mis on järjestatud nende tähtsuse järgi. Getterite ja setterite lõppu jätmine aitab lugejal keskenduda esmalt peamisele äriloogikale.
Tehniline võlahaldus ja refaktoreerimine
Tehniline võlg on "intress", mida maksame arendusprotsessi käigus otseteede võtmise eest. See võib olla hoolimatu (koodi kopeerimine internetist seda mõistmata) või ettevaatlik (teadmine, et see pole optimaalne lahendus, kuid prioriseeritakse teostust). Olenemata tüübist on selle lahendamiseks vaja pidevat refaktoreerimist.
Refaktoreerimine hõlmab koodi sisemise struktuuri parandamist ilma selle välist käitumist muutmata. Selle ohutuks tegemiseks on oluline automatiseeritud testimine (TDD ). Testipõhine arendus võimaldab meil enne loogika kirjutamist määratleda eeldatava käitumise, luues turvavõrgu , mis võimaldab meil koodi puhastada kartmata midagi rikkuda.
Oluline on tuvastada koodis esinevaid ebameeldivaid lõhnu . Need viitavad sellele, et midagi on valesti: „jumalikud” klassid, mis teevad kõike, mitmetähenduslike nimedega muutujad või surnud koodilõigud, mida enam ei kasutata. Nende lõhnade tuvastamine ja kõrvaldamine on võtmetähtsusega, et vältida süsteemi jäigaks ja skaleerimatuks muutumist.
Kohandamine vastavalt programmeerimiskeelele
Kuigi põhimõtted on universaalsed, on igal keelel oma eripärad. Näiteks C#-s on oluline kasutada avalike väljade asemel omadusi, et säilitada kapseldamine ja kasutada LINQ-d deklaratiivsemate ja puhtamate andmepäringute tegemiseks.
JavaScripti ökosüsteemis on ülioluline liikuda `var`-i kasutamisest edasi `let` ja `const`-i kasuks, et muutujate ulatust paremini kontrollida. Samuti aitab puhaste funktsioonide loomise ja koodi modulariseerimise edendamine vältida sellele keelele omaseid ettearvamatuid kõrvalmõjusid.
Teisest küljest seab Python juba lihtsuse esikohale, kuid visuaalse järjepidevuse säilitamiseks on oluline järgida PEP 8 juhendit. Loendimõistmiste kasutamine on võimas tööriist kokkuvõtlikuma ja elegantsema koodi kirjutamiseks selgust ohverdamata.
Lõpuks, Javas on paindlikkuse suurendamiseks soovitatav pigem komponeerimine kui pärimine. Kotlini ja Java võrdlemisel näeme, et Stream API ja annotatsioonide kasutamine võimaldab vähendada korduva koodi hulka, muutes andmetöötluse palju väljendusrikkamaks ja tõhusamaks.
Puhtuse ja jõudluse tasakaal
On levinud müüt, et puhas kood kahjustab jõudlust. Miski ei saaks olla tõest kaugemal. Enneaegne optimeerimine toob sageli kaasa keerulise ja loetamatu koodi. Ideaalis peaksite kõigepealt kirjutama puhta koodi ja seejärel tegelike profileerimisandmete põhjal optimeerima ainult konkreetseid kitsaskohti.
Õigete andmestruktuuride valimine mitte ainult ei paranda kiirust, vaid lisab ka selgust. Eesmärk on leida kompromiss, kus tarkvara töötab tõhusalt , kuid jääb igale inimesele arusaadavaks, vältides mõttetuid optimeerimisi, mis lisavad vaid visuaalset segadust.
Nende distsipliinide omaksvõtmine muudab igapäevatöö kvaliteeti, võimaldades tarkvaral tervislikult ja jätkusuutlikult kasvada. Selguse eelistamine kohesele kiirusele vähendab hooldusaega ja suurendab meeskonna üldist tootlikkust, muutes programmeerimise professionaalseks ja skaleeritavaks digitaalse meisterlikkuse harjutuseks .
