TakéCode refactoring, Refaktorování kóduPokročilý
Definice
Refactoring je cílená úprava vnitřní struktury existujícího kódu bez změny jeho pozorovatelného chování. Vývojář při něm zjednodušuje návrh, pojmenování, duplicity nebo rozdělení odpovědností tak, aby se kód snáz četl, testoval a měnil, aniž by uživatel aplikace poznal rozdíl ve funkcích.
Proč refactoring mění kód, ale ne funkci
Refactoring řeší rozdíl mezi tím, co program dělá, a tím, jak je uvnitř postavený. Veřejné chování zůstává stejné: stejné vstupy mají dát stejné výstupy, stejné tlačítko má spustit stejnou akci a stejné API má vrátit stejný význam odpovědi. Mění se názvy, hranice funkcí, závislosti, duplicity nebo rozdělení odpovědností.
Dobrý refactoring má malý rozsah a jasný záměr. Vývojář například přejmenuje nejasnou proměnnou, vytáhne část dlouhé metody do samostatné funkce, nahradí opakovaný blok jedním voláním nebo přesune logiku tam, kde lépe patří. Smyslem není přidat funkci, ale snížit budoucí náklady na porozumění a změny.
Bezpečnostní síť před úpravou návrhu
Bezpečný refactoring stojí na ověření chování. Nejčastější oporou jsou automatizované testy, typová kontrola, statická analýza a malé commity. Testy nemusí dokazovat dokonalost programu, ale mají rychle odhalit, že úprava rozbila existující scénář.
Refactoring je vhodné oddělovat od funkčních změn. Smíchaný commit, který zároveň mění architekturu i business logiku, se hůř kontroluje v code review a hůř vrací zpět. Praktický postup často vypadá takto: nejdřív zachytit současné chování testem, potom udělat malou strukturální změnu, spustit ověření a teprve následně pokračovat.
Dva praktické příklady refactoringu
Rozdělení dlouhé funkce v košíku
E-shop má funkci, která zároveň počítá cenu, vybírá dopravu a formátuje text pro zákazníka. Každá drobná změna ceníku nutí vývojáře číst i kód, který s cenou nesouvisí. Refactoring rozdělí odpovědnosti do menších funkcí, takže výpočet slevy lze testovat samostatně a úprava textu neohrozí pravidla objednávky.
function orderTotal(items, discount) {
const subtotal = items.reduce((sum, item) => sum + item.price, 0);
return subtotal - subtotal * discount;
}
function formatOrderSummary(total) {
return `Celkem: ${total} Kč`;
}Nahrazení větvení strategií plateb
Aplikace pro předplatné obsahuje podmínku pro kartu, bankovní převod a firemní fakturu. Přidání další platební metody zvětšuje jednu centrální funkci a zvyšuje riziko, že se omylem poškodí starší větev. Refactoring může zavést samostatné strategie pro jednotlivé platby, takže nová metoda přibude jako nový objekt nebo modul, ne jako další řádek ve stále delší podmínce.
const methods = {
card: payByCard,
invoice: payByInvoice
};
methods[order.paymentType](order);Kdy může refactoring počkat
Refactoring není automatická odpověď na každý nehezký kód. Úprava může počkat, když část systému brzy zmizí, když chybí základní testy pro rizikovou oblast nebo když tým právě řeší kritickou produkční závadu. Rozumné odložení ale znamená zapsat důvod a vrátit se k problému, ne nechat technický dluh bez majitele.
Příklady z praxe
Rozdělení dlouhé funkce v objednávkách
Vývojový tým e-shopu upravoval objednávkový modul, kde jedna dlouhá funkce počítala slevu, vytvářela text faktury a zároveň zapisovala auditní záznam. Programátoři nejprve doplnili testy pro existující výpočty a potom rozdělili funkci na samostatné části pro výpočet, formátování a logování. Zákazník v aplikaci neviděl žádnou novou funkci, ale další změna slevového pravidla se dala provést v jedné malé funkci bez zásahu do fakturace.
function calculateDiscount(order) { return order.items.reduce((sum, item) => sum + item.price, 0) * order.discountRate; } function createInvoiceText(order, discount) { return `Objednávka ${order.id}, sleva ${discount} Kč`; }Odstranění duplicit v kontrole plateb
Backendový tým bankovní aplikace řešil službu pro schvalování plateb, která obsahovala několik nejasně pojmenovaných proměnných a opakované bloky kontroly limitů. Vývojáři přejmenovali proměnné podle doménových pojmů, duplicitní kontrolu limitu přesunuli do jedné sdílené metody a změny nasadili až po průchodu regresních testů. Chování plateb zůstalo stejné, ale code review nových pravidel pro firemní účty bylo kratší a méně náchylné k přehlédnutí chyby.
Časté omyly
- MýtusRefactoring je jen přejmenování proměnných.
- Ve skutečnostiPřejmenování je jeden z nejmenších refactoringů. Refactoring může zahrnovat rozdělení modulů, odstranění duplicit, úpravu závislostí nebo změnu návrhového vzoru, pokud se nezmění pozorovatelné chování programu.
- MýtusRefactoring se nedá plánovat, protože nepřináší žádnou funkci.
- Ve skutečnostiRefactoring často nepřidá viditelnou funkci, ale může snížit náklady na další vývoj. Plánování dává smysl hlavně u částí, které se budou často měnit nebo už zpomalují dodávku oprav a nových funkcí.
Časté dotazy
- Má být refactoring samostatný úkol v backlogu?
- Refactoring má být samostatný ticket hlavně tehdy, když zabere viditelný čas, zasahuje více částí systému nebo potřebuje schválení produktu kvůli riziku. Menší refactoring přímo v rámci vývoje funkce bývá přirozený, pokud zůstane čitelný v code review. Důležité je nemíchat velkou strukturální změnu s novým chováním v jednom nečitelném balíku.
- Jak poznat, že refactoring omylem změnil chování?
- Refactoring změnil chování aplikace, pokud po úpravě přestane platit některý dosavadní scénář: jiný výsledek výpočtu, jiná odpověď API, změněná validace nebo odlišná práce s chybou. Automatizované testy, snapshoty API, kontrola logů a code review pomáhají rozdíl zachytit. Pokud je změna chování záměrná, nejde už o čistý refactoring, ale o funkční úpravu.
- Proč se refactoring doporučuje dělat po malých krocích?
- Refactoring po malých krocích snižuje velikost chyby, kterou musí vývojář hledat, když se něco rozbije. Krátký krok se dá rychle otestovat, snadno zkontrolovat a obvykle bezpečně vrátit. Velká jednorázová přestavba může být technicky správná, ale její review často trvá dlouho a riziko skrytých regresí roste.
- Kdy refactoring může být nebezpečný?
- Refactoring zvyšuje riziko, když tým upravuje málo pokrytou kritickou část těsně před releasem, nerozumí doménovým pravidlům nebo nemá možnost rychle ověřit dopad. Rizikový refactoring není zakázaný, ale potřebuje opatrnější plán: testy předem, menší rozsah, zkušeného reviewera a možnost rychlého návratu na předchozí verzi.
Zdroje
- Code refactoring(otevře se v novém okně)
- Refactoring in Visual Studio(otevře se v novém okně)
- code refactoring(otevře se v novém okně)
Související pojmy
