Menu

Refaktorování kódu: Co o něm potřebujete vědět

code refactoring what you need know about it

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Porozumění refaktoringu kódu: perspektiva testeru

Termín „refaktoring“ se používá hlavně k označení požadovaného vyčištění / redesignu kódu.

V tomto kurzu pochopíme definici refaktoringu, probereme potřebu refaktoringu kódu a zkontrolujeme dopad kódu refaktoringu na různé členy projektového týmu. Rovněž probereme odpověď na nejdůležitější otázku - Proč jako tester potřebujete vědět o refaktoringu?

Dále budeme diskutovat o několika případových studiích k objasnění konceptu.

Refaktorování kódu

Co se naučíte:

Úvod do refaktoringu

Nejprve pochopíme, co to vlastně refaktorování je.

Refaktoring je v podstatě postup nebo proces zlepšování kódu a / nebo databáze při zachování stávající funkce. Cílem je transformovat neefektivní a příliš komplikovaný kód na efektivnější, nejlépe jednodušší a snadnější kód.

Refactoring kódu také nabral na obrátkách u více týmů, a to díky přístupu Agile Software Development. Projektové týmy mají často omezený čas na implementaci nových nebo rozšíření funkčnosti stávajících funkcí a čistého kódu. Kód, který je snadno srozumitelný a udržovatelný, jistě při splnění termínu iterace jde dlouhou cestou.

Potřeba refaktoringu kódu

Pokud zachováváme původní funkčnost aplikace nebo modulu, vyvstává otázka jako Proč se vůbec obtěžujeme refaktorovat? Existuje mnoho důvodů, pro které může být nutné refaktorovat konkrétní modul nebo část kódu, například:

  1. Kód voní
  2. Technický dluh
  3. Agilní přístup k vývoji softwaru atd.

Těmto bodům se budeme podrobně věnovat v následujících částech.

# 1) Vůně kódu:

Všichni chápeme, že když jídlo začne páchnout, znamená to, že se s největší pravděpodobností zhoršuje - to platí i pro kód! Vůně kódu jsou náznaky, že v kódu může existovat mnohem vážnější problém.

Následují některé běžné vůně kódu:

  • Přítomnost nadbytečného nebo identického kódu.
  • Deklarovaná proměnná, která se nikde ve zbytku kódu nepoužívá.
  • Překomplikovaný design kódu.
  • Třída kódu, která dělá příliš málo a neospravedlňuje existenci definované třídy. Takové třídy jsou známé jako líná třída nebo freeloader.
  • Existence příliš mnoha podmínek a smyček, které by mohly být rozděleny a zjednodušeny.
  • Vytvoření kódu takovým způsobem, že změna v jedné části kódu vyžaduje implementaci změny i na dalších místech.

Vůně kódu se stanou zřetelnějšími s postupem času. Jak aplikace nebo systém roste, nakonec tyto vůně kódu začnou ovlivňovat vývoj, údržbu a dokonce i výkon systému v extrémních scénářích.

# 2) Technický dluh:

Při vývoji softwaru, během omezeného času a dostupných zdrojů, můžeme často použít zkratky k dosažení požadovaných výsledků.

Zvažte funkci, kterou je třeba přidat do existujícího modulu. Po diskusi tým zúží 2 přístupy k přidání této funkce. Přístup A, který vyžaduje 2 sprinty, bude schváleným dlouhodobým přístupem. Přístup B trvá pouze 5 dní, než se doručí, je chaotický naprogramovaný hack, který je navržen tak, aby modul v krátké době pouze obsluhoval.

Pokud je tým pod tlakem, aby dodal funkci v omezeném čase, může souhlasit, že bude nyní postupovat podle přístupu B a v budoucnu přidá přístup A do nevyřízených položek. Tímto způsobem si tento tým vytvořil technický dluh pro sebe.

Jednoduše řečeno, technický dluh ve vývoji softwaru označuje další přepracování nebo režii, která je nutná k zavedení příslušných oprav nebo k provedení „správného způsobu“.

Legacy Systems mají tendenci získávat obrovské technické dluhy v průběhu času, což může způsobit, že aplikace bude náchylná k selhání a bude obtížné ji podporovat a udržovat.

Přečtěte si více=> Co je to technické oddělení

# 3) Po přístupu Agile Software Development:

Agilní přístup k vývoji softwaru prosazuje postupný vývoj. Bez čistého, dobře strukturovaného a snadno udržovatelného kódu by týmy nemohly rozšířit stávající kód s každou iterací. Pokud je kód změněn bez řádného refaktoringu, může to přispět k pachům kódu nebo technickému zadlužení.

Tento vztah je znázorněn na následujícím obrázku

Agilní přístup k vývoji softwaru

Doporučené čtení => Nejlepší nástroje pro analýzu kódu

Proč QA potřebuje vědět o refaktoringu?

Cokoli, o čem jsme v tomto tutoriálu diskutovali až dosud, se zdá, že souvisí s kódováním, a vypadá to, že by si měl vývojář dělat starosti.

Proč tedy diskutujeme tento nesouvisející koncept v komunitě nápovědy pro testování softwaru? Pokračujte ve čtení zbytku tohoto tutoriálu, kde najdete odpověď na tuto otázku.

# 1) Pro testery / vývojáře jednotek

Při refaktorování kódu při vkládání nového kódu se aktualizují staré třídy, přidávají se nové třídy a stávající testy Unit nyní mohou selhat. U starších systémů nemusí být vůbec implementovány žádné testy jednotek. Ve většině případů bude nutné tyto nové jednotkové testy vytvořit a nastavit úplně od začátku.

# 2) Pro testery

Při refaktorování funkce (vzhledem k tomu, že nepřidáváme žádné nové funkce) je pochopitelné, že po provedení požadovaných změn by většina funkcí pro koncového uživatele měla zůstat stejná.

  • Jako tester se refaktoring kódu zhruba promítá do = hloubkové testování + regresní testování. Hloubkové testování musí zahrnovat všechny existující toky uživatelů, aby bylo zajištěno, že všechny funkce fungují jako dříve. Regresní testování celé aplikace (nebo ovlivněných oblastí) je vyžadováno, aby bylo zajištěno, že upgrade modulu neúmyslně nenarušilo funkčnost ostatních modulů.
  • Důležité budou uživatelské akceptační testy a tyto testy musí projít, než bude možné sestavení deklarovat jako připravené k vydání.
  • Kromě toho jsou vyžadovány jakékoli další testy, jako jsou zátěžové testy, bezpečnostní test podle potřeby by také musely být implementovány.

# 3) Automation Test Engineers

Refactoring kódu může způsobit selhání funkčních a nefunkčních automatizačních skriptů.

K tomu může dojít z následujících důvodů:

  • Pokud se objekty stránky změní jako součást úsilí o refaktorování a pokud se vaše skripty automatizace selenu spoléhají na objekty stránky, skripty selžou a bude je třeba aktualizovat.
  • Pokud došlo k drobným změnám, přesměruje ty, které byly přidány nebo odebrány během refaktoringu, a stávající automatizační skripty by selhaly a bylo by je třeba aktualizovat

Doporučuje se, aby testy funkční automatizace byly nastaveny až poté, co je funkce stabilní, jinak bude při vývoji funkce docházet k mnoha přepracováním.

Být vývojářem automatizačních testů musí také technici automatizačních testů myslet jako vývojář a usilovat o vytvoření čistého a snadno udržovatelného kódu. Většina IDE jako IntelliJ IDEA, Eclipse atd. Zahrnuje vestavěné menu refaktoringu s běžně používanými metodami refaktoringu pro snadnou orientaci.

Níže je snímek obrazovky nabídky refaktoringu v IntelliJ IDEA (Community Edition).

bezplatná kontrola gramatiky lepší než gramaticky

refaktoringové menu

# 4) Pro testovací vodiče / QA vodiče

  • Může být vyžadováno, aby testovací potenciální zákazníci / potenciální zákazníci QA spolupracovali se zbytkem týmu, včetně vývojářů, produktových analytiků a možná i zúčastněných stran, aby bylo zajištěno pečlivé plánování testů u těchto projektů.
  • Je důležité pochopit stávající funkčnost. Na základě stávajících funkcí je třeba zdokumentovat obchodní případy, toky uživatelů a uživatelské akceptační testy. Když se testuje refaktorovaný kód, je třeba ověřit všechny tyto scénáře spolu s regresním testováním ovlivněných oblastí.
  • Buďte proaktivní při plánování testovacího přístupu a testovací plány . Pokud očekáváte požadavek více testovacích prostředí nebo nových testovacích nástrojů, pošlete prosím žádost včas, abyste zabránili jakémukoli zpoždění, jakmile začne fáze testování.
  • Neváhejte zapojit členy neprojektového týmu nebo koncové uživatele, abyste se podíleli na testování.

Případové studie

Nyní probereme některé případové studie z reálného života, ve kterých jsem měl příležitost buď přímo pracovat, nebo nepřímo přispět.

Případová studie č. 1

Úkol: Refaktorujte modul, který nahradí pevně zakódované hodnoty proměnnými, a přidejte komentáře k novému automatizovanému nástroji pro generování technické dokumentace.

Výzvy :Žádné zásadní výzvy. Modul byl nový, měl zdokumentované funkční a uživatelské požadavky, uživatelské toky a testovací případy. Testy jednotek byly nastaveny během samotného počátečního spuštění.

Zkušební přístup :Byly provedeny testovací případy modulu, který je refaktorován, a relativně známých ovlivněných oblastí. Veškeré závady byly nahlášeny a vyřešeny před vydáním.

Případová studie č. 2

Úkol :Refaktorovat existující uloženou proceduru pro usnadnění škálování aplikací.

Uložená procedura v tomto scénáři byla starší uložená procedura, která byla navržena před několika lety, přičemž je třeba pamatovat na požadavek, že aplikace používala svoji uloženou proceduru jako interní aplikaci s méně než 10 souběžnými relacemi.

Nyní společnost chtěla prodat tuto aplikaci jako software jako službu (SaaS), s původně očekávaným objemem 300 souběžných relací.

Tým provedl několik počátečních zátěžových testů a dospěl k závěru, že se systém rozbije se zátěží 25 souběžných relací. Tým zkontroloval kód a doporučil refaktorování jedné existující základní uložené procedury, která by umožnila aplikaci škálovat a podporovat až 500 souběžných relací bez porušení.

Některé problémy identifikované u této uložené procedury byly více poddotazů v rámci jednoho dotazu, těžké spojení s pohledy místo tabulek, použití select * místo výběru konkrétního sloupce atd. Kvůli těmto problémům s kódováním aplikace načítala více dat bylo opravdu nutné, což způsobilo zpomalení aplikace a nakonec i pád.

Výzvy:

# 1) Projektový manažer / produktový analytik

  • Shromáždění požadavků - Vzhledem k tomu, že tato uložená procedura byla starým kódem, neexistovaly pro ni při prvním návrhu modulu žádné zdokumentované požadavky. Také pro iterace provedené v posledních několika letech nebyl žádný protokol změn, který by označoval obchodní pravidla a logiku přidanou nebo odebranou z modulu.
  • Časový plán projektu - Jelikož požadavky nebyly jasně definovány a závislosti na kódu ještě nebyly plně identifikovány, bylo obtížné sdělit předběžný plán.

# 2) Pro vývojáře

  • Nedostatek jasných požadavků a obchodních pravidel.
  • Čištění kódu bez ztráty jeho funkčnosti.
  • Neznámé ovlivněné oblasti a / nebo závislosti na kódu.
  • Nelze poskytnout konkrétní odhady doby vývoje.
  • Potřebujete vytvořit nové testy jednotek.

# 3) Pro testery

  • Chybějící jasné požadavky a obchodní pravidla ovlivňují plánování testů dopadu.
  • Neznámé ovlivněné oblasti ovlivňují plánování testů dopadů, konkrétně pro regresní testy.
  • Nelze poskytnout konkrétní odhady testování.

# 4) Zúčastněné strany

  • Nedostatek jasných dokumentovaných požadavků a / nebo toků uživatelů + krátké termíny = Vyšší riziko selhání.

Přístup, který tým používá ke zmírnění rizik a řešení problémů :

(i) Tým se při shromažďování požadavků řídil přístupem založeným na spolupráci : Projektový manažer / analytik produktu a testeři úzce spolupracovali s interními koncovými uživateli na porozumění a dokumentaci hlavních funkcí a toku uživatelů.

Vývojáři také zkontrolovali kód a přidali příslušné informace do dokumentu požadavků. To bylo provedeno před začátkem sprintu.

(ii) Alternativní testovací prostředí bylo vytvořeno za účelem testování implementované změny : Pojďme tato prostředí nazvat Gamma a Phi. Gamma by měla starý kód a Phi by měl vždy nasazenou nejnovější refaktorovanou uloženou proceduru.

Mít paralelně 2 testovací prostředí, téměř znovu vytvořené před a po přístupu, umožnilo týmu provést podrobnější a průzkumné testování porovnáním chování v těchto 2 testovacích prostředích a byli schopni identifikovat pravděpodobné chyby.

Tým poskytl požadavky na alternativní testovací prostředí, které bylo poskytnuto před datem zahájení sprintu.

(iii) Koncoví uživatelé a zúčastněné strany zapojené do testování brzy : Veškeré zjevné problémy byly zachyceny a nahlášeny brzy, což týmu poskytlo více času na nasazení a otestování požadované opravy.

(iv) Definování výstupních kritérií a jejich dodržování: Kritéria pro ukončení byla definována v počátečních fázích plánování - 80% testovaných toků uživatelů, žádná nevyřešená kritická chyba, před vydáním demo a odhlášení od zúčastněných stran.

(v) Stanovení předběžného data vydání: Nastavení data vydání v souladu a motivace týmu k práci na dosažení společného koncového bodu. Na základě rozsahu projektu bylo týmem doporučeno, aby byl místo běžného dvoutýdenního sprintu následován 3týdenní sprint, aby měl tým dostatek času na provedení projektu.

Závěr

Abychom to shrnuli, refaktorování kódu je proces čištění / zjednodušení návrhu modulu bez změny jeho funkčnosti. Proces refaktoringu může být jednoduchý, jako je přidání komentářů, přidání správného odsazení, odstranění statické proměnné atd., Nebo může být komplikovaný pro složité starší systémy.

Může být nutné refaktorovat konkrétní modul nebo část kódu kvůli vůni kódu, technickému dluhu nebo dodržování agilního přístupu k vývoji softwaru.

U testerů se refaktorování kódu zhruba promítne do = hloubkové testování + regresní testování.

K otestování všech existujících toků uživatelů je nutné provést důkladné testování, aby bylo zajištěno, že všechny funkce fungují jako dříve. Je vyžadováno regresní testování celé aplikace (nebo ovlivněných oblastí), aby bylo zajištěno, že upgrade modulu neúmyslně nezlomilo funkčnost ostatních modulů.

Může být vyžadováno, aby zájemci o testování / QA spolupracovali se zbytkem týmu, včetně vývojářů, produktového analytika, zejména u starších projektů. Při plánování testovacího přístupu a testovacích plánů buďte proaktivní. Pokud očekáváte požadavek více testovacích prostředí nebo nových testovacích nástrojů, pošlete prosím žádost včas, abyste předešli jakémukoli zpoždění, jakmile začne fáze testování.

O autorovi: Tento informativní tutoriál napsal Neha B. V současné době pracuje jako manažer zajišťování kvality a specializuje se na vedení a řízení interních a offshore QA týmů.

Pracovali jste na náročném projektu, který zahrnoval refaktorování kódu nebo modulu / aplikace? Pokud ano, neváhejte se podělit o své zkušenosti v sekci komentářů, ze které se naši kolegové testeři mohou poučit.

Doporučené čtení

^