nehakeris.lt Blogas apie iOS, Swift, programavimą, etc.

Knygos Clean Code apžvalga: Sneak Peek

Pagaliau tai bus pirmasis straipsnis daugiau ar mažiau apie programavimą. Šiame straipsnyje apžvelgsiu knygą apie švaraus kodo rašymą - Clean Code. Clean Code autorius @unclebobmartin Robert C. Martin, aka Uncle Bob yra programinės įrangos inžinierius, bei rašytojas parašęs ir daugiau tikrai teisingų knygų.
Clean Code knygoje sudėta daugelio metų patirtis, kurią autorius įgavo dirbant, klystant ir mokantis iš savo bei kitų klaidų. Knygos skaitymas nebus paprastas. Skaitydami knygą privalėsite skaityti ir kodą bei sukti galvą spręsdami iššūkius. Ši knyga suteikia galimybę pasimokyti iš profesionalo patarimų, tapti geresniais programuotojais ir sumažinti žodžių junginio “WTF” skaičių, kuriuos pasakys kitas programuotojas pamatęs mūsų rašytą kodą.

Kodo gerumo matavimas

Keli faktai, kurie padės atsakyki į kilusius klausimus apie knygą ir apsispręsti ar jums būtų naudinga perskaityti ją:

Sneak Peek:

Apžvalgsime šiuos knygos skyrius:

Mažiau bullshit’o, eikime prie reikalo.

Švarus kodas (Clean Code)

Švarus kodas

Pirmame skyriuje autorius paaiškina, kodėl švarus kodas toks svarbus. Visa tai yra pagrindžiama pavyzdžiais, kurie iliustruoja, kaip ir kodėl kompanijos, kuriančios daug potecialo turinčius produktus, sugriuna dėl blogo kodo. Skaitydami šį skyrių suprasime tikrąją blogo kodo kainą, kuri laikui bėgant eksponentiniu greičiu komandos produktyvumą artina link nulio.

Produktyvumas ir laikas

Kad išvengti šios katastrofos turime atsisakyti minties, kad kažką padarysime vėliau. Nes “Vėliau = Niekada”. Skyrius baigiamas palyginant kodą su gerai žinoma skautų taisykle:
“Palikime stovyklavietę švaresnę nei ją radome”
Kai jau žinome kokia yra blogo kodo kaina, galime judėti prie skyrių, kurie suteiks žinių kaip konkrečiai nustatyti blogą kodą, jo išvengti arba pakeisti geru.

Prasmingi pavadinimai (Meaningful Names)

Prasmingi vardai

“Gerų vardų parinkimas pareikalauja laiko, bet sutaupo daugiau nei pareikalauja.” - Robert C. Martin

let s: Int? // ellapsed time in seconds

//vs

let elapsedTimeInSecods: Int?

Kurį kodą lengviau perskaityti, ir naujiems komandos nariams suprasti?

struct DtaRcrd102 {
  let genymdhms: Date
  let modymdhms: Date?
  let pszqint = "102"
  /*...*/
}

ar

struct Customer {
  let generationTimestamp: Date
  let modificationTimestamp: Date?
  let recordId = "102"
  /*...*/
}

Funkcijos (Functions)

Funkcijos

Skirius apie funkcijas pradedamas su dvejais funkcijų kodo pavyzdžiais. Pirmąjį kodą autorius pasiūlo perskaityti ir per tris minutes stengstis suprasti ką tas kodas daro. Tai nelengva užduotis, kadangi funkcija yra gana ilga ir ji daro daug ką. Antrasis kodas - ta pati funcija tačiau sutrumpinta iki 10 eilučių. Taip autorius priveda prie pirmos taisyklės rašant funkcijas.

Uncle Bob’as pataria, kad funkcijos retai kada turėtų būti 20 eilučių ar didesnės. Jeigu naudojame if, else, while - po to blokas turėtų būti vienos eilutės ilgio. Ir tai tikriausiai bus kitos funkcijos kvietimas. Taip mes išlaikysime funkcijas trumpas ir lengvai skaitomas.

Kaip suprasti, ar funcija atlieka tik vieną darbą? Vienas iš būdų yra patikrinti ar galima būtų iš esamos funckijos ištraukti naują funkciją, su vardu, kuris nebūtų esamos funkcijos pasikartojimas.

Kad išlaikyti funkcijas trumpas ir darančias tik vieną dalyką, siūloma funkcijoje išlaikyti vieną abstrakcijos lygį.

Ateityje pažadu parašyti straipsnių apie SOLID ir dizaino modelius.

Šiame skyriuje yra siūloma labiau koncentruotis į funkcijų vardų parinkimą. Siūlama išbandyti kelis skirtingus vardus ir žiūrėti kaip lengviau yra skaityti kodą. Trumpos funkcijos, atliekančios vieną dalyką, turėtų skaitytis lyg pasakojimas.

Daug informacijos esančios knygoje apie teisingą funkcijų rašymą liko nepaminėta, čia išrinkau, savo nuomone, pagrindinius pamąstymus. Uncle Bob programavimą sulygina su istorijos rašymu. Klases priskirdami daiktavardžiams, o veiksmažodžius funkcijoms galime sukurti vientisą istoriją. Iš pradžių ji bus lyg rašinėlis juodraštyje - sunkiai skaitomas, netolygus ir kreivas. Reikės įdėti darbo (unit testai tą darbą labai palengvins), kelis kartus perrašyti ir ta istorija taps lengvai ir maloniai skaitoma.

Komentarai (Comments)

Komentarai

“Don’t comment bad code - rewrite it.”

Šio skyriaus pagrindinė mintis - komentarai yra blogis 💩. Geriausiu atveju, teisingai panaudoti komentarai kompensuoja mūsų nesekmę save suprantamai išreikšti rašant kodą. Jeigu parašome komentarus, dažniausiai turime jaustis blogai, nes kodas savaime nėra suprantamas. Blogas kodas

Autoriaus nuomone, komentarai dažnai būna pasenę, neatnaujinami kartu su kodu, nepalaikomi. Palaipsniui komentarai tampa visiškai melagingi ir neatspindintys tikrovės. O melagingi komentarai yra dar blogiau nei blogai.

Tad vietoj to, kad savo energiją ir laiką švaistytume galvojant kuo tikslesnį komentarą, geriau skirkim daugiau laiko ekspresivaus kodo rašymui. Knygoje pateikiamos dvi kodų variacijos - su komentaru ir be. Kurį jūs mieliau skaitytumėte?

// Check to see if the employee is eligible for full benefits
if ((employee.flags  && HOURLY_FLAG) && employee.age > 65){}

//vs

if employee.isEligibleForFullBenefits(){}

Autorius taip pat pateikia, kelis pavyzdžius, kada komentarai gali būti naudingi. Pavyzdžiui, įspėjimas //Don't run unless you have some time to kill. prie testo, kuris trunka labai ilgą laiką, gali būti naudingas.

Šiame skyriuje yra ir daugiau gerų ir blogų kodo panaudojimo pavyzdžių. Aš čia jų nepateiksiu. Nes jeigu viską parašyčiau, nebūtų prasmės patiems perskaityti knygos, taip? 😊

Formatavimas (Formatting)

Formatavimas Skirius apie kodo formatavimą yra suskirstytas į dvi dalis, kurios aprašo vertikalų ir horizontalų formatavimą. Trumpai apie vertikalų ir horizontalų formatavimus:

Vertikalus Formatavimas

Šiame poskyryje rašoma apie kodo eilučių skaičių source file’e. Autorius pabrėžia, kad dažniausiai galime išvengti daugiau nei 200 eilučių skaičiaus file’e. Kartais galime pasiekti ir 500 eilučių, kas turėtų būti limitas. Žinoma, retais atvejais šis skaičius gali būti ir dar didesnis, tačiau reikia prisiminti, kad mažesni file’ai yra lengviau suprantami.
Čia autorius source file’us palygina su laikraščio straipsniais. Straipsnio pirmajame paragrafe dažniausiai sudaromas įspūdis apie ką bus rašoma tame straipsnyje. Skaitant ir leidžiantis žemiau, randame daugiau detalių: datų, vardų, citatų ir t.t. Mes norime, kad source file’as primintų laikraščio straipsnį. Pavadinimas turėtų būti paprastas, bet aiškus. File’o viršuje turėtume rasti high-level konceptus ir algoritmus. Leidžiantis žemyn - turėtume rasti daugiau detalių. Pačioje apačioje randame lowest level funkcijas. Laikraštis sudarytas iš daug straipsnių, dauguma yra gana maži, kiti didesni. Labai nedaug straipsnių užima visą puslapį. Jeigu laikraštyje būtų viena ilga istorija sudaryta iš padrikų faktų, datų, vardų - laikraštis papraščiausiai nebūtų skaitomas.

Autorius pateikia daug pavyzdžių kaip vertikaliai formatuojant source file’ą, jį paversti grafiškai patraukliu. Tačiau sužinosite kaip tai padaryti skaitydami knygą patys 😊.

Horizontalus Formatavimas

Šiame skyriuje autorius kalba apie kodo eilučių ilgumą. Kaip teigia Robert C. Martin, jis pats stengiasi, kad kodo eilutė nebūtų ilgesnė nei 120 simbolių. Rasite pavyzdžių kaip išlygintis, išcentruoti kodo blokus, kad jie būtų lengvai skaitomi. while, for, if dažnai kodą paverčia sunkiai skaitomu - šiame skiriuje taip pat rasite pavyzdžių kaip to išvengti.

Pabaigai

Tai buvo trumpa ir paprasta apžvalga knygos, kuri yra naudinga nesvarbu kokia kalba tu programuoji. Nežinau, ar ši knyga yra išversta į lietuvių kalbą, tačiau Amazon’e lengvai rasite anglišką versiją.
Gero ir smagaus skaitymo! 👌