Meny

Code Refactoring: Hva du trenger å vite om det

code refactoring what you need know about it

Prøv Instrumentet Vårt For Å Eliminere Problemer

Forstå kode refactoring: En testers perspektiv

Begrepet 'Refactoring' brukes hovedsakelig for å indikere nødvendig kodeopprydding / redesign.

I denne opplæringen vil vi forstå definisjonen av refactoring, diskutere behovet for code refactoring, og gjennomgå virkningen av refactoring code på ulike prosjektmedlemmer. Vi vil også diskutere svaret på det viktigste spørsmålet - Som tester, hvorfor trenger du å vite om refactoring?

I tillegg vil vi også diskutere noen casestudier for å avklare konseptet.

Kode Refactoring

Hva du vil lære:

Introduksjon til refactoring

Til å begynne med, la oss først forstå hva egentlig refactoring er.

Refactoring er egentlig en praksis eller prosess for å forbedre koden og / eller databasen samtidig som den eksisterende funksjonaliteten opprettholdes. Tanken er å transformere ineffektiv og den overkompliserte koden til mer effektiv, helst enklere og enklere kode.

Refactoring av kode har også fått fart med flere lag nå ved å følge Agile Software Development-tilnærmingen. Prosjektgrupper har ofte begrenset tid til å implementere nye eller utvide funksjonaliteten til de eksisterende funksjonene og koden som er ren. Koden som er lett å forstå og vedlikeholde, går absolutt langt med å oppfylle iterasjonsfristen.

Behov for kodeomdannelse

Hvis vi opprettholder den opprinnelige funksjonaliteten til applikasjonen eller modulen, dukker det opp et spørsmål om hvorfor bryr vi oss om å refakturere? Vel, det er mange grunner til at en bestemt modul eller et stykke kode kan trenge å bli omformet, som:

  1. Koden lukter
  2. Teknisk gjeld
  3. Agil programvareutviklingsmetode osv.

Vi vil diskutere disse punktene i detalj i de følgende avsnittene.

# 1) Kodelukt:

Vi kan alle forstå at når maten begynner å lukte, indikerer det at den mest sannsynlig blir dårlig - dette gjelder også for kode! Kodelukt er indikasjoner på at det kan være et mye alvorlig problem i koden.

Følgende er noen vanlige kodelukter:

  • Tilstedeværelse av overflødig eller identisk kode.
  • En erklært variabel som ikke brukes noe sted i resten av koden.
  • Overkomplisert kodedesign.
  • Kodeklasse som gjør for lite og ikke rettferdiggjør eksistensen av klassen som er definert. Slike klasser er kjent som lat klasse eller freeloader.
  • Eksistensen av for mange forhold og løkker som har potensial til å bli brutt ned og forenklet.
  • Kodebygging på en måte som en endring i en del av koden krever at endringen også implementeres på de andre stedene.

Kodelukt blir tydeligere med tiden. Etter hvert som applikasjonen eller systemet vokser, vil disse kodeluktene til slutt påvirke kodeutviklingen, vedlikeholdet og til og med systemets ytelse i ekstreme scenarier.

# 2) Teknisk gjeld:

Mens vi utvikler en programvare, i den begrensede tiden og ressursene som er tilgjengelige, kan vi ofte ta snarveier for å oppnå de ønskede resultatene.

Vurder en funksjon som må legges til en eksisterende modul. Etter diskusjonen begrenser teamet to tilnærminger for å legge til denne funksjonen. Tilnærming A, tar to sprints å levere, vil være den godkjente langsiktige tilnærmingen. Tilnærming B tar bare fem dager å levere er et rotete hardkodet hack som er designet for å bare betjene modulen på kort sikt.

Hvis teamet er under press for å levere funksjonen innen en begrenset periode, kan de bli enige om å følge tilnærming B for nå og legge til tilnærming A i etterslaget for fremtiden. Ved å gjøre dette skapte dette teamet bare den tekniske gjelden for seg selv.

Enkelt sagt refererer teknisk gjeld i programvareutvikling til den ekstra omarbeidingen eller overhead som kreves for å få de rette løsningene på plass eller gjøre ting på riktig måte.

Legacy Systems har en tendens til å skaffe seg enorm teknisk gjeld over tid, som igjen kan gjøre applikasjonen utsatt for svikt og vanskelig å støtte og vedlikeholde.

Les mer=> Hva er teknisk avd

# 3) Etter Agile Software Development Approach:

Agil programvareutvikling tilnærmer seg for trinnvis utvikling. Uten ren, godt strukturert og enkel å vedlikeholde kode ville det ikke være mulig for team å utvide den eksisterende koden med hver iterasjon. Hvis koden endres uten riktig refactoring, kan det bidra til kodelukt eller teknisk gjeld.

Dette forholdet er avbildet i diagrammet nedenfor

Agile programvareutviklingsmetode

Anbefalt lesing => Topp kode analyseverktøy

Hvorfor trenger en kvalitetssikring å vite om refactoring?

Uansett hva vi diskuterte til nå i denne opplæringen ser ut til å være relatert til koding og ser ut som den typen ting som en utvikler bør bekymre seg for.

Så hvorfor diskuterer vi dette ikke-relaterte konseptet i Software Testing Help Community? Fortsett å lese resten av denne veiledningen for svaret på dette spørsmålet.

# 1) For enhetstestere / utviklere

Mens ny omforming av koden oppdateres, blir nye klasser oppdatert, nye klasser blir lagt til, og eksisterende enhetstester kan nå mislykkes. I tillegg, for eldre systemer, kan det hende at det ikke blir implementert enhetstester i det hele tatt. Disse nye enhetstestene må opprettes og settes opp fra bunnen av i de fleste tilfeller.

# 2) For testere

Når en funksjon ombygges (med tanke på at vi ikke legger til noen ny funksjonalitet), er forståelsen at etter at de nødvendige endringene er gjort, bør et flertall av funksjonaliteten for sluttbrukeren være den samme.

  • Som tester oversettes refactoring av kode omtrent til = grundig testing + regresjonstesting. Grundig testing må inkludere alle eksisterende brukerstrømmer for å sikre at alle funksjoner fungerer som før. Regresjonstesting av hele applikasjonen (eller berørte områder) kreves for å sikre at oppgradering av en modul ikke utilsiktet ødela funksjonaliteten til de andre modulene.
  • Brukeraksepttester vil være viktige, og disse testene må bestås før bygningen kan erklæres klar for utgivelse.
  • I tillegg er enhver annen test som kreves som belastningstester, sikkerhetstest etc. må også implementeres etter behov.

# 3) Automatiseringstestingeniører

Refactoring av kode kan føre til at funksjonelle og ikke-funksjonelle automatiseringsskript mislykkes.

Dette kan oppstå av følgende årsaker:

  • Hvis sideobjektene endres som en del av refactoring-innsatsen, og hvis Selenium-automatiseringsskriptene dine er avhengige av sideobjektene, vil skriptene mislykkes og må oppdateres.
  • Hvis det var mindre endringer, viderekobler den de som ble lagt til eller fjernet under refactoring, og eksisterende automatiseringsskript ville mislykkes og må oppdateres

Det anbefales at funksjonelle automatiseringstester bare settes opp når en funksjon er stabil, ellers vil det resultere i mye omarbeid etter hvert som funksjonen utvikler seg.

Å være en utvikler av automatiseringstester, trenger automatiseringstestingeniører også å tenke som en utvikler og sikte på å skape en ren og enkel å vedlikeholde kode. De fleste av IDE-ene som IntelliJ IDEA, Eclipse etc. inkluderer innebygd refactoring-meny med ofte brukte refactoring-metoder for enkel referanse.

Nedenfor er et skjermbilde av refactoring-menyen i IntelliJ IDEA (Community Edition).

whitebox og blackbox testing med eksempel

refactoring-meny

# 4) For testledninger / QA-ledninger

  • Test Leads / QA Leads kan være nødvendig å samarbeide med resten av teamet, inkludert utviklere, produktanalytikere og kanskje til og med interessenter for å sikre at testplanlegging for slike prosjekter blir gjort nøye.
  • Det er viktig å forstå den eksisterende funksjonaliteten. Basert på eksisterende funksjonalitet, må forretningsdokumenter, brukerflyter og brukeracceptansetester dokumenteres. Når en omformet kode testes, må alle disse scenariene valideres, sammen med regresjonstesting av de berørte områdene.
  • Vær proaktiv mens du planlegger testtilnærmingen og testplaner . Hvis du forventer behovet for flere testmiljøer eller nye testverktøy, må du sende rekvisisjonen tidlig for å forhindre forsinkelser når testfasen starter.
  • Ikke nøl med å involvere ikke-prosjektmedlemmer eller sluttbrukere til å bidra til testing.

Casestudier

Vi vil nå diskutere noen virkelige casestudier der jeg hadde muligheten til å enten jobbe direkte med eller bidra til indirekte.

Casestudie nr. 1

Oppgave: Refactor en modul for å erstatte hardkodede verdier med variabler og legge til kommentarer for nytt automatisert verktøy for generering av teknisk dokumentasjon.

Utfordringer :Ingen store utfordringer. Modulen var ny, hadde dokumentert funksjonelle og brukerakseptkrav, brukerflyter og testtilfeller. Enhetstester ble satt opp under selve den første lanseringen.

Test tilnærming :Testtilfellene for modulen som ble ombygd og de relativt kjente berørte områdene ble utført. Eventuelle mangler ble rapportert og løst før løslatelsen.

Case Study # 2

Oppgave :Refaktorer eksisterende lagret prosedyre for å lette applikasjonsskalering.

Den lagrede prosedyren i dette scenariet var en eldre lagret prosedyre som ble designet for noen år siden, med tanke på kravet om at applikasjonen brukte den lagrede prosedyren som en intern applikasjon med mindre enn ti samtidige økter.

Nå ønsket selskapet å markedsføre denne applikasjonen som en Software as a Service (SaaS), med forventet volum på 300 samtidige økter i utgangspunktet.

Teamet gjorde noen innledende lastetester og konkluderte med at systemet bryter med en belastning på 25 samtidige økter. Teamet gjennomgikk koden og anbefalte å omformere en eksisterende kjernelagret prosedyre som gjør at applikasjonen kan skaleres opp og støtte opptil 500 samtidige økter uten å bryte.

Noen problemer identifisert med denne lagrede prosedyren var flere undersøk innen en enkelt spørring, tunge sammenføyninger med visninger i stedet for tabeller, bruk av select * i stedet for å velge en bestemt kolonne, etc. På grunn av disse kodingsproblemene hentet applikasjonen mer data enn det var virkelig nødvendig, og fikk applikasjonen til å bremse og til slutt krasje.

Utfordringer:

# 1) Prosjektleder / produktanalytiker

  • Kravsamling - Siden denne lagrede prosedyren var en eldre kode, var det ingen dokumenterte krav til den da modulen ble designet. Også for iterasjonene som er gjort de siste årene, var det ingen endringslogg for å indikere forretningsregler og logikk lagt til eller fjernet fra modulen.
  • Prosjektplan - Siden kravene ikke var klart definert og kodeavhengighet ennå ikke var fullstendig identifisert, var det vanskelig å kommunisere den foreløpige tidsplanen.

# 2) For utviklere

  • Mangel på klare krav og forretningsregler.
  • Rengjøring av koden uten å miste funksjonaliteten.
  • Ukjente berørte områder og / eller kodeavhengighet.
  • Kan ikke gi konkrete estimater for utviklingstid.
  • Trenger du å lage nye enhetstester.

# 3) For testere

  • Mangel på klare krav og forretningsregler påvirker testplanlegging.
  • Ukjente påvirkede områder påvirker testplanlegging, spesielt for regresjonstester.
  • Kan ikke gi konkrete testestimater.

# 4) Interessenter

  • Mangel på klare dokumenterte krav og / eller brukerstrømmer + stramme tidsfrister = Høyere risiko for feil.

Tilnærmingen som følges av teamet for å redusere risikoen og omgå utfordringene :

(i) Teamet fulgte en samarbeidende tilnærming for å samle krav : Prosjektleder / produktanalytiker og testere jobbet tett med de interne sluttbrukerne for å forstå og dokumentere den viktigste funksjonaliteten og brukerflyten.

Utviklere gjennomgikk også koden og la til relevant informasjon i kravdokumentet. Dette ble gjort før sprintstartdagen.

(ii) Det alternative testmiljøet ble opprettet for å teste endringen som implementeres : La oss kalle disse miljøene som Gamma og Phi. Gamma ville ha den gamle koden og Phi ville ha den siste ombygde lagrede prosedyren til enhver tid distribuert.

Å ha to testmiljøer parallelt, nesten gjenskape før - og - etter tilnærming, tillot teamet å gjøre mer grundige og utforskende tester ved å sammenligne oppførselen i disse 2 testmiljøene, de var i stand til å identifisere de sannsynlige feilene.

Teamet ga kravene til et alternativt testmiljø som ble gitt før sprintens startdato.

(iii) Sluttbrukere og interessenter som er involvert i testing tidlig : Eventuelle åpenbare problemer ble fanget opp og rapportert tidlig, slik at teamet fikk mer tid til å distribuere og teste den nødvendige løsningen.

(iv) Definere utgangskriterier og overholde det: Utgangskriterier ble definert i de innledende planleggingsstadiene - 80% brukerstrømmer testet, ingen kritisk feil uløst, demo og avmelding fra interessentene før utgivelsen.

(v) Angi en foreløpig utgivelsesdato: Angi en utgivelsesdato justert og motivere teamet til å jobbe mot et felles endepunkt. Basert på omfanget av prosjektet, ble det anbefalt av teamet at en 3-ukers sprint ble fulgt i stedet for en vanlig 2-ukers sprint for å gi tilstrekkelig tid for teamet til å gjennomføre prosjektet.

Konklusjon

For å oppsummere, refactoring av kode er en prosess for å rense / forenkle utformingen av en modul uten å endre funksjonaliteten. Refactoring-prosessen kan være enkel, som å legge til kommentarer, legge til riktig innrykk, fjerne en statisk variabel, etc. eller kan være komplisert for komplekse eldre systemer.

En spesiell modul eller kode kan trenge å bli omformet på grunn av kodelukt, teknisk gjeld eller ved å følge en smidig programvareutviklingsmetode.

For testere oversettes refactoring av kode omtrent til = grundig testing + regresjonstesting.

Det kreves grundig testing for å teste alle eksisterende brukerstrømmer for å sikre at alle funksjoner fungerer som før. Regresjonstesting av hele applikasjonen (eller berørte områder) er nødvendig for å sikre at oppgradering av en modul ikke utilsiktet ødela funksjonaliteten til de andre modulene.

Testledere / kvalitetsledere kan være påkrevd for å samarbeide med resten av teamet, inkludert utviklere, produktanalytiker spesielt for eldre prosjekter. Vær proaktiv mens du planlegger testtilnærmingen og testplanene. Hvis du forventer kravet om flere testmiljøer eller nye testverktøy, må du sende rekvisisjonen tidlig for å forhindre forsinkelser når testfasen starter.

Om forfatteren: Denne informative veiledningen er skrevet av Neha B. Hun jobber for tiden som kvalitetssikringsleder og er spesialisert i å lede og administrere interne og offshore kvalitetslag.

Har du jobbet med et utfordrende prosjekt som involverte refactoring av kode eller en modul / applikasjon? Hvis ja, kan du gjerne dele erfaringene dine i kommentarfeltet slik at andre testere kan lære av det.

Anbefalt lesing

^