Meny

Code Refactoring: Vad du behöver veta om det

code refactoring what you need know about it

Prova Vårt Instrument För Att Eliminera Problem

Förstå kodrefaktoring: En testares perspektiv

Termen ”Refactoring” används främst för att indikera nödvändig kodrensning / redesign.

I denna handledning kommer vi att förstå definitionen av refactoring, diskutera behovet av kodrefactoring och granska effekterna av refactoring-kod på olika projektmedlemmar. Vi kommer också att diskutera svaret på den viktigaste frågan - Som testare, varför behöver du veta om refactoring?

Dessutom kommer vi också att diskutera några fallstudier för att klargöra konceptet.

Kodreformering

Vad du kommer att lära dig:

Introduktion till refactoring

Till att börja med, låt oss först förstå vad refactoring egentligen är.

Refactoring är i huvudsak en praxis eller process för att förbättra koden och / eller databasen med bibehållen befintlig funktionalitet. Tanken är att omvandla ineffektiv och överkomplicerad kod till mer effektiv, helst enklare och enklare kod.

Refactoring av kod har också fått fart med fler team nu genom att följa Agile Software Development-metoden. Projektgrupper har ofta begränsad tid att implementera nya eller utöka funktionerna hos de befintliga funktionerna och koden som är ren. Koden som är lätt att förstå och underhålla går verkligen långt för att uppfylla iterationsfristen.

Behov av kodomformning

Om vi ​​behåller den ursprungliga funktionaliteten i applikationen eller modulen, uppstår en fråga som varför bryr vi oss om att omforma? Det finns många orsaker till att en viss modul eller kod kan behöva omformuleras, som:

  1. Koden luktar
  2. Teknisk skuld
  3. Agil programvaruutvecklingsmetod, etc.

Vi kommer att diskutera dessa punkter i detalj i följande avsnitt.

# 1) Kod luktar:

Vi kan alla förstå att när maten börjar lukta indikerar det att det troligtvis blir dåligt - detta gäller också för kod! Kodlukt är en indikation på att det kan finnas ett mycket allvarligt problem i koden.

Följande är några vanliga kodluktar:

  • Förekomst av överflödig eller identisk kod.
  • En deklarerad variabel som inte används någonstans i resten av koden.
  • Överkomplicerad koddesign.
  • Kodklass som gör för lite och inte motiverar förekomsten av den definierade klassen. Sådana klasser är kända som lat klass eller freeloader.
  • Förekomsten av för många förhållanden och slingor som har potential att brytas ner och förenklas.
  • Kodbyggnad på ett sätt som en ändring av en del av koden kräver att ändringen också implementeras på andra platser.

Kodlukt blir tydligare med tiden. När applikationen eller systemet växer så småningom börjar dessa kodluktar påverka kodutveckling, underhåll och till och med systemets prestanda i extrema scenarier.

# 2) Teknisk skuld:

Under utvecklingen av en programvara kan vi ofta ta genvägar för att uppnå önskade resultat under den begränsade tiden och tillgängliga resurser.

Tänk på en funktion som måste läggas till i en befintlig modul. Efter diskussionen begränsar teamet två metoder för att lägga till den här funktionen. Tillvägagångssätt A, tar två sprints att leverera, kommer att vara den godkända långsiktiga metoden. Tillvägagångssätt B tar bara 5 dagar att leverera är ett rörigt hårdkodat hack som är utformat för att bara serva modulen på kort sikt.

Om teamet är under press att leverera funktionen inom en begränsad tid kan de komma överens om att följa metod B för nu och lägga till metod A i eftersläpningen för framtiden. Genom att göra detta skapade detta team bara den tekniska skulden för sig själva.

Enkelt uttryckt hänvisar teknisk skuld inom mjukvaruutveckling till den extra omarbetning eller allmänna omkostnader som krävs för att få rätt lösningar på plats eller göra saker på rätt sätt.

Legacy Systems tenderar att förvärva enorma tekniska skulder över tiden vilket i sin tur kan göra applikationen mottaglig för misslyckande och svår att stödja och underhålla.

Läs mer=> Vad är teknisk avdelning

# 3) Efter Agile Software Development Approach:

Agil programvaruutvecklingsstrategi förespråkar stegvis utveckling. Utan ren, välstrukturerad och lätt att underhålla kod skulle det inte vara möjligt för team att utöka den befintliga koden med varje iteration. Om koden ändras utan korrekt refactoring kan det bidra till kodlukt eller teknisk skuld.

Detta förhållande visas i diagrammet nedan

Agil mjukvaruutvecklingsmetod

Rekommenderad läsning => De bästa kodanalysverktygen

Varför behöver en kvalitetsbedömning veta om refactoring?

Oavsett vad vi hittills diskuterade i den här handledningen verkar det vara relaterat till kodning och ser ut som den typ av saker som en utvecklare borde oroa sig för.

Varför diskuterar vi sedan detta icke-relaterade koncept i Software Testing Help Community? Fortsätt läsa resten av denna handledning för svaret på den här frågan.

# 1) För enhetstestare / utvecklare

När koden omaktiveras när ny kod införs uppdateras gamla klasser, nya klasser läggs till och befintliga enhetstester kan nu misslyckas. Dessutom, för äldre system kan det hända att inga enhetstester implementeras alls. De här nya enhetstesterna måste skapas och ställas in från grunden i de flesta fall.

# 2) För testare

När en funktion ombyggs (med tanke på att vi inte lägger till någon ny funktionalitet) är förståelsen att efter de nödvändiga ändringarna ska en majoritet av funktionaliteten för slutanvändaren förbli densamma.

  • Som en testare översätter refactoring av kod ungefär till = djupgående tester + regressionstester. Djupgående tester måste inkludera alla befintliga användarflöden för att säkerställa att alla funktioner fungerar som tidigare. Regressionstestning av hela applikationen (eller påverkade områden) krävs för att säkerställa att uppgradering av en modul inte oavsiktligt bröt funktionerna hos de andra modulerna.
  • Användaracceptansprov kommer att vara viktiga och dessa test måste godkännas innan byggnaden kan förklaras redo att släppas.
  • Dessutom krävs alla andra test som belastningstester, säkerhetstest etc. måste också genomföras efter behov.

# 3) Automationstestingenjörer

Omkodning av kod kan orsaka att funktionella och icke-funktionella automatiseringsskript misslyckas.

Detta kan uppstå på grund av följande skäl:

  • Om sidobjekten ändras som en del av refactoring-ansträngningen och om dina Selen-automatiseringsskript är beroende av sidobjekten, kommer skripten att misslyckas och måste uppdateras.
  • Om det fanns mindre ändringar omdirigeras de som läggs till eller tas bort under refactoring, och befintliga automatiseringsskript skulle misslyckas och måste uppdateras

Det rekommenderas att funktionella automatiseringstest endast ska ställas in när en funktion är stabil, annars kommer det att resultera i mycket omarbetning när funktionen utvecklas.

För att vara utvecklare av automatiseringstester måste automatiseringstestingenjörer tänka som en utvecklare och sträva efter att skapa en ren och lätt att underhålla kod. De flesta av IDE: s som IntelliJ IDEA, Eclipse etc., inkluderar inbyggd refactoring-meny med vanliga refactoring-metoder för enkel referens.

Nedan finns en skärmdump av refactoring-menyn i IntelliJ IDEA (Community Edition).

whitebox och blackbox testning med exempel

menyn för refactoring

# 4) För testledningar / kvalitetsledningar

  • Testledningar / QA-ledningar kan krävas för att arbeta tillsammans med resten av teamet inklusive utvecklare, produktanalytiker och kanske till och med intressenter för att säkerställa att testplanering för sådana projekt görs noggrant.
  • Det är viktigt att förstå den befintliga funktionaliteten. Baserat på befintlig funktionalitet måste affärsfall, användarflöden och användaracceptstester dokumenteras. När en ombyggd kod testas måste alla dessa scenarier valideras, tillsammans med regressionstestning av de drabbade områdena.
  • Var proaktiv när du planerar testmetoden och testplaner . Om du förutser kravet på flera testmiljöer eller nya testverktyg, vänligen skicka rekvisitionen tidigt för att förhindra förseningar när testfasen startar.
  • Tveka inte att involvera icke-projektmedlemmar eller slutanvändare att bidra till testningen.

Fallstudier

Vi kommer nu att diskutera några verkliga fallstudier där jag fick möjlighet att antingen arbeta direkt eller bidra till indirekt.

Fallstudie nr 1

Uppgift: Omforma en modul för att ersätta de hårdkodade värdena med variabler och lägga till kommentarer för det nya automatiska genereringsverktyget för teknisk dokumentation.

Utmaningar :Inga stora utmaningar. Modulen var ny, hade dokumenterade funktionella krav och acceptanskrav, användarflöden och testfall. Enhetstester skapades under själva den första lanseringen.

Testmetod :Testfallet för modulen som ombyggdes och de relativt kända påverkade områdena utfördes. Eventuella brister rapporterades och löstes före släppet.

Fallstudie # 2

Uppgift :Omforma befintligt lagrat förfarande för att underlätta uppskalning av applikationen

Den lagrade proceduren i detta scenario var en äldre lagrad procedur som utformades för några år sedan, med tanke på kravet att applikationen använde sin lagrade procedur som en intern applikation med mindre än tio samtidiga sessioner.

Nu ville företaget marknadsföra denna applikation som en Software as a Service (SaaS), med den förväntade volymen på 300 samtidiga sessioner initialt.

Teamet gjorde några inledande belastningstester och drog slutsatsen att systemet bryts med en belastning på 25 samtidiga sessioner. Teamet granskade koden och rekommenderade ombyggnad av en befintlig kärnlagrad procedur som gör det möjligt för applikationen att skala upp och stödja upp till 500 samtidiga sessioner utan att bryta.

Några problem som identifierats med den här lagrade proceduren var flera underfrågor inom en enda fråga, tunga sammanfogningar med vyer istället för tabeller, användning av select * istället för att välja en specifik kolumn, etc. På grund av dessa kodproblem hämtade applikationen mer data än den var verkligen nödvändigt, vilket fick applikationen att sakta ner och så småningom krascha.

Utmaningar:

# 1) Projektledare / produktanalytiker

  • Kravsamling - Eftersom denna lagrade procedur var en äldre kod fanns det inga dokumenterade krav för den när modulen först designades. Även för de iterationer som gjorts under de senaste åren fanns det ingen ändringslogg för att ange affärsregler och logik som lagts till eller tagits bort från modulen.
  • Projekt schema - Eftersom kraven inte var tydligt definierade och kodberoende ännu inte identifierades helt var det svårt att kommunicera det preliminära schemat.

# 2) För utvecklare

  • Brist på tydliga krav och affärsregler.
  • Rengöring av koden utan att förlora dess funktionalitet.
  • Okända påverkade områden och / eller kodberoenden.
  • Det går inte att ge uppskattningar av konkret utvecklingstid.
  • Behöver skapa nya enhetstester.

# 3) För testare

  • Brist på tydliga krav och affärsregler påverkar testplaneringen.
  • Okända påverkade områden påverkar testplanering, speciellt för regressionstester.
  • Det går inte att tillhandahålla konkreta testuppskattningar.

# 4) Intressenter

  • Brist på tydliga dokumenterade krav och / eller användarflöden + snäva deadlines = Högre risk för fel.

Den strategi som teamet följer för att mildra risker och arbeta kring utmaningarna :

(i) Teamet följde en samarbetsmetod för att samla krav : Projektledare / produktanalytiker och testare arbetade nära med de interna slutanvändarna för att förstå och dokumentera de viktigaste funktionerna och användarflödet.

Utvecklare granskade också koden och lade till relevant information i kravdokumentet. Detta gjordes före sprintens startdag.

(ii) Den alternativa testmiljön skapades för att testa den förändring som implementeras : Låt oss kalla dessa miljöer som Gamma och Phi. Gamma skulle ha den gamla koden och Phi skulle ha den senaste ombyggda lagrade proceduren distribuerad hela tiden.

Att ha två testmiljöer parallellt, nästan återskapa före - och - efter tillvägagångssätt, gjorde att teamet kunde göra mer djupgående och utforskande tester genom att jämföra beteendet i dessa 2 testmiljöer, de kunde identifiera de troliga buggarna.

Teamet tillhandahöll kraven för en alternativ testmiljö som tillhandahölls före sprintens startdatum.

(iii) Slutanvändare och intressenter som är involverade i testning tidigt : Eventuella uppenbara problem upptäcktes och rapporterades tidigt vilket gav mer tid för teamet att distribuera och testa den nödvändiga åtgärden.

(iv) Definiera utgångskriterier och följa det: Utgångskriterier definierades i de inledande planeringsfaserna - 80% användarflöden testades, inget kritiskt fel olöst, demo och avloggning från intressenterna innan de släpptes.

(v) Ställa in ett preliminärt släppdatum: Ange ett släppdatum anpassat och motivera teamet att arbeta mot en gemensam slutpunkt. Baserat på projektets omfattning rekommenderades teamet att en 3-veckors sprint följs istället för en vanlig 2-veckors sprint för att ge tillräckligt med tid för teamet att genomföra projektet.

Slutsats

Sammanfattningsvis är omformning av kod en process för att rengöra / förenkla designen av en modul utan att ändra dess funktionalitet. Refactoring-processen kan vara enkel, som att lägga till kommentarer, lägga till korrekt indrag, ta bort en statisk variabel, etc. eller kan vara komplicerad för komplexa äldre system.

En viss modul eller kod kan behöva omformuleras på grund av kodlukt, teknisk skuld eller genom att följa en smidig programvaruutvecklingsstrategi.

För testare översätter refaktorisering av kod ungefär till = djupgående tester + regressionstester.

Fördjupningstestning krävs för att testa alla befintliga användarflöden för att säkerställa om alla funktioner fungerar som tidigare. Regressionstestning av hela applikationen (eller berörda områden) krävs för att säkerställa att uppgradering av en modul inte oavsiktligt bröt funktionerna hos de andra modulerna.

Testledningar / kvalitetsledningar kan krävas för att arbeta tillsammans med resten av teamet inklusive utvecklare, produktanalytiker speciellt för äldre projekt. Var proaktiv när du planerar testmetoden och testplanerna. Om du räknar med kravet på flera testmiljöer eller nya testverktyg, vänligen skicka rekvisitionen tidigt för att förhindra förseningar när testfasen startar.

Om författaren: Denna informativa handledning är skriven av Neha B. Hon arbetar för närvarande som kvalitetssäkringschef och är specialiserad på ledning och ledning av interna och offshore kvalitetsgrupper.

Har du arbetat med ett utmanande projekt som innebar omformning av kod eller en modul / applikation? Om ja, berätta gärna dina erfarenheter i kommentarfältet så att våra medtestare kan lära av.

Rekommenderad läsning

^