Greitas pradedančiųjų refaktorizavimo pradžiamokslis

Todėl kai kuriems nesuprantama, kad refaktoringas iš tikrųjų yra programavimo sritis, be to, tai labai svarbi programuotojo darbo dalis. Kodas nuolat tobulėja, jis bus keičiamas tol, kol bus galimybė pridėti naujų funkcijų. Tačiau jis gali įgauti tokią formą, kuri nebeleis efektyviai pridėti naujų funkcijų, ir bus paprasčiau perrašyti visą programą iš naujo.

Kas yra refaktoringas?

Paprastai išgirstate atsakymą, kad tai yra kodo struktūros keitimas, taikant keletą refaktorizavimo transformacijų, nedarant įtakos stebimam kodo elgesiui. Tai tiesa. Neseniai taip pat susidūriau su apibrėžimu pagal Martin Fowler savo knygoje “Esamo kodekso projektavimo tobulinimas” kur jis aprašo refaktoringas kaip “didelių pokyčių darymas mažais žingsneliais”. Jis apibūdina refaktoringas kaip kodo pakeitimas, neturintis įtakos jo veikimui, tačiau jis pabrėžia, kad tai turi būti daroma mažais žingsneliais.

Knygoje taip pat rekomenduojama, kad refaktoringas neturi įtakos kodo veikimui ir nurodo, kad ji neturi jokios įtakos testų išlaikymui bet kuriuo metu. Jame žingsnis po žingsnio aprašoma, kaip saugiai atlikti refaktoringas. Man patiko jo knyga, nes joje aprašomos paprastos gudrybės, kurias galima naudoti kasdieniame darbe.

Kodėl mums reikia refaktorizavimo?

 Dažniausiai jos gali prireikti, kai norite įdiegti naują funkciją, o dabartinės versijos kodas to neleidžia arba tai padaryti būtų sudėtingiau nekeičiant kodo. Be to, jis naudingas tais atvejais, kai pridėti daugiau funkcijų neapsimoka laiko atžvilgiu, t. y. greičiau būtų perrašyti kodą iš naujo. Manau, kartais pamirštama, kad refaktoringas kodas gali būti švaresnis ir lengviau skaitomas. Martinas savo knygoje rašo, kaip jis atlieka refaktorizaciją, kai jaučia nemalonius kvapus kode, ir, kaip jis sako, “visada lieka vietos geresniam”. Ir čia jis mane nustebino matydamas refaktoringą kaip kasdienio darbo su kodu elementą. Man kodai dažnai būna nesuprantami, juos skaityti yra šiek tiek patirtis, nes kodas dažnai būna neintuityvus.

Gerai parengtos programos skiriamasis bruožas yra jos Moduliarumas, dėl kurios pakanka žinoti tik nedidelę kodo dalį, kad būtų galima atlikti daugumą pakeitimų. Be to, dėl modulinės struktūros naujiems žmonėms lengviau įsitraukti ir efektyviau pradėti dirbti. Norint pasiekti tokį modulinį pobūdį, susiję programos elementai turi būti sugrupuoti, o ryšiai turi būti suprantami ir lengvai randami. Vienos taisyklės, kaip tai padaryti, nėra. Kai vis geriau žinote ir suprantate, kaip kodas turėtų veikti, galite grupuoti elementus, tačiau kartais taip pat tenka testuoti ir tikrinti.

Viena iš refaktorizavimo taisyklių YAGNI, tai akronimas, reiškiantis ‘You Aren't Gonna Need It’ ir kilęs iš eXtreme programavimas (XP) daugiausia naudojamas Agile programinės įrangos kūrimas komandos. Trumpa istorija, YAGNI sako, kad reikia daryti tik naujausius dalykus. Tai iš esmės reiškia, kad net jei ko nors gali prireikti ateityje, dabar to daryti nereikėtų. Tačiau mes taip pat negalime užgniaužti tolesnių plėtinių, ir čia svarbus tampa moduliavimas.

Kalbėdami apie refaktoringas, reikia paminėti vieną iš svarbiausių elementų, t. y. bandymus. Svetainėje refaktoringas, turime žinoti, kad kodas vis dar veikia, nes refaktoringas nekeičia jos veikimo būdo, o keičia jos struktūrą, todėl visi testai turi būti atlikti. Geriausia po kiekvieno nedidelio pakeitimo atlikti tos kodo dalies, su kuria dirbame, testus. Tai suteikia mus patvirtinimas, kad viskas veikia taip, kaip reikia, ir sutrumpinamas visos operacijos laikas. Būtent apie tai savo knygoje kalba Martinas - kuo dažniau atlikti bandymus, kad nereikėtų žengti žingsnio atgal ir gaišti laiko ieškant transformacijos, kuri kažką sugadino.

Kodo pertvarkymas be bandymų yra vargas ir didelė tikimybė, kad kažkas bus ne taip. Jei įmanoma, geriausia būtų pridėti bent keletą pagrindinių testų, kurie suteiktų mums šiek tiek užtikrintumo, kad kodas veikia.

Toliau išvardytos transformacijos yra tik pavyzdžiai, tačiau jos tikrai naudingos kasdienėje programavimo veikloje:

• Funkcijos išskyrimas ir kintamųjų išskyrimas - jei funkcija yra per ilga, patikrinkite, ar yra kokių nors mažesnių funkcijų, kurias būtų galima išskirti. Tas pats pasakytina ir apie ilgas eilutes. Šios transformacijos gali padėti rasti pasikartojimų kode. Dėl Mažųjų funkcijų kodas tampa aiškesnis ir suprantamesnis,
• Funkcijų ir kintamųjų pavadinimų keitimas - norint gerai programuoti, labai svarbu naudoti teisingus pavadinimus. Tinkamai parinkti kintamųjų pavadinimai gali daug ką pasakyti apie kodą,
• Funkcijų grupavimas į klases - šis pakeitimas naudingas, kai dvi klasės atlieka panašias operacijas, nes taip galima sutrumpinti klasės ilgį,
• Įterpto teiginio perrašymas - jei sąlyga pasitvirtina specialiu atveju, išveskite grąžinimo teiginį, kai sąlyga įvyksta. Tokio tipo testai dažnai vadinami apsauginiu sakiniu. Pakeitus įterptinį sąlyginį teiginį išėjimo teiginiu, pasikeičia kodo akcentai. Konstruktyve if-else abiem variantams priskiriamas vienodas svoris. Kodą skaitančiam asmeniui tai yra pranešimas, kad kiekvienas iš jų yra vienodai tikėtinas ir svarbus,
• Įveskite ypatingą atvejį - jei kai kurias sąlygas savo kode naudojate daug kartų, galbūt verta joms sukurti atskirą struktūrą. Dėl to daugumą specialiųjų atvejų patikrinimų galima pakeisti paprastais funkcijų iškvietimais. Dažnai pasitaikanti reikšmė, kuriai reikia specialaus apdorojimo, yra null. Todėl šis modelis dažnai vadinamas nuliniu objektu. Tačiau šis metodas gali būti naudojamas bet kuriuo specialiu atveju,
• Sąlyginio nurodymo polimorfizmo pakeitimas.

Pavyzdys

Tai straipsnis apie refaktoringas ir reikia pavyzdžio. Toliau noriu parodyti paprastą refaktorizavimo pavyzdį naudodamas Įterpto teiginio perrašymas ir Sąlyginio nurodymo polimorfizmo pakeitimas. Tarkime, turime programos funkciją, kuri grąžina a hash su informacija, kaip laistyti augalus realiame gyvenime. Tokia informacija tikriausiai būtų pateikta modelyje, tačiau šiame pavyzdyje ji pateikta funkcijoje.

def laistymo_info(augalas)
     result = {}
     if plant.is_a? Suculent || plant.is_a? Kaktusas
         result = { water_amount: "A little bit " , how_to: "Iš apačios", laistymo trukmė: "2 savaitės" }
     elsif plant.is_a? Alocasia || plant.is_a? Maranta
         result = { water_amount: "Didelis kiekis", how_to: laistymo_duration: "Kaip jums patogiau", laistymo_duration: "Kaip jums patogiau": "5 dienos" }
     elsif plant.is_a? Peperomia
         result = { water_amount: "Dicent amount",
             how_to: "jie nemėgsta vandens ant lapų",
             laistymo trukmė: "1 savaitė" }
     else
         result = { water_amount: "Dicent amount",
             how_to: "Kaip jums patogiau",
             watering_duration: "1 savaitė"
             }
     pabaiga
     grąžinti rezultatą
 pabaiga

Idėja yra pakeisti, jei grįžti:

if plant.isa? Suculent || plant.isa? Cactus

     result = { wateramount: "A little bit " , howto: "Iš apačios",

Į

return { water_amount: " , how_to: "Iš apačios",laistymo_trukmė: "2 savaitės" } if plant.is_a? Suculent || plant.is_a? Cactus

grąžinti { vanduosuma: “Šiek tiek” , kaipį: “Iš apačios”, laistymastrukmė: “2 savaitės” } if plant.isa? Sukulentinis || plant.is_a? Kaktusas

Ir taip toliau, kol pasieksime funkciją, kuri atrodo taip:

def laistymo_info(augalas)

return result = { wateramount: " , howto: "Iš apačios", laistymo trukmė: "2 savaitės" } if plant.isa? Suculent || plant.is_a? Cactus

return result = { wateramount: "Didelis kiekis", howto: "Kaip jums patogiau", laistymo trukmė: "5 dienos" } if plant.isa? Alocasia || plant.is_a? Maranta

return result = { water_amount: "Dicent amount",

          howto: "jie nemėgsta vandens ant lapų",
          wateringduration: "1 savaitė" } if plant.is_a? Peperomia

return result = { water_amount: "Dicent amount",

          how_to: "Kaip jums patogiau",

          laistymo trukmė: "1 savaitė"

          }

pabaiga

 Pačioje pabaigoje jau turėjome grąžinimo rezultatą. Geras įprotis - tai daryti žingsnis po žingsnio ir išbandyti kiekvieną pakeitimą. Šį if bloką galėtumėte pakeisti perjungimo atveju (switch case) ir jis iš karto atrodytų geriau, be to, nereikėtų kiekvieną kartą tikrinti visų if. Tai atrodytų taip:

def laistymo_info(augalas)

swich plant.class.to_string

case Suculent, Cactus

     { wateramount: "Šiek tiek " , howto: "Iš apačios", laistymo trukmė: "2 savaitės" }

atvejis Alocasia, Maranta

     { wateramount: "Didelis kiekis", howto: "laistymo trukmė: "5 dienos" }

atvejis Peperomia

     { water_amount: "Dicent amount",

          how_to: "jie nemėgsta vandens ant lapų",

          laistymo trukmė: "1 savaitė" }

else

     { water_amount: "Dicent amount",

            how_to: "Kaip jums patogiau",

       laistymo trukmė: "1 savaitė" }

pabaiga

pabaiga

Tada galite taikyti Sąlyginio nurodymo polimorfizmo pakeitimas. Taip sukuriama klasė su funkcija, kuri grąžina tinkamą reikšmę ir perjungia jas į tinkamas vietas.

klasė Suculent

...

def laistymo_info()

     return { wateramount: " , howto: "Iš apačios", laistymo_trukmė: "2 savaitės" }

end  end

pabaiga

klasė Cactus

...

def laistymo_info()

     return { wateramount: " , howto: "Iš apačios", laistymo_trukmė: "2 savaitės" }

end  end

pabaiga

klasė Alocasia

...

def laistymo_info

     return { wateramount: "Didelis kiekis", howto: "laistymo trukmė: "5 dienos" }

pabaiga

pabaiga

klasė Maranta

...

def laistymo_info

     return { wateramount: "Didelis kiekis", howto: "laistymo trukmė: "5 dienos" }

pabaiga

pabaiga

klasė Peperomia

...

def laistymo_info

     return { water_amount: "Dicent amount",

      how_to: "jie nemėgsta vandens ant lapų",

      laistymo trukmė: "1 savaitė" }

pabaiga

pabaiga

klasė Plant

...

def laistymo_info

     return { water_amount: "Dicent amount",

              how_to: "Kaip jums patogiau",

              laistymo trukmė: "1 savaitė" }

pabaiga

pabaiga

Pagrindinėje laistymo_infofunkcijoje kodas atrodys taip:

def laistymo_info(augalas)

    plant.map(&:watering_info)

pabaiga

Žinoma, šią funkciją galima pašalinti ir pakeisti jos turiniu. Šiame pavyzdyje norėjau pateikti bendrą refaktorizavimo modelis.

Santrauka

Pertvarkymas yra didelė tema. Tikiuosi, kad šis straipsnis paskatino perskaityti daugiau. Šie refaktorizavimo įgūdžiai padės jums sugauti klaidas ir patobulinti švaraus kodo dirbtuves. Rekomenduoju perskaityti Martino knygą (Improving the Design of Existing Code), kuri yra gana paprastas ir naudingas taisyklių rinkinys. refaktoringas. Autorius žingsnis po žingsnio parodo įvairias transformacijas, pateikia išsamius paaiškinimus, motyvaciją ir patarimus, kaip išvengti klaidų. refaktoringas. Dėl savo universalumo tai puiki knyga frontend ir backend kūrėjai.

Skaityti daugiau

"GraphQL Ruby". O kaip dėl našumo?

Bėgiai ir kitos transporto priemonės

"Rails" kūrimas naudojant TMUX, "Vim", Fzf + Ripgrep