Menu

Code refactoring: wat u erover moet weten

code refactoring what you need know about it

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Inzicht in code-refactoring: het perspectief van een tester

De term ‘Refactoring’ wordt voornamelijk gebruikt om de vereiste code-opschoning / herontwerp aan te duiden.

In deze tutorial zullen we de definitie van refactoring begrijpen, de noodzaak van code refactoring bespreken en de impact van refactoring code op verschillende projectteamleden bekijken. We zullen ook het antwoord op de belangrijkste vraag bespreken - Waarom moet u als tester meer weten over refactoring?

Daarnaast zullen we ook enkele case studies bespreken om het concept te verduidelijken.

Code refactoring

Wat je leert:

Inleiding tot refactoring

Laten we om te beginnen eerst begrijpen wat refactoring eigenlijk is.

Refactoring is in wezen een praktijk of proces om de code en / of database te verbeteren met behoud van de bestaande functionaliteit. Het idee is om inefficiënte en te gecompliceerde code om te zetten in efficiëntere, bij voorkeur eenvoudigere en gemakkelijkere code.

Het herstructureren van code heeft nu ook vaart gekregen met meer teams door de Agile Software Development-aanpak te volgen. Projectteams hebben vaak weinig tijd om nieuwe te implementeren of de functionaliteit van de bestaande features en code uit te breiden die schoon is. De code die gemakkelijk te begrijpen en te onderhouden is, helpt zeker om de iteratiedeadline te halen.

Noodzaak van code-refactoring

Als we de oorspronkelijke functionaliteit van de applicatie of module behouden, rijst de vraag waarom doen we zelfs de moeite om te refactoren? Welnu, er zijn tal van redenen waarom een ​​bepaalde module of stuk code mogelijk moet worden geherstructureerd, zoals:

  1. Code ruikt
  2. Technische schuld
  3. Agile benadering van softwareontwikkeling, enz.

In de volgende paragrafen zullen we deze punten in detail bespreken.

# 1) Code ruikt:

We kunnen allemaal begrijpen dat wanneer het voedsel begint te ruiken, dit aangeeft dat het waarschijnlijk slecht wordt - dit geldt ook voor code! Codegeur is een indicatie dat er een veel ernstig probleem in de code kan zitten.

Hieronder volgen enkele veelvoorkomende codegeuren:

  • Aanwezigheid van overtollige of identieke code.
  • Een gedeclareerde variabele die nergens in de rest van de code wordt gebruikt.
  • Overgecompliceerd code-ontwerp.
  • Codeklasse die te weinig doet en het bestaan ​​van de gedefinieerde klasse niet rechtvaardigt. Dergelijke klassen staan ​​bekend als luie klas of freeloader.
  • Het bestaan ​​van te veel voorwaarden en lussen die kunnen worden afgebroken en vereenvoudigd.
  • Code is zo opgebouwd dat een wijziging in een deel van de code vereist dat de wijziging ook op de andere plaatsen wordt doorgevoerd.

Codegeuren worden duidelijker met het verstrijken van de tijd. Naarmate de applicatie of het systeem groeit, beginnen deze codegeur uiteindelijk de ontwikkeling, het onderhoud en zelfs de systeemprestaties van het systeem in extreme scenario's te beïnvloeden.

# 2) Technische schuld:

Tijdens het ontwikkelen van software kunnen we, in de beperkte tijd en beschikbare middelen, vaak snelkoppelingen nemen om de gewenste resultaten te bereiken.

Overweeg een functie die moet worden toegevoegd aan een bestaande module. Na bespreking beperkt het team twee benaderingen om deze functie toe te voegen. Aanpak A, waarvoor 2 sprints nodig zijn, wordt de goedgekeurde langetermijnaanpak. Aanpak B duurt slechts 5 dagen om te leveren, is een rommelige, hard-coded hack die is ontworpen om de module op korte termijn te onderhouden.

Als het team onder druk staat om de functie binnen een beperkte tijd te leveren, kunnen ze afspreken om benadering B voorlopig te volgen en benadering A toe te voegen aan de backlog voor de toekomst. Door dit te doen, creëerde dit team zojuist de technische schuld voor zichzelf.

In eenvoudige bewoordingen verwijst technische schuld bij softwareontwikkeling naar de extra herwerking of overhead die nodig is om de juiste oplossingen door te voeren of dingen op de 'juiste manier' te doen.

Legacy-systemen hebben de neiging om in de loop van de tijd enorme technische schulden te verwerven, waardoor de applicatie vatbaar is voor storingen en moeilijk te ondersteunen en te onderhouden is.

Lees verder​ Wat is Technical Dept

# 3) Agile Software Development Approach volgen:

Een flexibele benadering van softwareontwikkeling pleit voor incrementele ontwikkeling. Zonder schone, goed gestructureerde en gemakkelijk te onderhouden code zou het voor teams niet mogelijk zijn om de bestaande code met elke iteratie uit te breiden. Als de code wordt gewijzigd zonder de juiste refactoring, kan dit bijdragen aan codegeur of technische schuld.

Deze relatie is weergegeven in het onderstaande diagram

Agile software-ontwikkelingsaanpak

Aanbevolen lezen ​ Top tools voor code-analyse

Waarom moet een QA weten over refactoring?

Wat we tot nu toe in deze tutorial hebben besproken, lijkt te maken te hebben met codering en lijkt op het soort dingen waar een ontwikkelaar zich zorgen over moet maken.

Waarom bespreken we dit niet-gerelateerde concept dan in de Software Testing Help Community? Lees de rest van deze tutorial voor het antwoord op deze vraag.

# 1) Voor unit-testers / ontwikkelaars

Tijdens het herstructureren van de code, terwijl nieuwe code wordt ingevoegd, worden oude klassen bijgewerkt, nieuwe klassen toegevoegd en kunnen bestaande Unit-tests nu mislukken. Bovendien zijn er voor oudere systemen mogelijk helemaal geen unit-tests geïmplementeerd. Deze nieuwe unit-tests zullen in de meeste gevallen vanaf nul moeten worden gemaakt en opgezet.

# 2) Voor testers

Wanneer een functie wordt geherstructureerd (gezien het feit dat we geen nieuwe functionaliteit toevoegen), is het de bedoeling dat nadat de vereiste wijzigingen zijn aangebracht, een meerderheid van de functionaliteit voor de eindgebruiker hetzelfde moet blijven.

  • Als tester vertaalt refactoring van code zich ruwweg naar = diepgaande testen + regressietesten. Diepgaande tests moeten alle bestaande gebruikersstromen omvatten om ervoor te zorgen dat alle functionaliteiten werken zoals voorheen. Regressietesten van de volledige applicatie (of getroffen gebieden) is vereist om ervoor te zorgen dat het upgraden van een module niet onbedoeld de functionaliteit van de andere modules breekt.
  • Gebruikersacceptatietests zijn belangrijk en deze tests moeten doorstaan ​​voordat de build gereed kan worden verklaard voor release.
  • Bovendien is elke andere vereiste test zoals belastingtests, veiligheidstest enz. zouden ook moeten worden geïmplementeerd zoals vereist.

# 3) Automation Test Engineers

Herstructurering van code kan ertoe leiden dat functionele en niet-functionele automatiseringsscripts mislukken.

Dit kan gebeuren om de volgende redenen:

  • Als de pagina-objecten veranderen als onderdeel van de herstructurering en als uw Selenium-automatiseringsscripts afhankelijk zijn van de pagina-objecten, zullen de scripts mislukken en moeten ze worden bijgewerkt.
  • Als er kleine wijzigingen zijn, worden de wijzigingen die zijn toegevoegd of verwijderd tijdens het refactoren, omgeleid, en bestaande automatiseringsscripts zouden mislukken en moeten worden bijgewerkt

Het wordt aanbevolen om de functionele automatiseringstests alleen op te zetten als een functie stabiel is, anders zal het resulteren in veel herwerk naarmate de functie zich ontwikkelt.

Als ontwikkelaar van automatiseringstests, moeten automatiseringstestingenieurs ook denken als een ontwikkelaar en streven naar een schone en gemakkelijk te onderhouden code. De meeste van de IDE's zoals IntelliJ IDEA, Eclipse enz., Bevatten een ingebouwd refactoring-menu met veelgebruikte refactoring-methoden voor gemakkelijke verwijzing.

Hieronder ziet u een screenshot van het refactoring-menu in IntelliJ IDEA (Community Edition).

wat is de beste software voor het verwijderen van malware

refactoring menu

# 4) Voor meetsnoeren / QA-leads

  • Testleads / QA-leads kunnen nodig zijn om samen te werken met de rest van het team, inclusief ontwikkelaars, productanalisten en misschien zelfs belanghebbenden, om ervoor te zorgen dat de testplanning voor dergelijke projecten zorgvuldig wordt uitgevoerd.
  • Het is belangrijk om de bestaande functionaliteit te begrijpen. Op basis van de bestaande functionaliteit dienen businesscases, gebruikersstromen en gebruikersacceptatietesten te worden gedocumenteerd. Wanneer een gerefactureerde code wordt getest, moeten al deze scenario's worden gevalideerd, samen met regressietests van de getroffen gebieden.
  • Wees proactief bij het plannen van de testaanpak en testplannen ​Als u verwacht dat er meerdere testomgevingen of nieuwe testtools nodig zijn, stuur de aanvraag dan vroegtijdig om vertragingen te voorkomen zodra de testfase begint.
  • Schroom niet om niet-projectteamleden of eindgebruikers te betrekken bij het testen.

Case Studies

We zullen nu enkele praktijkvoorbeelden bespreken waarin ik de kans kreeg om direct aan te werken of indirect bij te dragen.

Casestudy # 1

Taak: Refactoreer een module om de hardgecodeerde waarden te vervangen door variabelen en om opmerkingen toe te voegen voor een nieuwe geautomatiseerde tool voor het genereren van technische documentatie.

Uitdagingen ​Geen grote uitdagingen. De module was nieuw, had functionele en gebruikersacceptatievereisten, gebruikersstromen en testcases gedocumenteerd. Unit tests werden opgezet tijdens de eerste lancering zelf.

Testbenadering ​De testcases voor de module die wordt gerefactored en de relatief bekende getroffen gebieden zijn uitgevoerd. Eventuele defecten werden vóór de vrijlating gemeld en verholpen.

Casestudy # 2

Taak ​Refactor bestaande opgeslagen procedure om opschalen van applicaties te vergemakkelijken.

De opgeslagen procedure in dit scenario was een oudere opgeslagen procedure die een paar jaar geleden werd ontworpen, rekening houdend met de vereiste dat de applicatie de opgeslagen procedure gebruikte als een interne applicatie met minder dan 10 gelijktijdige sessies.

Nu wilde het bedrijf deze applicatie op de markt brengen als Software as a Service (SaaS), met het verwachte volume van in eerste instantie 300 gelijktijdige sessies.

Het team deed een aantal eerste belastingtests en concludeerde dat het systeem breekt met een belasting van 25 gelijktijdige sessies. Het team heeft de code beoordeeld en aanbevolen om een ​​bestaande opgeslagen kernprocedure te herstructureren waarmee de applicatie kan opschalen en tot 500 gelijktijdige sessies kan ondersteunen zonder te breken.

Enkele problemen die met deze opgeslagen procedure werden geïdentificeerd, waren meerdere subquery's binnen een enkele query, zware joins met weergaven in plaats van tabellen, het gebruik van select * in plaats van een specifieke kolom te selecteren, enz. Vanwege deze coderingsproblemen haalde de toepassing meer gegevens op dan dat was echt nodig, waardoor de applicatie langzamer ging werken en uiteindelijk crashte.

Uitdagingen:

# 1) Projectmanager / productanalist

  • Verzamelen van vereisten - Aangezien deze opgeslagen procedure een oude code was, waren er geen gedocumenteerde vereisten voor toen de module voor het eerst werd ontworpen. Ook voor de iteraties die de afgelopen jaren zijn gedaan, was er geen wijzigingslogboek om de bedrijfsregels en logica aan te geven die aan de module zijn toegevoegd of verwijderd.
  • Project planning - Omdat de vereisten niet duidelijk waren gedefinieerd en de codeafhankelijkheden nog niet volledig waren geïdentificeerd, was het moeilijk om het voorlopige schema te communiceren.

# 2) Voor ontwikkelaars

  • Gebrek aan duidelijke vereisten en bedrijfsregels.
  • De code opschonen zonder de functionaliteit te verliezen.
  • Onbekende getroffen gebieden en / of codeafhankelijkheden.
  • Kan geen concrete schattingen van de ontwikkelingstijd geven.
  • Er moeten nieuwe unit-tests worden gemaakt.

# 3) Voor testers

  • Gebrek aan duidelijke vereisten en bedrijfsregels hebben invloed op de testplanning.
  • Onbekende impacttestplanning op gebieden, specifiek voor regressietests.
  • Kan geen concrete testschattingen geven.

# 4) Belanghebbenden

  • Gebrek aan duidelijk gedocumenteerde eisen en / of gebruikersstromen + strakke deadlines = groter risico op uitval.

De aanpak die het team volgt om risico's te beperken en de uitdagingen te omzeilen ​

(i) Het team volgde een gezamenlijke aanpak om vereisten te verzamelen : Projectmanager / Productanalist en testers werkten nauw samen met de interne eindgebruikers om de belangrijkste functionaliteit en gebruikersstroom te begrijpen en te documenteren.

Ontwikkelaars hebben ook de code bekeken en relevante informatie aan het requirementsdocument toegevoegd. Dit werd gedaan vóór de startdag van de sprint.

(ii) De alternatieve testomgeving is gemaakt om de wijziging die wordt geïmplementeerd te testen : Laten we deze omgevingen Gamma en Phi noemen. Gamma zou de oude code hebben en Phi zou te allen tijde de nieuwste opnieuw ontworpen opgeslagen procedure hebben.

Door 2 testomgevingen parallel te hebben, bijna opnieuw gecreëerd voor en na de aanpak, kon het team meer diepgaande en verkennende tests doen door het gedrag in deze 2 testomgevingen te vergelijken, ze waren in staat om de waarschijnlijke bugs te identificeren.

Het team leverde de vereisten voor een alternatieve testomgeving die was voorzien vóór de startdatum van de sprint.

(iii) Eindgebruikers en belanghebbenden die al vroeg bij het testen zijn betrokken : Alle voor de hand liggende problemen werden opgemerkt en vroegtijdig gerapporteerd, waardoor het team meer tijd kreeg om de vereiste oplossing te implementeren en te testen.

(iv) Het definiëren van exitcriteria en het naleven ervan: Exitcriteria werden gedefinieerd in de initiële planningsfasen - 80% gebruikersstromen getest, geen kritische bug onopgelost, demo en afmelden van de belanghebbenden vóór release.

(v) Een voorlopige releasedatum instellen: Een releasedatum op één lijn stellen en het team motiveren om naar een gemeenschappelijk eindpunt toe te werken. Op basis van de scope van het project werd door het team aanbevolen om een ​​sprint van 3 weken te volgen in plaats van een gewone sprint van 2 weken om het team voldoende tijd te geven om het project uit te voeren.

Gevolgtrekking

Samenvattend is het herstructureren van code een proces om het ontwerp van een module op te schonen / vereenvoudigen zonder de functionaliteit ervan te wijzigen. Het herstructureringsproces kan eenvoudig zijn, zoals het toevoegen van opmerkingen, het toevoegen van de juiste inspringing, het verwijderen van een statische variabele, enz. Of kan gecompliceerd zijn voor complexe legacy-systemen.

Een bepaalde module of stuk code moet mogelijk worden geherstructureerd vanwege codegeur, technische schuld of door het volgen van een agile softwareontwikkelingsaanpak.

Voor testers vertaalt refactoring van code zich ruwweg naar = diepgaande testen + regressietesten.

Diepgaande tests zijn vereist om alle bestaande gebruikersstromen te testen om er zeker van te zijn dat alle functionaliteiten werken zoals voorheen. Regressietesten van de gehele applicatie (of getroffen gebieden) zijn vereist om ervoor te zorgen dat het upgraden van een module niet onbedoeld de functionaliteit van de andere modules breekt.

Testleads / QA-leads kunnen nodig zijn om samen te werken met de rest van het team, inclusief ontwikkelaars, productanalisten, vooral voor legacy-projecten. Wees proactief bij het plannen van de testaanpak en testplannen. Als u verwacht dat er meerdere testomgevingen of nieuwe testtools nodig zijn, verstuur dan de aanvraag vroegtijdig om vertragingen te voorkomen zodra de testfase begint.

Over de auteur: Deze informatieve tutorial is geschreven door Neha B. Ze werkt momenteel als Quality Assurance Manager en is gespecialiseerd in het leiden en managen van In-house en Offshore QA-teams.

Heb je gewerkt aan een uitdagend project waarbij je code of een module / applicatie moest herstructureren? Zo ja, deel dan gerust uw ervaringen in het opmerkingengedeelte zodat onze collega-testers kunnen leren.

Aanbevolen literatuur

^