Stutt innleiðsluhandbók um endurskipulagningu kóða fyrir byrjendur

Þess vegna er það óskiljanlegt fyrir suma að enduruppbygging kóðans Það er í raun svið í forritun og jafnframt mjög mikilvægur hluti af vinnu forritarans. Kóðinn er sífellt í þróun; hann verður breyttur svo lengi sem mögulegt er að bæta við nýjum virkni. Hins vegar getur hann tekið á sig form sem gerir ekki lengur kleift að bæta á skilvirkan hátt við nýja virkni og það væri auðveldara að endurskrifa allt forritið.

Hvað er endurskipulagning kóða?

Venjulega er svarið sem þú heyrir að um sé að ræða að breyta uppbyggingu kóðans með því að beita röð endurskipulagningabreytinga án þess að hafa áhrif á áberandi hegðun kóðans. Þetta er rétt. Nýlega rakst ég einnig á skilgreiningu eftir Martin Fowler í bók hans “Bæta hönnun núverandi kóða” þar sem hann lýsir enduruppbygging kóðans sem “að gera stórar breytingar í smáum skrefum.” Hann lýsir enduruppbygging kóðans sem kóðabreyting sem hefur ekki áhrif á rekstur þess, en hann leggur áherslu á að henni verði komið í framkvæmd í litlum skrefum.

Bókin mælir einnig með því að enduruppbygging kóðans Á ekki við um rekstur kóðans og bendir á að það hafi engin áhrif á að standast prófin hvenær sem er. Það lýsir skref fyrir skref hvernig á að framkvæma það örugglega. enduruppbygging kóðans. Mér líkaði bókin hans því hún lýsir einföldum brellum sem hægt er að nota í daglegu starfi.

Af hverju þurfum við endurskipulagningu kóðans?

 Oftast þarftu það þegar þú vilt kynna nýja virkni og kóðinn í núverandi útgáfu leyfir það ekki eða það væri erfiðara án breytinga á kóðanum. Einnig er það gagnlegt þegar það er tímalega óhagkvæmt að bæta við fleiri eiginleikum, þ.e. það væri fljótlegra að endurskrifa kóðann frá grunni. Ég held að stundum sé gleymt að enduruppbygging kóðans getur gert kóðann hreinni og læsilegri. Martin skrifar í bók sinni hvernig hann framkvæmir endurskipulagningu þegar hann finnur óþægilega lykt í kóðanum og, eins og hann orðar það, “Það skilur alltaf eftir pláss fyrir hið betra”. Og hann kom mér á óvart með því að sjá umritun kóða sem hluta af daglegu kóðunarstarfi. Fyrir mig eru kóðarnir oft óskiljanlegir; að lesa þá er sérstök reynsla þar sem kóðinn er oft óinnsæis.

Áberandi einkenni vel hannaðs forrits er þess Modularity, Þökk sé því nægir að þekkja aðeins lítinn hluta kóðans til að innleiða flestar breytingar. Modularitet gerir það einnig auðveldara fyrir nýtt fólk að koma inn og byrja að vinna á skilvirkari hátt. Til að ná þessum modularitet þarf að hópa skylda forritunarþætti saman, þannig að tengsl þeirra séu skiljanleg og auðveldlega finnanleg. Það er engin ein einföld regla um hvernig þetta skuli gert. Þegar þú þekkir og skilur betur og betur hvernig kóðinn á að virka, geturðu flokkað þættina, en stundum þarftu líka að prófa og athuga.

Eitt af reglum endurskipulagningar í YAGNI, það er skammstöfun fyrir ‘You Aren't Gonna Need It’ og á rætur sínar að rekja til Öfgaforritun (XP) notað aðallega í Sveigjanlegur hugbúnaðarþróun teams. Til að stytta langa sögu, YAGNI Segir að eingöngu uppfærð verkefni skuli unnin. Þetta þýðir í grundvallaratriðum að jafnvel þótt eitthvað kunni að verða nauðsynlegt í framtíðinni, eigi ekki að gera það núna. En við getum heldur ekki hindrað frekari viðbætur, og hér verður móduleiningaskipulag mikilvægt.

Þegar talað er um enduruppbygging kóðans, eitt af mikilvægustu þáttunum, þ.e. prófunum, verður að nefna. Í enduruppbygging kóðans, við þurfum að vita að kóðinn virkar ennþá, vegna þess að enduruppbygging kóðans breytir ekki því hvernig það virkar, heldur uppbyggingu þess, svo öll próf verða að ganga upp. Það er best að keyra prófin fyrir þann hluta kóðans sem við erum að vinna í eftir hverja litla umbreytingu. Það gefur okkur staðfesting á því að allt virki eins og það á að virka og styttir tímann sem fer í alla aðgerðina. Þetta er það sem Martin ræðir í bók sinni – keyrið prófanir eins oft og mögulegt er svo þið þurfið ekki að taka skref afturábak og eyða tíma í að leita að breytingu sem braut eitthvað.

Kóðaviðgerð Án prófana er þetta plága og miklar líkur eru á að eitthvað fari úrskeiðis. Ef það er mögulegt væri best að bæta við að minnsta kosti nokkrum grunnprófum sem gefa okkur smá vissu um að kóðinn virki.

Umbreytingarnar sem taldar eru upp hér að neðan eru aðeins dæmi en þær eru mjög gagnlegar í daglegri forritun:

• Funktsjónútdráttur og breytnaútdráttur – ef funktsjónin er of löng, athugaðu hvort einhverjar minni funktsjónir séu til sem hægt væri að draga út. Það sama gildir um langar línur. Þessar umbreytingar geta hjálpað til við að finna endurtekningar í kóðanum. Þökk sé smáum funktsjónum verður kóðinn skýrari og auðskiljanlegri.,
• Endurnefning fallanna og breytna – að nota rétt nafngiftarform er nauðsynlegt fyrir góða forritun. Nafn breytna, þegar þau eru vel valin, geta sagt mikið um kóðann.,
• Að hópa fallin í bekk – þessi breyting er gagnleg þegar tveir bekkir framkvæma svipaðar aðgerðir, því hún getur stytt lengd bekkjarins,
• Yfirskrift innfelldrar skilyrðis – ef skilyrðið stenst fyrir sértilfelli, gefðu út return-tilskipun þegar skilyrðið er uppfyllt. Þessar prófanir eru oft kallaðar vörsluklausa. Að skipta út innfelldri skilyrðistilskipun fyrir exit-tilskipun breytir áherslunni í kóðanum. if-else-uppbyggingin gefur báðum útgáfunum jafnan vægi. Fyrir þann sem les kóðann er þetta skilaboð um að hvor um sig sé jafn líkleg og jafn mikilvæg.,
• Kynnum sér sértilfelli – ef þú notar ákveðin skilyrði í kóðanum þínum mörgum sinnum gæti verið þess virði að búa til sérstaka uppbyggingu fyrir þau. Þar af leiðandi er hægt að skipta flestum sértilfellisathugunum út fyrir einföld fallaköll. Oft er algengt gildi sem krefst sérmeðferðar null. Þess vegna er þetta mynstur oft kallað Null-hlutur. Hins vegar er hægt að nota þessa nálgun í hvaða sértilfelli sem er.,
• Endurnýjun margbreytileika skilyrðisboðana.

Dæmi

Þetta er grein um enduruppbygging kóðans og dæmi þarf. Ég vil sýna einfalt endurskipulagningardæmi hér að neðan með notkun Yfirskrift innfelldrar yfirlýsingar og Endurnýjun margbreytileika skilyrðisboðana. Segjum að við höfum forritafall sem skilar a skrá með upplýsingum um hvernig á að vökva plöntur í raunveruleikanum. Slíkar upplýsingar væru líklega í líkaninu, en í þessu dæmi höfum við þær í fallinu.

def watering_info(planta)
 result = {}
 if plant.is_a? Sukkulenta || plant.is_a? Kaktus
 result = { water_amount: "Smávegis", how_to: "Frá botni", watering_duration: "2 vikur" }
 elsif plant.is_a? Alocasia || plant.is_a? Maranta
 result = { water_amount: "Mikið magn", how_to: "Eins og þér hentar", watering_duration: "5 dagar" }
 elsif plant.is_a? Peperomia
 result = { water_amount: "Nóg magn",
 how_to: "Frá botninum! þær vilja ekki vatn á laufunum",
 watering_duration: "1 vika" }
 else
 result = { water_amount: "Dicent amount",
 how_to: "As you prefer",
 watering_duration: "1 vika"
 }
 end
 return result
 end

Hugmyndin er að breyta if í return:

ef plant.isa? Safaríkur || plant.isa? Kaktus

 niðurstaða = { vatnsmagn: "Aðeins smá", hvernig: "Frá botninum",

Til

Skilaðu { water_amount: "A little bit", how_to: "From the bottom", watering_duration: "2 weeks" } ef plant.is_a? Suculent || plant.is_a? CactusHljóðskrift

skila { vatnmagn: “aðeins smá”, hvernigtil: “Frá botni”,vökvunLengd: “2 vikur” } ef plant.isa? Safaríkur plöntu.is_a? Kaktus

Og svo með allt, þar til við komum að falli sem lítur svona út:

def watering_info(plant) 

return result = { wateramount: "Smávegis", howto: "Frá botni", wateringduration: "2 vikur" } if plant.isa? Suculent || plant.is_a? Cactus

return result = { wateramount: "Mikið", howto: "Eins og þér hentar", wateringduration: "5 dagar" } if plant.isa? Alocasia || plant.is_a? Maranta

return result = { water_amount: "Dicent amount",

 howto: "Frá botni! Þær vilja ekki vatn á laufunum",
 wateringduration: "1 vika" } if plant.is_a? Peperomia

return result = { water_amount: "Dicent amount",

 how_to: "As you prefer",

 watering_duration: "1 week"

 }

end

 Í lokin höfðum við þegar fengið niðurstöðuna. Og gott vinnubrögð er að fara skref fyrir skref og prófa hverja breytingu. Þú gætir skipt þessu if-blokka út fyrir switch-case og það myndi strax líta betur út, og þú þyrftir ekki að athuga öll if-skilyrðin í hvert skipti. Það myndi líta svona út:

def watering_info(plant) 

swich plant.class.to_string

case Suculent, Cactus

 { wateramount: "A little bit " , howto: "From the bottom", watering_duration: "2 weeks" }

case Alocasia, Maranta

 { wateramount: "Mikið magn", howto: "Eins og þér hentar", watering_duration: "5 dagar" }

case Peperomia

 { water_amount: "Nóg magn",

 how_to: "Frá botni! Þær vilja ekki vatn á laufunum",

 watering_duration: "1 vika" }

else

 { water_amount: "Dicent amount",

 how_to: "As you prefer",

 watering_duration: "1 week” }

end

end

Og svo geturðu beitt Að skipta út fjölgerðarleika skilyrðisboðana. Þetta er til að búa til bekk með falli sem skilar réttum gildum og skiptir þeim í rétta sæti.

class Suculent...



def watering_info()

 return { wateramount: "A little bit " , howto: "From the bottom", watering_duration: "2 weeks" }

end

end

class Cactus...



def watering_info()

 return { wateramount: "A little bit " , howto: "From the bottom", watering_duration: "2 weeks" }

end

end

class Alocasia

...

def watering_info

 return { wateramount: "Mikið magn", howto: "Eins og þér hentar", watering_duration: "5 dagar" }

end

end

class Maranta...



def watering_info

 return { wateramount: "Mikið magn", howto: "Eins og þér hentar", watering_duration: "5 dagar" }

end

end

class Peperomia...



def watering_info

 return { water_amount: "Dicent amount",

 how_to: "From the bottom! they don't like water on the leaves",

 watering_duration: "1 week" }

end

end

class Plant...



def watering_info

 return { water_amount: "Dicent amount",

 how_to: "As you prefer",

 watering_duration: "1 week" }

end

end

Og í aðal vatnsgjafainfofunction-inu mun kóðinn líta svona út:

`watering_info`(plöntu) 

 `plant.map`(&:watering_info)

`end`

Auðvitað er hægt að fjarlægja þessa fall og skipta henni út fyrir innihald hennar. Með þessu dæmi vildi ég kynna hið almenna mynstur endurskipulagningar.

Yfirlit

Endurskipulagning kóðans er stórt umræðuefni. Ég vona að þessi grein hafi hvatt þig til að lesa meira. Þessar Endurskipulagningarhæfni Verkstæði sem hjálpar þér að finna villur og bæta hreinan kóðann þinn. Ég mæli með að lesa bók Martins (Bæta hönnun núverandi kóða), sem er nokkuð grunnur og gagnlegur regluserð enduruppbygging kóðans. Höfundurinn sýnir ýmsar umbreytingar skref fyrir skref með fullri útskýringu og rökstuðningi og ráðleggingum um hvernig forðast megi villur í enduruppbygging kóðans. Vegna fjölhæfni sinnar er hún yndisleg bók fyrir frontend og bakendaþróunaraðilar.

Lesa meira

GraphQL Ruby. Hvernig er frammistaðan?

Lestar og önnur samgöngutæki

Rails-þróun með tmux, vim, fzf og ripgrep