Menu

Refaktorovanie kódu: Čo o ňom potrebujete vedieť

code refactoring what you need know about it

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Pochopenie refaktoringu kódu: Perspektíva testera

Pojem „refaktoring“ sa používa hlavne na označenie požadovaného vyčistenia / redizajnu kódu.

V tomto tutoriále pochopíme definíciu refaktoringu, prediskutujeme potrebu refaktoringu kódu a skontrolujeme dopad kódu refaktoringu na rôznych členov projektového tímu. Budeme tiež diskutovať o odpovedi na najdôležitejšiu otázku - Prečo ako tester potrebujete vedieť o refaktoringu?

Okrem toho budeme tiež diskutovať o niekoľkých prípadových štúdiách na objasnenie koncepcie.

Refaktoring kódu

Čo sa dozviete:

Úvod do refaktoringu

Na začiatok si najskôr uvedomme, čo to vlastne refaktoring je.

Refaktoring je v podstate postup alebo proces zlepšovania kódu a / alebo databázy pri zachovaní existujúcej funkčnosti. Cieľom je transformovať neefektívny a príliš komplikovaný kód na efektívnejší, najlepšie jednoduchší a ľahší kód.

Refactoring kódu tiež nabral na obrátkach s ďalšími tímami, ktoré nasledovali po prístupe Agile Software Development. Projektové tímy majú často obmedzený čas na implementáciu nových alebo rozšírenie funkčnosti existujúcich funkcií a čistého kódu. Kód, ktorý je ľahko pochopiteľný a udržiavateľný, určite vedie dlhú cestu k dodržaniu termínu iterácie.

Potreba refaktoringu kódu

Ak si zachovávame pôvodnú funkčnosť aplikácie alebo modulu, naskytá sa otázka: Prečo sa vôbec obťažujeme s refaktoringom? Existuje mnoho dôvodov, pre ktoré bude možno potrebné znova upraviť konkrétny modul alebo časť kódu, napríklad:

  1. Kód vonia
  2. Technický dlh
  3. Agilný prístup k vývoju softvéru atď.

Týmto bodom sa budeme podrobne venovať v nasledujúcich častiach.

# 1) Kód vonia:

Všetci chápeme, že keď jedlo začne voňať, znamená to, že sa s najväčšou pravdepodobnosťou zhoršuje - to platí aj pre kód! Vône po kóde naznačujú, že sa v kóde môže vyskytnúť oveľa vážnejší problém.

Nasleduje niekoľko bežných vôní kódu:

  • Prítomnosť nadbytočného alebo identického kódu.
  • Deklarovaná premenná, ktorá sa nikde vo zvyšku kódu nepoužíva.
  • Príliš komplikovaný návrh kódu.
  • Trieda kódu, ktorá robí príliš málo a neoprávňuje na existenciu definovanej triedy. Takéto triedy sú známe ako lazy class alebo freeloader.
  • Existencia príliš veľkého množstva podmienok a cyklov, ktoré by mohli byť rozčlenené a zjednodušené.
  • Kód je zostavený tak, že zmena v jednej časti kódu vyžaduje implementáciu zmeny aj na ďalších miestach.

Vône kódu sa stávajú zreteľnejšie s odstupom času. Ako aplikácia alebo systém rastie, nakoniec tieto vône kódu začnú ovplyvňovať vývoj, údržbu a dokonca aj výkon systému v extrémnych scenároch.

# 2) Technický dlh:

Pri vývoji softvéru môžeme počas obmedzeného času a dostupných zdrojov často vyžadovať skratky, aby sme dosiahli požadované výsledky.

Zvážte funkciu, ktorú je potrebné pridať do existujúceho modulu. Po diskusii tím zúžil dva prístupy na pridanie tejto funkcie. Prístup A, ktorého uskutočnenie vyžaduje dva šprinty, bude schváleným dlhodobým prístupom. Prístup B trvá iba 5 dní, kým sa doručí, a to je chaotický pevne zakódovaný hack, ktorý je navrhnutý tak, aby v krátkom čase slúžil iba modulu.

Ak je tím pod tlakom, aby dodal funkciu v obmedzenom čase, potom môže súhlasiť s tým, že sa bude zatiaľ držať prístupu B a že v budúcnosti bude prístup A pridávať do nevybavených položiek. Týmto tím tento tím vytvoril technický dlh pre seba.

Zjednodušene povedané, technický dlh vo vývoji softvéru znamená ďalšie prepracovanie alebo réžiu potrebnú na zavedenie vhodných opráv alebo na vykonávanie vecí „správnym spôsobom“.

Legacy Systems majú tendenciu časom získavať obrovské technické dlhy, čo zase môže spôsobiť, že aplikácia bude náchylná na zlyhanie a bude ťažké ju podporovať a udržiavať.

Čítaj viac=> Čo je to technické oddelenie

# 3) Po prístupe agilného vývoja softvéru:

Agilný prístup k vývoju softvéru podporuje prírastkový vývoj. Bez čistého, dobre štruktúrovaného a ľahko udržiavateľného kódu by nebolo možné, aby tímy rozšírili existujúci kód o každú iteráciu. Ak sa kód zmení bez náležitého prefinancovania, môže to prispieť k zápachu kódu alebo technickému dlhu.

Tento vzťah je znázornený na nasledujúcom diagrame

Agilný prístup k vývoju softvéru

Odporúčané čítanie => Najlepšie nástroje na analýzu kódu

Prečo QA musí vedieť o refaktoringu?

Čokoľvek, o čom sme v tejto príručke hovorili až doteraz, sa zdá, že súvisí s kódovaním, a vyzerá to, že by si mal vývojár robiť starosti.

Prečo potom diskutujeme o tomto nesúvisiacom koncepte v komunite pomoci pre testovanie softvéru? Pokračujte v čítaní zvyšku tohto tutoriálu, kde nájdete odpovede na túto otázku.

# 1) Pre testerov / vývojárov jednotiek

Počas refaktoringu kódu pri vkladaní nového kódu sa aktualizujú staré triedy, pridávajú sa nové triedy a existujúce testy Unit teraz môžu zlyhať. Pre staršie systémy nemusí byť vôbec implementované žiadne jednotkové testy. Vo väčšine prípadov bude potrebné tieto nové jednotkové testy vytvoriť a nastaviť úplne od začiatku.

# 2) Pre testerov

Pri prehodnocovaní funkcie (vzhľadom na to, že nepridávame žiadne nové funkcie) sa predpokladá, že po vykonaní požadovaných zmien by väčšina funkcií pre koncového používateľa mala zostať rovnaká.

  • Ako tester sa refaktoring kódu zhruba premieta do = hĺbkového testovania + regresného testovania. Hĺbkové testovanie musí zahŕňať všetky existujúce toky používateľov, aby sa zabezpečilo, že všetky funkcie fungujú rovnako ako predtým. Regresné testovanie celej aplikácie (alebo ovplyvnených oblastí) sa vyžaduje, aby sa zabezpečilo, že aktualizácia modulu neúmyselne neporušila funkčnosť ostatných modulov.
  • Budú dôležité testy prijateľnosti používateľom a tieto testy musia prejsť, kým bude možné zostavenie vyhlásiť za pripravené na vydanie.
  • Akákoľvek ďalšia požadovaná skúška, ako napríklad záťažové skúšky, bezpečnostný test bude potrebné implementovať podľa potreby.

# 3) Inžinieri automatizácie

Refactoring kódu môže spôsobiť zlyhanie funkčných a nefunkčných automatizačných skriptov.

Môže k tomu dôjsť z nasledujúcich dôvodov:

  • Ak sa objekty stránky zmenia v rámci úsilia o refaktoring a ak sa vaše skripty automatizácie selénu spoliehajú na objekty stránky, skripty zlyhajú a bude ich treba aktualizovať.
  • Ak došlo k menším zmenám, presmeruje tie, ktoré boli pridané alebo odstránené počas refaktoringu, a existujúce automatizačné skripty by zlyhali a bolo by ich treba aktualizovať

Odporúča sa, aby sa testy funkčnej automatizácie nastavovali až potom, keď je funkcia stabilná, inak bude mať pri vývoji funkcie za následok veľa prepracovania.

Ako vývojári automatizačných testov musia technici automatizačných testov myslieť ako vývojári a usilovať sa o vytvorenie čistého a ľahko udržiavateľného kódu. Väčšina IDE ako IntelliJ IDEA, Eclipse atď. Obsahuje vstavané menu refaktoringu s bežne používanými metódami refaktoringu pre ľahšiu orientáciu.

Nižšie je uvedený obrázok obrazovky ponuky refaktoringu v IntelliJ IDEA (komunitná edícia).

direktívy preprocesora v c ++ s príkladom

refaktoringové menu

# 4) Pre testovacie elektródy / QA elektródy

  • Môže sa vyžadovať, aby testovací potenciálni zákazníci / záujemcovia o kontrolu kvality spolupracovali so zvyškom tímu vrátane vývojárov, produktového analytika a možno aj zainteresovaných strán, aby sa zabezpečilo, že plánovanie testovania takýchto projektov sa bude robiť opatrne.
  • Je dôležité pochopiť existujúcu funkčnosť. Na základe existujúcej funkčnosti je potrebné zdokumentovať obchodné prípady, toky používateľov a testy prijatia používateľov. Keď sa testuje refaktorovaný kód, je potrebné overiť všetky tieto scenáre spolu s regresným testovaním postihnutých oblastí.
  • Buďte proaktívni pri plánovaní testovacieho prístupu a testovacie plány . Ak očakávate požiadavku viacerých testovacích prostredí alebo nových testovacích nástrojov, pošlite žiadosť včas, aby ste predišli akýmkoľvek oneskoreniam hneď po začiatku testovacej fázy.
  • Ak chcete prispieť k testovaniu, neváhajte zapojiť členov neprojektového tímu alebo koncových používateľov.

Prípadové štúdie

Teraz si povieme niečo o prípadových štúdiách z reálneho života, na ktorých som mal možnosť buď priamo pracovať, alebo nepriamo k nim prispieť.

Prípadová štúdia č

Úloha: Refaktorujte modul, ktorý nahradí pevne napísané hodnoty premennými, a pridajte komentáre k novému automatizovanému nástroju na generovanie technickej dokumentácie.

Výzvy :Žiadne zásadné výzvy. Modul bol nový, mal zdokumentované funkčné a užívateľské akceptačné požiadavky, užívateľské toky a testovacie prípady. Jednotkové testy boli nastavené počas samotného úvodného uvedenia na trh.

Skúšobný prístup :Boli vykonané testovacie prípady modulu, ktorý sa rekonfiguruje, a relatívne známych ovplyvnených oblastí. Prípadné chyby boli nahlásené a vyriešené pred vydaním.

Prípadová štúdia č

Úloha :Refaktorovať existujúcu uloženú procedúru na uľahčenie rozšírenia aplikácie.

Uložená procedúra v tomto scenári bola staršia uložená procedúra, ktorá bola navrhnutá pred niekoľkými rokmi, pričom treba pamätať na požiadavku, aby aplikácia používala svoju uloženú procedúru ako internú aplikáciu s menej ako 10 súbežnými reláciami.

Spoločnosť teraz chcela predať túto aplikáciu ako softvér ako službu (SaaS) so očakávaným objemom pôvodne 300 súbežných relácií.

Tím vykonal niekoľko úvodných testov zaťaženia a dospel k záveru, že systém sa rozpadá so zaťažením 25 súbežných relácií. Tím skontroloval kód a odporučil refaktorovanie jednej existujúcej uloženej procedúry jadra, ktorá by aplikácii umožnila zväčšenie a podporu až 500 súbežných relácií bez porušenia.

Niektoré problémy identifikované v tejto uloženej procedúre boli viac poddotazov v jednom dotaze, ťažké spojenia s pohľadmi namiesto tabuliek, použitie select * namiesto výberu konkrétneho stĺpca atď. Kvôli týmto problémom s kódovaním aplikácia načítavala viac dát ako to bolo skutočne nevyhnutné, čo spôsobilo spomalenie a nakoniec pád aplikácie.

Výzvy:

# 1) Projektový manažér / produktový analytik

  • Zhromaždenie požiadavky - Pretože táto uložená procedúra bola starým kódom, pri prvom navrhovaní modulu na ňu neexistovali žiadne zdokumentované požiadavky. Rovnako pre iterácie vykonané za posledných pár rokov neexistoval žiadny protokol zmien, ktorý by označoval obchodné pravidlá a logiku pridanú alebo odstránenú z modulu.
  • Časový plán projektu - Pretože požiadavky neboli jasne definované a závislosti kódov ešte neboli úplne identifikované, bolo ťažké oznámiť predbežný harmonogram.

# 2) Pre vývojárov

  • Nedostatok jasných požiadaviek a obchodných pravidiel.
  • Čistenie kódu bez straty jeho funkčnosti.
  • Neznáme ovplyvnené oblasti a / alebo závislosti na kóde.
  • Nie je možné poskytnúť konkrétne odhady času vývoja.
  • Potrebujete vytvoriť nové testy jednotiek.

# 3) Pre testerov

  • Nedostatok jasných požiadaviek a plánovanie dopadových testov na obchodné pravidlá.
  • Plánovanie nárazových testov dopadu na neznáme oblasti, konkrétne pre regresné testy.
  • Nie je možné poskytnúť konkrétne odhady testovania.

# 4) Zainteresované strany

  • Nedostatok jasných zdokumentovaných požiadaviek alebo tokov používateľov + krátke termíny = vyššie riziko poruchy.

Prístup, ktorý tím sleduje, pri zmierňovaní rizík a obchádzaní výziev :

i) Tím pri zhromažďovaní požiadaviek postupoval podľa prístupu založeného na spolupráci : Projektový manažér / produktový analytik a testeri úzko spolupracovali s internými koncovými používateľmi na porozumení a dokumentácii hlavných funkcií a toku používateľov.

Vývojári tiež skontrolovali kód a do dokumentu s požiadavkami pridali príslušné informácie. Toto bolo urobené pred dňom začiatku šprintu.

ii) Alternatívne testovacie prostredie bolo vytvorené na testovanie implementovanej zmeny : Nazvime tieto prostredia ako Gama a Phi. Gama by mala starý kód a Phi by mala vždy nasadenú najnovšiu refaktorovanú uloženú procedúru.

Tým, že mali paralelne 2 testovacie prostredia, takmer sa znovu vytvorili pred a po prístupe, umožnili tímu vykonať podrobnejšie a prieskumné testovanie porovnaním správania v týchto 2 testovacích prostrediach, vďaka čomu dokázali identifikovať pravdepodobné chyby.

Tím poskytol požiadavky na alternatívne testovacie prostredie, ktoré bolo poskytnuté pred dátumom začiatku šprintu.

(iii) Koncoví používatelia a zainteresované strany zapojené do testovania skoro : Všetky zjavné problémy boli zachytené a hlásené včas, keď mal tím viac času nasadiť a otestovať požadovanú opravu.

(iv) Definovanie výstupných kritérií a ich dodržiavanie: Kritériá ukončenia boli definované v počiatočných fázach plánovania - 80% testovaných tokov používateľov, žiadna nevyriešená kritická chyba, pred uvedením demo a odhlásenie od zainteresovaných strán.

(v) Stanovenie predbežného dátumu vydania: Zladené nastavenie dátumu vydania a motivácia tímu k práci na dosiahnutí spoločného koncového bodu. Na základe rozsahu projektu tím odporučil, aby sa namiesto pravidelného 2-týždňového šprintu sledoval 3-týždňový šprint, aby mal tím dostatok času na vykonanie projektu.

Záver

Ak to zhrnieme, refaktoring kódu je proces na vyčistenie / zjednodušenie návrhu modulu bez zmeny jeho funkčnosti. Proces refaktoringu môže byť jednoduchý, napríklad pridávanie komentárov, pridanie správneho odsadenia, odstránenie statickej premennej atď., Alebo môže byť komplikovaný pre zložité staršie systémy.

Môže byť potrebné upraviť konkrétny modul alebo časť kódu z dôvodu vône kódu, technického dlhu alebo dodržania agilného prístupu k vývoju softvéru.

Pre testerov sa refaktoring kódu zhruba premieta do = hĺbkového testovania + regresného testovania.

Na otestovanie všetkých existujúcich tokov používateľov je potrebné vykonať dôkladné testovanie, aby ste sa uistili, či všetky funkcie fungujú rovnako ako predtým. Vyžaduje sa regresné testovanie celej aplikácie (alebo ovplyvnených oblastí), aby sa zabezpečilo, že aktualizácia modulu neúmyselne neporušila funkčnosť ostatných modulov.

Môže sa vyžadovať, aby potenciálni zákazníci na testovanie / QA spolupracovali so zvyškom tímu vrátane vývojárov, produktového analytika, najmä pri starších projektoch. Pri plánovaní testovacieho prístupu a testovacích plánov buďte proaktívni. Ak očakávate požiadavku viacerých testovacích prostredí alebo nových testovacích nástrojov, pošlite požiadavku včas, aby ste predišli akýmkoľvek oneskoreniam po začiatku fázy testovania.

O autorovi: Tento informatívny tutoriál napísala Neha B. V súčasnosti pracuje ako manažérka zabezpečenia kvality a špecializuje sa na vedenie a riadenie interných a offshore QA tímov.

Pracovali ste na náročnom projekte, ktorý zahŕňal refaktorizáciu kódu alebo modulu / aplikácie? Ak áno, neváhajte sa podeliť o svoje skúsenosti v sekcii komentárov, kde sa môžu naši kolegovia testeri poučiť.

Odporúčané čítanie

^