Menu

Code Refactoring: Hvad du behøver at vide om det

code refactoring what you need know about it

Prøv Vores Instrument Til At Fjerne Problemer

Forståelse af kode refactoring: En testers perspektiv

Udtrykket 'Refactoring' bruges hovedsageligt til at angive den nødvendige kodeoprydning / redesign.

I denne vejledning vil vi forstå definitionen af ​​refactoring, diskutere behovet for code refactoring og gennemgå indvirkningen af ​​refactoring code på forskellige projektmedlemmer. Vi vil også diskutere svaret på det vigtigste spørgsmål - Som tester, hvorfor har du brug for at vide om refactoring?

Derudover vil vi også diskutere et par casestudier for at afklare begrebet.

Kode refactoring

Hvad du lærer:

Introduktion til refactoring

Til at begynde med, lad os først forstå, hvad egentlig refactoring er.

Refactoring er i det væsentlige en praksis eller proces med at forbedre koden og / eller databasen, samtidig med at den eksisterende funktionalitet opretholdes. Ideen er at omdanne ineffektiv og den overkomplicerede kode til mere effektiv, helst enklere og lettere kode.

Refactoring af kode har også fået fart med flere hold nu ved at følge Agile Software Development tilgangen. Projektgrupper har ofte begrænset tid til at implementere nye eller udvide funktionaliteten af ​​de eksisterende funktioner og kode, der er ren. Koden, der er let at forstå og vedligeholde, går bestemt langt i at overholde iterationsfristen.

Behov for kodeomdannelse

Hvis vi opretholder den oprindelige funktionalitet i applikationen eller modulet, opstår der et spørgsmål om, hvorfor gider vi endda refactoring? Der er mange grunde til, at et bestemt modul eller et stykke kode muligvis skal omformuleres, som:

  1. Kode lugter
  2. Teknisk gæld
  3. Agil softwareudviklingsmetode osv.

Vi vil diskutere disse punkter i detaljer i de følgende afsnit.

# 1) Kodelugt:

Vi kan alle forstå, at når maden begynder at lugte, indikerer det, at den sandsynligvis bliver dårlig - dette gælder også for kode! Kodelugt er tegn på, at der kan være et meget alvorligt problem i koden.

Følgende er nogle almindelige kodelugt:

  • Tilstedeværelse af overflødig eller identisk kode.
  • En erklæret variabel, der ikke bruges overalt i resten af ​​koden.
  • Overkompliceret kodedesign.
  • Kodeklasse, der gør for lidt og ikke retfærdiggør eksistensen af ​​den definerede klasse. Sådanne klasser er kendt som doven klasse eller freeloader.
  • Eksistensen af ​​for mange forhold og sløjfer, der har potentialet til at blive brudt ned og forenklet.
  • Kodebyggelse på en måde, som en ændring i en del af koden kræver, at ændringen også implementeres andre steder.

Kodelugt bliver tydeligere med tiden der går. Efterhånden som applikationen eller systemet vokser, begynder disse kodelugt til sidst at påvirke kodeudviklingen, vedligeholdelsen og endda systemets ydeevne i ekstreme scenarier.

# 2) Teknisk gæld:

Mens vi udvikler en software i den begrænsede tid og de tilgængelige ressourcer, kan vi ofte tage genveje for at opnå de ønskede resultater.

Overvej en funktion, der skal føjes til et eksisterende modul. Efter diskussion indsnævrer holdet to tilgange for at tilføje denne funktion. Fremgangsmåde A, tager 2 sprints at levere, vil være den godkendte langsigtede tilgang. Metode B tager kun 5 dage at levere er et rodet hårdkodet hack, der er designet til kun at servicere modulet på kort sigt.

Hvis holdet er under pres for at levere funktionen inden for en begrænset periode, kan de muligvis blive enige om at følge tilgang B indtil videre og tilføje tilgang A i efterslæbet for fremtiden. Ved at gøre dette skabte dette team netop den tekniske gæld for sig selv.

Enkelt sagt henviser teknisk gæld til softwareudvikling til den ekstra omarbejdning eller overhead, der kræves for at få de rette rettelser på plads eller gøre tingene på den 'rigtige måde'.

Legacy Systems har tendens til at erhverve enorm teknisk gæld over tid, hvilket igen kan gøre applikationen modtagelig for fiasko og vanskelig at understøtte og vedligeholde.

Læs mere=> Hvad er teknisk afdeling

# 3) Efter Agile Software Development Approach:

Agil softwareudviklingsmetode fortaler for trinvis udvikling. Uden ren, velstruktureret og let at vedligeholde kode ville det ikke være muligt for hold at udvide den eksisterende kode med hver iteration. Hvis koden ændres uden ordentlig refactoring, kan den bidrage til kodelugt eller teknisk gæld.

Dette forhold er afbildet i nedenstående diagram

Agil softwareudviklingsmetode

Anbefalet læsning => Top kode analyseværktøjer

Hvorfor skal en kvalitetssikring vide om refactoring?

Uanset hvad vi hidtil diskuterede i denne vejledning ser det ud til at være relateret til kodning og ligner den slags ting, som en udvikler skal bekymre sig om.

Hvorfor diskuterer vi så dette ikke-relaterede koncept i Software Testing Help Community? Fortsæt med at læse resten af ​​denne vejledning for at få svaret på dette spørgsmål.

# 1) For enhedstestere / udviklere

Mens refactoring af koden, når der indsættes ny kode, opdateres gamle klasser, nye klasser tilføjes, og eksisterende enhedstest kan nu mislykkes. Derudover er der muligvis ikke implementeret enhedstests overhovedet for ældre systemer. Denne nye enhedstest skal i de fleste tilfælde oprettes og oprettes fra bunden.

# 2) For testere

Når en funktion refaktureres (i betragtning af at vi ikke tilføjer nogen ny funktionalitet), er forståelsen, at efter at de krævede ændringer er udført, skal størstedelen af ​​funktionaliteten for slutbrugeren forblive den samme.

  • Som tester oversættes refactoring af kode groft til = dybtgående test + regressionstest. Dybtgående test skal omfatte alle eksisterende brugerstrømme for at sikre, at alle funktioner fungerer som før. Regressionstest af hele applikationen (eller de berørte områder) kræves for at sikre, at opgradering af et modul ikke utilsigtet ødelagde funktionaliteten af ​​de andre moduler.
  • Test af brugeraccept vil være vigtig, og disse tests skal bestås, før build kan erklæres klar til frigivelse.
  • Derudover kræves enhver anden test som belastningstest, sikkerhedstest osv. skal også implementeres efter behov.

# 3) Automatiseringstestingeniører

Refactoring af kode kan medføre, at funktionelle og ikke-funktionelle automatiseringsscripts mislykkes.

Dette kan forekomme af følgende årsager:

  • Hvis sideobjekterne ændres som en del af refactoring-indsatsen, og hvis dine Selenium-automatiseringsscripts er afhængige af sideobjekterne, mislykkes scriptsne og skal opdateres.
  • Hvis der var mindre ændringer, omdirigerer den dem, der blev tilføjet eller fjernet under refactoring, og eksisterende automatiseringsscripts ville mislykkes og skulle opdateres

Det anbefales, at de funktionelle automatiseringstest kun skal oprettes, når en funktion er stabil, ellers vil det resultere i en masse omarbejde, når funktionen udvikler sig.

At være udvikler af automatiseringstest, skal automatiseringstestingeniører også tænke som en udvikler og sigte mod at skabe en ren og let at vedligeholde kode. De fleste af IDE'erne som IntelliJ IDEA, Eclipse osv. Inkluderer indbygget refactoring-menu med almindeligt anvendte refactoring-metoder til nem reference.

Nedenfor er et screenshot af refactoring-menuen i IntelliJ IDEA (Community Edition).

html-spørgsmål og svar til nybegyndere

menu til refactoring

# 4) For testledninger / QA-ledninger

  • Test Leads / QA Leads kan være påkrævet for at arbejde sammen med resten af ​​teamet inklusive udviklere, produktanalytikere og måske endda interessenter for at sikre, at testplanlægning for sådanne projekter udføres omhyggeligt.
  • Det er vigtigt at forstå den eksisterende funktionalitet. Baseret på den eksisterende funktionalitet skal business cases, brugerflow og brugeracceptstest dokumenteres. Når en refactored kode testes, skal alle disse scenarier valideres sammen med regressionstest af de berørte områder.
  • Vær proaktiv, mens du planlægger testmetoden og testplaner . Hvis du forventer kravet om flere testmiljøer eller nye testværktøjer, skal du sende rekvisitionen tidligt for at forhindre forsinkelser, når testfasen starter.
  • Tøv ikke med at involvere ikke-projektmedlemmer eller slutbrugere til at bidrage til testning.

Casestudier

Vi vil nu diskutere nogle virkelige casestudier, hvor jeg havde mulighed for enten at arbejde direkte på eller bidrage til indirekte.

Casestudie nr. 1

Opgave: Omformuler et modul for at erstatte de hårdkodede værdier med variabler og tilføje kommentarer til det nye automatiserede værktøj til generering af teknisk dokumentation.

Udfordringer :Ingen store udfordringer. Modulet var nyt, havde dokumenteret funktionelle krav og brugeracceptkrav, brugerflow og testcases. Enhedstest blev oprettet under selve den første lancering.

Test tilgang :Testkasserne for modulet, der ombygges, og de relativt kendte påvirkede områder blev udført. Eventuelle mangler blev rapporteret og løst inden frigivelsen.

Casestudie nr. 2

Opgave :Omdefiner den eksisterende lagrede procedure for at lette applikationsskalering.

Den lagrede procedure i dette scenarie var en ældre lagret procedure, der blev designet for et par år siden, idet kravet om, at applikationen brugte sin lagrede procedure som en intern applikation med mindre end 10 samtidige sessioner i betragtning.

Nu ønskede virksomheden at markedsføre denne applikation som en Software as a Service (SaaS) med det forventede volumen på 300 samtidige sessioner i første omgang.

Holdet lavede nogle indledende belastningstest og konkluderede, at systemet bryder med en belastning på 25 samtidige sessioner. Holdet gennemgik koden og anbefalede omlægning af en eksisterende kernelagret procedure, der gør det muligt for applikationen at skalere op og understøtte op til 500 samtidige sessioner uden at bryde.

Nogle problemer identificeret med denne lagrede procedure var flere underforespørgsler inden for en enkelt forespørgsel, tunge sammenføjninger med visninger i stedet for tabeller, brug af select * i stedet for at vælge en bestemt kolonne osv. På grund af disse kodningsproblemer hentede applikationen flere data end den var virkelig nødvendigt, hvilket fik applikationen til at bremse og til sidst gå ned.

Udfordringer:

# 1) Projektleder / produktanalytiker

  • Kravindsamling - Da denne lagrede procedure var en ældre kode, var der ingen dokumenterede krav til den, da modulet blev designet. Også for de gentagelser, der er udført i løbet af de sidste par år, var der ingen ændringslog for at angive forretningsregler og logik tilføjet eller fjernet fra modulet.
  • Projektplan - Da kravene ikke var klart definerede, og kodeafhængigheder endnu ikke var identificeret fuldt ud, var det vanskeligt at kommunikere den foreløbige tidsplan.

# 2) For udviklere

  • Manglende klare krav og forretningsregler.
  • Rengøring af koden uden at miste dens funktionalitet.
  • Ukendte påvirkede områder og / eller kodeafhængigheder.
  • Kan ikke give konkrete estimater for udviklingstid.
  • Brug for at oprette nye enhedstests.

# 3) For testere

  • Manglende klare krav og forretningsregler påvirker testplanlægningen.
  • Ukendte påvirkede områder påvirker testplanlægning, specielt til regressionstest.
  • Kan ikke give konkrete testestimater.

# 4) Interessenter

  • Mangel på klare dokumenterede krav og / eller brugerflow + stramme deadlines = Højere risiko for fiasko.

Den tilgang, som holdet fulgte for at afbøde risici og omgå udfordringerne :

(i) Holdet fulgte en samarbejdsvillig tilgang til at samle krav : Projektleder / produktanalytiker og testere arbejdede tæt sammen med de interne slutbrugere for at forstå og dokumentere den største funktionalitet og brugerflow.

Udviklere gennemgik også koden og tilføjede relevant information til kravsdokumentet. Dette blev gjort inden sprintstartdagen.

(ii) Det alternative testmiljø blev oprettet for at teste den ændring, der implementeres : Lad os kalde disse miljøer som Gamma og Phi. Gamma ville have den gamle kode, og Phi ville have den nyeste refactored lagrede procedure til enhver tid implementeret.

At have to testmiljøer parallelt, næsten genskabe før - og - efter tilgang, tillod holdet at udføre mere dybtgående og udforskende test ved at sammenligne adfærd i disse 2 testmiljøer, de var i stand til at identificere de sandsynlige fejl.

Holdet stillede kravene til et alternativt testmiljø, der blev leveret inden sprintens startdato.

(iii) Slutbrugere og interessenter, der er involveret i test tidligt : Eventuelle åbenlyse problemer blev fanget og rapporteret tidligt, hvilket giver mere tid til teamet til at implementere og teste den nødvendige løsning.

(iv) Definition af exitkriterier og overholdelse af det: Udgangskriterier blev defineret i de indledende planlægningsfaser - 80% testet brugerstrømme, ingen kritisk fejl uløst, demo og afmelding fra interessenterne før frigivelse.

(v) Indstilling af en foreløbig udgivelsesdato: Indstilling af en udgivelsesdato tilpasset og motivering af teamet til at arbejde hen imod et fælles slutpunkt. Baseret på projektets omfang blev det anbefalet af holdet, at en 3-ugers sprint blev fulgt i stedet for en regelmæssig 2-ugers sprint for at give tilstrækkelig tid til holdet til at udføre projektet.

Konklusion

For at opsummere er refactoring af kode en proces til at rense / forenkle designet af et modul uden at ændre dets funktionalitet. Refactoring-processen kan være enkel, som at tilføje kommentarer, tilføje korrekt indrykning, fjerne en statisk variabel osv. Eller kan være kompliceret for komplekse ældre systemer.

Et bestemt modul eller stykke kode skal muligvis ombygges på grund af kodelugt, teknisk gæld eller ved at følge en agil softwareudviklingsmetode.

For testere oversættes refactoring af kode groft til = dybtgående test + regressionstest.

Der kræves dybtgående test for at teste alle eksisterende brugerstrømme for at sikre, om alle funktioner fungerer som før. Regressionstest af hele applikationen (eller påvirkede områder) er påkrævet for at sikre, at opgradering af et modul ikke utilsigtet ødelagde funktionaliteten i de andre moduler.

Test Leads / QA Leads kan være påkrævet for at arbejde sammen med resten af ​​teamet inklusive udviklere, produktanalytiker især til ældre projekter. Vær proaktiv, mens du planlægger testmetoden og testplanerne. Hvis du forventer kravet om flere testmiljøer eller nye testværktøjer, skal du sende rekvisitionen tidligt for at forhindre forsinkelser, når testfasen starter.

Om forfatteren: Denne informative vejledning er skrevet af Neha B. Hun arbejder i øjeblikket som kvalitetssikringschef og er specialiseret i at lede og styre interne og offshore QA-teams.

Har du arbejdet på et udfordrende projekt, der involverede refactoring af kode eller et modul / applikation? Hvis ja, er du velkommen til at dele dine oplevelser i kommentarfeltet, som vores kollegaer kan lære af.

Anbefalet læsning

^