Meni

Preoblikovanje kode: kaj morate vedeti o tem

code refactoring what you need know about it

Preizkusite Naš Instrument Za Odpravo Težav

Razumevanje preoblikovanja kod: perspektiva preizkuševalca

Izraz „preoblikovanje“ se v glavnem uporablja za označevanje zahtevanega čiščenja / preoblikovanja kode.

V tej vadnici bomo razumeli definicijo refaktoringa, razpravljali o potrebi po refaktoringu kode in pregledali vpliv kode refaktoringa na različne člane projektne skupine. Obravnavali bomo tudi odgovor na najpomembnejše vprašanje - Zakaj morate kot preizkuševalec vedeti o refaktoringu?

Poleg tega bomo razložili nekaj študij primerov za razjasnitev koncepta.

Refaktoriranje kode

Kaj se boste naučili:

Uvod v refaktoring

Za začetek najprej razumemo, kaj pravzaprav je refaktoring.

Refaktoriranje je v bistvu praksa ali postopek izboljšanja kode in / ali baze podatkov ob ohranjanju obstoječe funkcionalnosti. Ideja je spremeniti neučinkovito in preveč zapleteno kodo v bolj učinkovito, po možnosti enostavnejšo in lažjo kodo.

Refaktoriranje kode je po zaslugi pristopa agilnega razvoja programske opreme zdaj dobilo zagon tudi več skupin. Projektne skupine imajo pogosto omejen čas za uvedbo novih ali razširitev funkcionalnosti obstoječih funkcij in čiste kode. Koda, ki je enostavna za razumevanje in vzdrževanje, zagotovo močno prispeva k izpolnjevanju roka za ponovitev.

Potreba po preoblikovanju kode

Če ohranjamo prvotno funkcionalnost aplikacije ali modula, se zastavlja vprašanje Zakaj se sploh trudimo z refaktoringom? No, obstajajo številni razlogi, zaradi katerih bo morda treba predelati določen modul ali del kode, na primer:

  1. Koda diši
  2. Tehnični dolg
  3. Agilni pristop k razvoju programske opreme itd.

O teh točkah bomo podrobno razpravljali v naslednjih poglavjih.

# 1) Vonj kode:

Vsi lahko razumemo, da ko hrana začne dišati, to kaže, da se najverjetneje slabo spremeni - to velja tudi za kodo! Vonji kode kažejo, da lahko v kodi obstaja veliko resnih težav.

Sledi nekaj pogostih vonjav kode:

  • Prisotnost odvečne ali enake kode.
  • Deklarirana spremenljivka, ki se ne uporablja nikjer v preostali kodi.
  • Prezapleteno oblikovanje kode.
  • Razred kode, ki naredi premalo in ne upravičuje obstoja definiranega razreda. Takšni razredi so znani kot leni razred ali brezplačni nakladalnik.
  • Obstoj preveč pogojev in zank, ki bi jih bilo mogoče razčleniti in poenostaviti.
  • Izdelava kode na način, da sprememba enega dela kode zahteva, da se sprememba izvede tudi na drugih mestih.

Vonji kod postanejo bolj očitni sčasoma. Ko aplikacija ali sistem raste, sčasoma te vonjave kode začnejo vplivati ​​na razvoj, vzdrževanje in celo delovanje sistema v ekstremnih scenarijih.

# 2) Tehnični dolg:

Med razvojem programske opreme lahko v omejenem času in razpoložljivih virih pogosto uporabimo bližnjice, da dosežemo želene rezultate.

Razmislite o funkciji, ki jo je treba dodati obstoječemu modulu. Po razpravi skupina zoži dva pristopa, da doda to funkcijo. Pristop A, ki traja 2 sprinta, bo odobren dolgoročni pristop. Pristop B traja le 5 dni, da je neurejen trdo kodiran kramp, ki je namenjen le kratkoročnemu servisu modula.

Če je ekipa pod pritiskom, da funkcijo dostavi v omejenem času, se lahko zaenkrat strinja, da bo sledila pristopu B in dodala pristop A v zaostanku za prihodnost. S tem je ta ekipa samo ustvarila tehnični dolg zase.

Preprosto povedano, tehnični dolg pri razvoju programske opreme se nanaša na dodatno predelavo ali režijske stroške, potrebne za postavitev ustreznih popravkov ali za izvedbo stvari na 'pravi način'.

Podedovani sistemi sčasoma ponavadi pridobivajo velik tehnični dolg, kar lahko povzroči, da je aplikacija dovzetna za okvare in jo je težko podpirati in vzdrževati.

Preberi več=> Kaj je tehnični oddelek

# 3) Po pristopu agilnega razvoja programske opreme:

Pristop agilnega razvoja programske opreme zagovarja postopni razvoj. Brez čiste, dobro strukturirane kode, ki jo je enostavno vzdrževati, ekipe ne bi mogle razširiti obstoječe kode z vsako ponovitvijo. Če se koda spremeni brez ustreznega preoblikovanja, lahko prispeva k vonjem kode ali tehničnemu dolgu.

To razmerje je prikazano na spodnjem diagramu

Pristop agilnega razvoja programske opreme

Priporočeno branje => Vrhunska orodja za analizo kode

Zakaj mora QA vedeti o refaktoringu?

Karkoli smo do zdaj razpravljali v tej vadnici, se zdi povezano s kodiranjem in je videti, kot da bi moral razvijalec skrbeti.

Zakaj potem o tem nepovezanem konceptu razpravljamo v skupnosti za pomoč pri testiranju programske opreme? Nadaljujte z branjem nadaljevanja te vadnice za odgovor na to vprašanje.

# 1) Za preizkuševalce enot / razvijalce

Med refaktoringom kode se ob vstavljanju nove kode posodabljajo stari razredi, dodajajo se novi razredi in obstoječi preizkusi enote zdaj morda ne bodo uspeli. Poleg tega za starejše sisteme morda sploh niso izvedeni preskusi enot. V večini primerov bo treba te nove enotne teste ustvariti in nastaviti iz nič.

# 2) Za preizkuševalce

Ko se funkcija preoblikuje (glede na to, da ne dodajamo novih funkcij), se razume, da mora biti po opravljenih zahtevanih spremembah večina funkcionalnosti za končnega uporabnika enaka.

  • Kot preizkuševalec se refaktoriranje kode približno prevede v = poglobljeno testiranje + regresijsko testiranje. Poglobljeno testiranje mora vključevati vse obstoječe tokove uporabnikov, da se zagotovi, da vse funkcije delujejo kot prej. Regresijsko testiranje celotne aplikacije (ali prizadetih območij), da se zagotovi, da nadgradnja modula nenamerno ne bo prekinila funkcionalnosti drugih modulov.
  • Pomembni bodo preskusi sprejemljivosti uporabnikov, ki jih je treba opraviti, preden je mogoče gradnjo razglasiti za pripravljeno za izdajo.
  • Poleg tega kateri koli drug zahtevan test, kot so preskusi obremenitve, preskus varnosti itd. bi bilo treba izvajati tudi po potrebi.

# 3) Inženirji za avtomatizacijo

Refaktoriranje kode lahko povzroči odpoved funkcionalnih in nefunkcionalnih skriptov za avtomatizacijo.

To se lahko zgodi iz naslednjih razlogov:

  • Če se predmeti strani spremenijo kot del napora za preoblikovanje in če se vaši skripti za avtomatizacijo Selenium zanašajo na predmete strani, potem skripti ne bodo uspeli in jih bo treba posodobiti.
  • Če bi prišlo do manjših sprememb, potem preusmeri tiste, ki so bili dodani ali odstranjeni med preoblikovanjem, obstoječi skripti za avtomatizacijo pa ne bi uspeli in jih je treba posodobiti

Priporočljivo je, da se preskusi funkcionalne avtomatizacije nastavijo šele, ko je funkcija stabilna, saj bo v nasprotnem primeru med razvojem funkcije veliko predelanih.

Ker so razvijalci testov za avtomatizacijo, morajo tudi inženirji za avtomatizacijo razmišljati kot razvijalec in si prizadevati ustvariti čisto in enostavno vzdrževano kodo. Večina IDE-jev, kot so IntelliJ IDEA, Eclipse itd., Vključuje vgrajen meni za preoblikovanje s pogosto uporabljenimi načini predelave za lažje sklicevanje.

Spodaj je posnetek zaslona menija za refaktoring v IntelliJ IDEA (izdaja skupnosti).

kako predvajate swf datoteke

meni za refaktoriranje

# 4) Za testne potencialne stranke / QA potencialne stranke

  • Morda bodo potrebni testni potencialni kupci / voditelji za zagotavljanje kakovosti, da bodo skupaj s preostalimi člani skupine, vključno z razvijalci, analitikom izdelkov in morda celo zainteresiranimi stranmi, zagotovili skrbno načrtovanje testov za takšne projekte.
  • Pomembno je razumeti obstoječo funkcionalnost. Na podlagi obstoječe funkcionalnosti je treba dokumentirati poslovne primere, pretoke uporabnikov in teste sprejemljivosti uporabnikov. Ko se preskuša predelana koda, je treba vse te scenarije potrditi, skupaj z regresijskim preskušanjem prizadetih območij.
  • Bodite proaktivni med načrtovanjem testnega pristopa in preskusni načrti . Če predvidevate potrebo po več testnih okoljih ali novih testnih orodjih, pošljite zahtevek zgodaj, da preprečite kakršne koli zamude po začetku preizkusne faze.
  • Ne oklevajte in vključite člane ne-projektne skupine ali končne uporabnike, da prispevajo k testiranju.

Študije primerov

Zdaj bomo razpravljali o nekaterih resničnih študijah primerov, pri katerih sem imel priložnost delati neposredno ali posredno prispevati.

Študija primera št. 1

Naloga: Refaktorirajte modul, da bo trdo kodirane vrednosti zamenjal s spremenljivkami, in dodajte komentarje za novo orodje za avtomatizirano ustvarjanje tehnične dokumentacije.

Izzivi :Brez večjih izzivov. Modul je bil nov, imel je dokumentirane funkcionalne zahteve in zahteve za sprejem uporabnikov, uporabniške tokove in testne primere. Enotni testi so bili postavljeni med samim začetkom lansiranja.

Preskusni pristop :Izvedeni so bili testni primeri za modul, ki je bil obnovljen, in relativno znana prizadeta območja. Morebitne napake so bile sporočene in odpravljene pred izdajo.

Študija primera št

Naloga :Reformirajte obstoječi shranjeni postopek, da olajšate razširitev aplikacije.

Shranjena procedura v tem scenariju je bila starejša shranjena procedura, ki je bila zasnovana pred nekaj leti, ob upoštevanju zahteve, da je aplikacija uporabljala svoj shranjeni postopek kot interno aplikacijo z manj kot 10 sočasnimi sejami.

Zdaj je podjetje želelo to aplikacijo tržiti kot programsko opremo kot storitev (SaaS), s pričakovanim obsegom 300 sočasnih sej na začetku.

Skupina je opravila nekaj začetnih testov obremenitve in ugotovila, da se sistem zlomi z obremenitvijo 25 sočasnih sej. Skupina je pregledala kodo in priporočila predelavo enega obstoječega jedrnega shranjenega postopka, ki bi aplikaciji omogočil razširitev in podporo do 500 sočasnih sej brez prekinitve.

Nekatere težave, opredeljene s tem shranjenim postopkom, so bile več podpoizvedb znotraj ene poizvedbe, težka združevanja s pogledi namesto tabel, uporaba select * namesto izbire določenega stolpca itd. Zaradi teh težav s kodiranjem je aplikacija pridobivala več podatkov kot tisti je bila res potrebna, s čimer se je aplikacija upočasnila in sčasoma zrušila.

Izzivi:

# 1) Vodja projekta / analitik izdelkov

  • Zbiranje zahtev - Ker je bila ta shranjena procedura starejša koda, zanjo ob prvem načrtovanju ni bilo dokumentiranih zahtev. Tudi za ponovitve, opravljene v zadnjih nekaj letih, ni bilo dnevnika sprememb, ki bi navajal poslovna pravila in logiko, dodane ali odstranjene iz modula.
  • Urnik projekta - Ker zahteve niso bile jasno opredeljene in odvisnosti od kode še niso bile popolnoma opredeljene, je bilo težko sporočiti okvirni urnik.

# 2) Za razvijalce

  • Pomanjkanje jasnih zahtev in poslovnih pravil.
  • Čiščenje kode brez izgube njene funkcionalnosti.
  • Neznana prizadeta območja in / ali odvisnosti kode.
  • Ne morem zagotoviti konkretnih ocen časa razvoja.
  • Treba je ustvariti nove enote.

# 3) Za preizkuševalce

  • Pomanjkanje jasnih zahtev in poslovnih pravil vpliva na načrtovanje preskusov.
  • Načrtovanje preskusov vplivov na neznana prizadeta območja, zlasti za regresijske teste.
  • Konkretnih ocen preskusov ni mogoče predložiti.

# 4) Zainteresirane strani

  • Pomanjkanje jasnih dokumentiranih zahtev in / ali tokov uporabnikov + kratki roki = Večja nevarnost okvare.

Pristop, ki ga je sledila ekipa za ublažitev tveganj in reševanje izzivov :

(i) Skupina je sledila skupnemu pristopu pri zbiranju zahtev : Vodja projekta / analitik in preizkuševalci izdelkov so tesno sodelovali z notranjimi končnimi uporabniki, da bi razumeli in dokumentirali glavno funkcionalnost in tok uporabnikov.

Razvijalci so tudi pregledali kodo in v dokument z zahtevami dodali ustrezne informacije. To je bilo storjeno pred začetkom šprinta.

(ii) Nadomestno testno okolje je bilo ustvarjeno za preizkušanje spremembe, ki se izvaja : Omenjena okolja poimenujmo kot Gamma in Phi. Gamma bi imela staro kodo, Phi pa bi imel ves čas nameščen najnovejši preoblikovan shranjeni postopek.

Vzporedno dve testni okolji, ki sta se skoraj poustvarili pred pristopom in po njem, sta ekipi omogočili bolj poglobljeno in raziskovalno testiranje s primerjavo vedenja v teh dveh testnih okoljih, zato so lahko prepoznali verjetne napake.

Ekipa je zagotovila zahteve za nadomestno testno okolje, ki je bilo zagotovljeno pred datumom začetka šprinta.

(iii) Končni uporabniki in zainteresirane strani, ki so že zgodaj vključene v preskušanje : Vse očitne težave so bile odkrite in o njih so poročali že zgodaj, da so ekipi omogočili več časa za razmestitev in preizkus zahtevanega popravka.

(iv) Določitev meril za izstop in upoštevanje le-teh: Merila za izhod so bila določena v začetnih fazah načrtovanja - testirano je bilo 80% uporabniških tokov, nobena kritična napaka ni bila odpravljena, predstavitev in odjava zainteresiranih strani pred sprostitvijo.

(v) Določitev okvirnega datuma izdaje: Določitev datuma izida poravnana in motiviranje ekipe za delo v smeri skupne končne točke. Glede na obseg projekta je ekipa priporočila, da se namesto običajnega dvotedenskega sprinta sledi 3-tedenskemu šprintu, da se ekipi omogoči dovolj časa za izvedbo projekta.

Zaključek

Če povzamemo, refaktoriranje kode je postopek čiščenja / poenostavitve zasnove modula brez spreminjanja njegove funkcionalnosti. Postopek refaktoriziranja je lahko preprost, na primer dodajanje komentarjev, dodajanje pravilnih zamikov, odstranjevanje statične spremenljivke itd. Ali pa je zapleten za zapletene stare sisteme.

Morda bo treba določen modul ali kos kode spremeniti zaradi vonjev kode, tehničnega dolga ali z uporabo agilnega pristopa k razvoju programske opreme.

Za preizkuševalce se refaktoriranje kode približno prevede v = poglobljeno testiranje + regresijsko testiranje.

Potrebno je poglobljeno testiranje, da se preverijo vsi obstoječi tokovi uporabnikov, da se preveri, ali vse funkcije delujejo kot prej. Potrebno je regresijsko testiranje celotne aplikacije (ali prizadetih območij), da zagotovite, da nadgradnja modula nenamerno ni prekinila funkcionalnosti drugih modulov.

Morda bodo morda potrebni testni potencialni kupci / vodila za zagotavljanje kakovosti za sodelovanje z ostalimi člani skupine, vključno z razvijalci, analitikom izdelkov, zlasti za starejše projekte. Pri načrtovanju preskusnega pristopa in načrtov preskusov bodite proaktivni. Če predvidevate potrebo po več testnih okoljih ali novih testnih orodjih, prosimo, da zahtevek zgodaj pošljete, da preprečite zamude, ko se začne testna faza.

O avtorju: To informativno vadnico je napisala Neha B. Trenutno dela kot vodja zagotavljanja kakovosti in je specializirana za vodenje in upravljanje internih in zunanjih služb za zagotavljanje kakovosti.

Ste že delali na zahtevnem projektu, ki je vključeval predelavo kode ali modula / aplikacije? Če je odgovor pritrdilen, lahko svoje izkušnje delite s svojimi izkušnjami v razdelku s komentarji, na katerih se bodo lahko naučili naši kolegi preizkuševalci.

Priporočeno branje

^