🛠️ BI-SWI – Softwarové inženýrství

🔄 Modelování obchodních procesů – účel a přínosy

Než začneme navrhovat software, musíme pochopit, co zákazník aktuálně dělá a jak. Modelování procesů není jen technická formalita – je to způsob, jak odhalit problémy ještě před zahájením vývoje.

• Popsání činnosti zákazníka – pochopení jeho potřeb a problémů z pohledu praxe
• Přesnější specifikace požadavků – víme, co systém musí podporovat
• Lepší podpora procesů v navržené aplikaci
• Zlepšení samotných procesů – bez ohledu na implementaci (re-engineering)
• Identifikace „problémových" míst – kde teče čas nebo vznikají chyby

Typy modelů procesů:

• AS IS – současný stav procesů, bez ohledu na navrhovaný systém. Slouží k pochopení zákazníka, nalezení problémů a jako podklad pro nové procesy.
• TO BE – stav po realizaci nového systému. Umožňuje srovnání a vyhodnocení přínosů.

Notace pro modelování procesů:

• Eriksson-Penker – rozšíření UML pro podnikové procesy
• BPMN (Business Process Model and Notation) – průmyslový standard, bohatá notace
• Diagram aktivit UML – nejčastěji používaný ve výuce FIT ČVUT

Způsob zachycení: Text je nejdůležitější. Diagram slouží pro snadnější pochopení a ověření. Sledujeme důležitost procesu, četnost provádění a časovou/finanční náročnost.

📊 UML Diagram aktivit

Diagram aktivit zobrazuje tok řízení – jak se systém nebo uživatel pohybuje od jedné akce k druhé, jak se tok větví a jak probíhají paralelní činnosti.

Stavební kameny diagramu aktivit:

Akční uzly – reprezentují činnosti, které se provádějí:

• Akce – základní atomická činnost (zaokrouhlený obdélník)
• Akce spouštějící aktivitu – volá jinou aktivitu jako podproces
• Odeslání události – posílá signál jinému účastníkovi (pentagon s šipkou ven)
• Přijetí události – čeká na příchod signálu (pentagon se šipkou dovnitř)
• Časová událost – akce spuštěná časovačem (přesýpací hodiny)

Řídící uzly – řídí tok:

• Počáteční uzel – plný černý kruh, začátek aktivity
• Koncový uzel aktivity – plný kruh v kroužku, ukončí celou aktivitu
• Konec toku – křížek v kroužku, ukončí pouze jeden tok (ostatní pokračují)
• Rozhodovací uzel (Decision) – diamant, tok se větví na základě podmínky. Podmínky na větvích musí být výlučné – vždy splněna právě jedna!
• Slučovací uzel (Merge) – diamant, sbíhá se více toků do jednoho (bez synchronizace)
• Paralelní Fork – černá tlustá čára, rozdělí jeden tok do více paralelních
• Paralelní Join – černá tlustá čára, počká na dokončení VŠECH paralelních větví

Další prvky diagramu aktivit:

• Zóny zodpovědnosti (swimlanes) – rozdělení diagramu do oblastí odpovídajících rolím nebo systémům. Akce v dané zóně provádí daná role.
• Objektové uzly – zachycují stav objektu přenášeného mezi akcemi (obdélník s názvem třídy, volitelně stav v hranatých závorkách, např. Výtisk [Vypůjčen])
• Vícenásobné provedení akce (Expansion Region) – akce se provede pro každý prvek kolekce
• Přerušení provádění (Interrupt Region) – region, jehož zpracování lze přerušit výjimečnou událostí; všechny tokeny uvnitř jsou odstraněny

Typická chyba č. 2 – Míchání stavů objektů mezi akce:

Stav objektu (např. „Vypůjčen") nesmí figurovat jako akce v diagramu. Akce způsobují změnu stavu. Správně: přidáme objektový uzel s daným stavem a akci, která stav vyvolá (např. „Zapsat výpůjčku" → Výtisk [Vypůjčen]).

📋 Analýza a správa požadavků

Kategorizace požadavků:

• Projektové požadavky – cena, termíny, školení, způsob dodání
• Produktové požadavky – Funkční – popisují chování systému (co systém dělá). Příklad: „Systém bude evidovat knihy a výtisky."
• Produktové požadavky – Obecné / Nefunkční – určují omezení kladená na systém. Mají zásadní dopad na architekturu. Příklad: „Aplikace zvládne 100 souběžných uživatelů."

Klasifikace nefunkčních požadavků – FURPS:

Evidované informace o požadavku:

• Název a zkratka (usnadňuje odkazování, např. F1, N2)
• Popis – nejdůležitější část, musí být jednoznačný
• Typ (kategorie), priorita, složitost

Způsoby zachycení požadavků:

• Strukturovaný text – přirozený jazyk s pevnou šablonou
• Uživatelské příběhy (User Stories) – psány z pohledu uživatele, typické pro agilní vývoj. Nesnaží se popsat kompletní chování celého systému.
• Use Case model – detailní zachycení funkčních požadavků

👤 Model případů užití (Use Case Model)

Využití: vyjasnění požadavků se zákazníkem, základ pro uživatelskou příručku, podklady pro akceptační testy, zpřesnění odhadů pracnosti, zadání pro programátora.

Složení modelu případů užití:

• Seznam aktérů – každý aktér je popsán (kdo je, jakou roli zastává)
• Diagramy případů užití – grafický přehled
• Seznam případů užití – každý případ užití obsahuje název, zkratku, popis (cíl), scénáře (hlavní, alternativní, výjimky) a podmínky provedení

Aktér:

• Role, která má zájem využívat funkčnosti systému pro dosažení cíle
• Vždy se jedná o externí entitu – mimo modelovaný systém
• Jedna konkrétní osoba může zastávat více rolí současně
• Speciální aktér: Čas – automaticky spouštěné úlohy na základě časové události
• Mezi aktéry lze použít generalizaci/dědičnost – potomek může spouštět i všechny případy užití svého rodiče

UML Diagram případů užití:

• Patří do skupiny diagramů chování (UML Behavioral – Use Case)
• Aktér – panáček (stickman) nebo obdélník se stereotypem
• Případ užití – elipsa s názvem uvnitř hranice systému
• Hranice systému – obdélník ohraničující všechny případy užití
• Asociace – čára mezi aktérem a případem užití
• «include» – povinná součást, vždy se provede; vyčleňuje sdílené části scénářů (přerušovaná šipka od UC k inkludovanému UC)
• «extend» – volitelné rozšíření; nepovinná část, provede se jen za určitých podmínek (přerušovaná šipka od rozšíření k základnímu UC)

Scénáře případů užití:

• Hlavní scénář – standardní průchod bez chyb a výjimek. Číslovaný seznam kroků (střídají se aktér a systém). Příklad: 1. Aktér klikne, 2. Systém zobrazí formulář, 3. Aktér vyplní…
• Alternativní scénář – odlišný průchod existující část scénáře (např. jiný způsob vložení fotografie)
• Výjimky – chybové stavy (např. nevalidní ISBN)
• Podmínky provedení – vstupní (pre-condition) a výstupní (post-condition)

Granularita případů užití:

• Jeden scénář cca 10 kroků
• Umožňuje uživateli splnit konkrétní cíl, jehož provedení trvá řádově hodiny
• Případ užití musí mít přínos pro uživatele, který ho provádí

🗂️ Analytický doménový model – UML diagram tříd

Cíle: popsat data a jejich meaning (slovníček pojmů), popsat vazby mezi entitami, identifikovat stavy entit, poskytnout základ pro návrh (databázový model, návrhový model tříd).

UML Diagram tříd – základní prvky:

• Třída – obdélník rozdělený na tři části: název, atributy (název:typ), metody
• Viditelnost: - private, # protected, + public
• Atribut vs. asociace – v analytickém modelu preferujeme asociaci (vazbu), protože je názornější a vyjadřuje relaci mezi entitami. Sémanticky jsou ekvivalentní.

Typy vztahů:

Násobnosti (multiplicity):

• 1 – přesně jeden
• 0..1 – nula nebo jeden (volitelný)
• 0..* nebo * – nula nebo více
• 1..* – jeden nebo více (alespoň jeden)

Jak hledat třídy:

• Předměty a objekty reálného světa
• Podstatná jména z vytvořených dokumentů (procesní model, UC model, slovníček)
• Kategorie: obchodní transakce (výpůjčka, platba), položky transakcí, produkty a služby (kniha), role a aktéři, fyzické objekty (výtisk), popisy věcí

Asociační třída: Pokud má samotná vazba atributy (např. vazba Výpůjčka mezi Čtenářem a Výtiskem má datum výpůjčky), zavede se asociační třída. Většinou si však vystačíme bez ní – stačí třída Výpůjčka s atributy a asociacemi.

🔀 UML Stavový diagram

Cíle: porozumění životnímu cyklu entit, vyjasnění stavů, ve kterých se může entita nacházet, zachycení událostí vyvolávajících přechod a podmínek, za kterých může změna nastat.

Prvky stavového diagramu:

• Počáteční pseudostav – plný černý kruh (odkud objekt začíná)
• Koncový stav – kruh v kroužku
• Stav – zaoblený obdélník s názvem stavu
• Přechod – šipka mezi stavy s popisem ve formátu: Událost[Podmínka]/Akce

Syntax přechodu:

• Událost – co přechod spouští (např. vrácenKnihovníkem)
• Podmínka (guard) – v hranatých závorkách, musí být splněna (např. [dne není po termínu])
• Akce – co se provede při přechodu (za lomítkem)

Příklad – stavový diagram Výtisku:

• Stav Volný → přechod „PůjčenČtenáři" → stav Vypůjčen
• Stav Vypůjčen → přechod „VrácenKnihovníkem" → stav Volný
• Stav Volný → přechod „Vyřazen" → stav Vyřazen

🎯 GRASP vzory – principy přiřazení zodpovědností

Existuje mnoho způsobů rozdělení úloh mezi třídy a neexistuje jediné správné řešení. GRASP nám dává vodítko, jak rozhodnout.

Informační expert (Information Expert):

Základní princip: Přiřaďte zodpovědnost třídě, která má informace potřebné pro splnění této zodpovědnosti. Proč? Protože tak se minimalizuje nutnost přístupu jiných tříd k datům – data jsou tam, kde se s nimi pracuje.

Ostatní GRASP vzory (pro přehled): Tvůrce (Creator), Řadič (Controller), Polymorfismus, Čistá výroba (Pure Fabrication), Nepřímý odkaz (Indirection), Chráněné variace (Protected Variations)

🏛️ Vícevrstvá (třívrstvá) architektura

Evoluce architektur:

• Monolitická (jednovrstvá) – vše smícháno dohromady (SQL v HTML šabloně). Vhodná pouze pro prototypy, složitá udržovatelnost.
• Dvouvrstvá – oddělena prezentační vrstva od datové (DAO vrstva). Vhodná pro jednoduché CRUD aplikace.
• Třívrstvá – přidána business vrstva. Vhodná pro enterprise aplikace.
• Vícevrstvá – třívrstvá s dalším dělením na podsystémy.

Striktní vs. Relaxovaná třívrstvá architektura:

• Striktní – závislost vždy směrem dolů a pouze o jednu úroveň (prezentační → business → datová). Čistější, ale méně flexibilní.
• Relaxovaná – závislost vždy dolů, ale přes libovolný počet úrovní. V praxi nejvíce používaná.

🖥️ Model View Controller (MVC)

Komponenty MVC:

• Model – zapouzdřuje data a business logiku. Notifikuje View o změnách (vzor Observer). Dvě varianty:
  • Aktivní model – sám upozorní View na změny (Observer pattern)
  • Pasivní model – pouze reaguje na dotazy, Controller zajistí obnovení View
• View – zobrazuje data z Modelu uživateli. Nezahrnuje business logiku. Může být více View pro jeden Model.
• Controller – zpracovává uživatelský vstup (klik, formulář), volá metody Modelu a určuje, která View se zobrazí.

Vztah MVC a třívrstvé architektury:

MVC je vzor pro prezentační vrstvu třívrstvé architektury. Model v MVC volá Business vrstvu, Controller orchestruje. View a Controller jsou součástí prezentační vrstvy.

MVP (Model-View-Presenter): Varianta MVC pro GUI based na komponentách (Swing, WinForms). View odchytí událost, ale deleguje zpracování na Presenter. View implementuje rozhraní, které Presenter volá.

Příklady frameworků MVC/MVP:

• Spring MVC, Grails – Java
• JSF 2, MyFaces – Java EE (spíše MVP)
• Angular, React – JavaScript (MVVM varianta)
• ASP.NET MVC – .NET

🏭 GoF návrhové vzory

Abstraktní továrna (Abstract Factory) – Creational:

Řeší problém vytváření rodiny/varianty objektů. Klient pracuje pouze s rozhraním továrny a nemusí znát konkrétní třídy produktů.

• AbstractFactory – rozhraní/abstraktní třída definující metody pro vytváření všech produktů
• ConcreteFactory – konkrétní implementace pro danou variantu (např. TestFactoryDAO, HibernateFactoryDAO)
• AbstractProduct – rozhraní produktu (ICtenarDAO, IVypujckaDAO)
• ConcreteProduct – konkrétní implementace produktu

Proč to tak je? Při vývoji chceme testovat bez databáze (TestFactoryDAO vrátí mock objekty). V produkci použijeme HibernateFactoryDAO. Kód klienta se nezmění.

Vzor Stav (State) – Behavioral:

Odděluje chování třídy závislé na stavu do samostatné třídy. Odstraňuje složitá větvení (switch/case, if/else) závislá na stavu objektu.

• Context – třída, jejíž chování se mění v závislosti na stavu (např. Výtisk). Udržuje referenci na aktuální stav.
• State – abstraktní třída/rozhraní pro všechny stavy
• ConcreteState – konkrétní stavy (StavVolny, StavVypujcen) – každý implementuje jiné chování metod

Proč to tak je? Bez vzoru State by metoda zpracuj() obsahovala: if (stav == VOLNY) {...} else if (stav == VYPUJCEN) {...}. S přidáním nového stavu bychom museli modifikovat tuto metodu. Se vzorem State přidáme pouze novou třídu stavu.

Adaptér (Adapter) – Structural:

Konvertuje rozhraní jedné třídy na rozhraní jiné. Umožňuje propojit třídy s nekompatibilními rozhraními bez jejich modifikace.

• Target – rozhraní, které klient očekává
• Adaptee – existující třída s jiným rozhraním
• Adapter – implementuje Target rozhraní a deleguje volání na Adaptee

Příklad z praxe: Naše aplikace očekává rozhraní IPlatebniSluzba. Integrujeme nový platební gateway, jehož API je zcela jiné. Napíšeme Adapter, který překládá volání z IPlatebniSluzba na API gateway.

Stavitel (Builder) – Creational:

• Director – řídí strukturu (pořadí stavění) výsledného produktu
• Builder – umí postavit jednotlivé části produktu v konkrétní „technologii"
• Příklad z přednášky: SQLBuilder – Director řídí, co a v jakém pořadí se přidá do SQL scriptu; konkrétní Builder (OracleBuilder, PostgreSQLBuilder) to realizuje pro danou DB.

Pozorovatel (Observer) – Behavioral:

• Pozorující objekty se zaregistrují u pozorovaného objektu
• Musí implementovat požadované rozhraní (IObserver)
• Při změně upozorní pozorovaný objekt všechny pozorující touto metodou
• Využití: aktivní Model v MVC upozorňuje View na změny

📞 Spolupráce objektů – UML Sekvenční diagram

Prvky sekvenčního diagramu:

• Lifeline (životní čára) – svislá přerušovaná čára znázorňující životnost objektu. Nahoře je obdélník s názvem objektu ve formátu nazev:Trida nebo anonymně :Trida.
• Aktivační obdélník – úzký obdélník na životní čáře znázorňující dobu, kdy je objekt aktivní (vykonává kód)
• Synchronní zpráva – plná šipka → , volající čeká na odpověď
• Asynchronní zpráva – otevřená šipka → , volající nečeká
• Návratová hodnota – přerušovaná šipka zpět, s názvem proměnné/hodnoty
• Statická metoda – volání na třídě, ne na objektu (podtžený název třídy)
• Vytvoření objektu – šipka míří na obdélník nového objektu
• Zrušení objektu – X na konci životní čáry
• Self message – šipka zpět na vlastní lifeline (volání vlastní metody)
• Found message – zpráva s neznámým odesílatelem (začíná plným kruhem)

Kombinované fragmenty (framing):

• alt – alternativa (if-else); každá větev má guard podmínku v hranatých závorkách
• opt – volitelné (if bez else)
• loop – cyklus; guard podmínka nebo loop(min, max)
• par – paralelní provedení
• ref – odkaz na jiný diagram

Iterace přes kolekci: Označuje se smyčkou, uvnitř je notace [foreach prvek : kolekce]

🧩 Objektové paradigma

Základní pojmy:

Třída je šablona (blueprint), podle které se vytvářejí objekty. Definuje:

• Metadata atributů (název, typ, viditelnost)
• Signatury metod (název, parametry, návratový typ)
• Implementace metod
• Konstruktory pro inicializaci atributů při vytvoření objektu

Objekt (instance třídy):

• Hodnoty atributů patří konkrétnímu objektu – nejsou sdílené mezi instancemi
• Implementace metod je sdílená pro všechny objekty dané třídy

Čtyři pilíře OOP:

1. Zapouzdření (Encapsulation):

• Objekt je „black box" – drží svůj stav uvnitř sebe sama
• Implementační detaily jsou schovány za množinou veřejných metod
• Přímý přístup k atributům je zakázán (private), k dispozici jsou gettery/settery
• Proč? Umožňuje měnit vnitřní implementaci bez ovlivnění vnějšího kódu. Chrání před nekonzistentním stavem.

2. Dědičnost (Inheritance):

• Podtřída (potomek) přebírá atributy a metody nadtřídy (rodiče)
• Metody podtřídy mohou překrýt (override) metody nadtřídy
• Ve většině jazyků pouze jednoduchá dědičnost (Java, C#)
• Výhoda: kód rodiče se znovu použije, potomci přidávají specifika

Abstraktní třída:

• Atributy a metody (i abstraktní – bez implementace) jsou povoleny
• Konstruktory jsou povoleny, ale nelze je použít pro vytváření instancí
• Podtřída musí implementovat všechny abstraktní metody, nebo musí být také abstraktní

3. Polymorfismus (Polymorphism):

• Při volání metody je implementace určena typem objektu (dynamická vazba), ne typem referenční proměnné
• Příklad: proměnná typu Zivocich zv = new Pes(). Volání zv.zvuk() zavolá metodu třídy Pes, ne Zivocich.
• Proč? Umožňuje psát generický kód pracující s rozhraním – konkrétní chování dodají potomci.

4. Abstrakce (Abstraction):

• Skrytí implementačních detailů za rozhraní nebo abstraktní třídu
• Klient pracuje s abstraktem, nevidí konkrétní implementaci

UML objektový diagram: Patří do diagramů struktur. Zobrazuje konkrétní instance (objekty) a jejich aktuální stav (hodnoty atributů) v daném čase. Usnadňuje pochopení diagramu tříd – jde o „snímek" systému.

📐 Základní principy návrhu: SRP, LSP, DRY

SRP – Single Responsibility Principle (Princip jediné zodpovědnosti):

Každá třída (ale i metoda) by měla mít právě jednu přesně definovanou zodpovědnost. Přeloženo: třída by se měla měnit pouze z jednoho důvodu.

• Proč? Třída s jednou zodpovědností je snadněji pochopitelná, testovatelná a méně pravděpodobně se rozbije při změnách jiných částí systému.
• Signál porušení SRP: prázdný řádek v těle metody nebo komentář v těle metody – indikuje, že metoda dělá více věcí (kandidát na extrahování)
• Příklad porušení: třída Uzivatel obsahuje metody pro ověření, ukládání do DB i odesílání emailu.
• Příklad splnění: samostatné třídy AutentizacniSluzba, UzivatelDAO, EmailService

LSP – Liskov Substitution Principle (Liskovův substituční princip):

Pokud instanci nadtřídy nahradíme instancí podtřídy, pak kód očekávající instanci nadtřídy by měl fungovat správně i s instancí podtřídy.

• Proč? Dědičnost by měla být skutečně IS-A vztah, ne jen sdílení implementace. Porušení LSP způsobuje nečekané chyby při polymorfismu.
• Klasický příklad porušení: Ctverec extends Obdelnik. Čtverec má vždy stejnou šířku a výšku. Pokud zavoláme na obdélník setSirka(2) a setVyska(3), očekáváme obsah 6. Ale pokud je to čtverec, setVyska(3) nastaví šířku i výšku na 3, obsah bude 9, ne 6. LSP je porušen.
• Řešení: nesnažit se modelovat matematické vztahy přes dědičnost, pokud mají různé kontrakty

DRY – Don't Repeat Yourself (Neopakuj se):

Každý kus znalosti (logika, data, konfigurace) by měl mít v systému jednu jednoznačnou autoritativní reprezentaci.

• Proč? Duplikace kódu je zdroj chyb – při opravě chyby musíme najít a opravit všechny kopie. Při přidání funkce musíme přidat na více místech. Snadno se opomene jedno místo.
• DRY pro kód – zapouzdřit opakující se logiku do metody nebo třídy
• DRY pro data – správný návrh způsobu ukládání dat (normalizace); používání pojmenovaných konstant místo „magic numbers"

Pozor: Ne vždy je copy-paste porušením DRY! Pokud dvě části kódu vypadají podobně, ale jsou logicky nezávislé a mohou se vyvíjet odděleně, spojování je předčasná abstrakce. Musíme rozlišit náhodnou shodu od skutečné duplikace logiky.

Don't talk to strangers (Zákon Démétry):

V metodě objektu je možné volat pouze:

• Jiné metody tohoto objektu (this.metoda())
• Metody objektů, které vlastní (atributy)
• Metody objektů, které vytváří
• Metody objektů, které dostala jako parametr

Porušení: order.getCustomer().getAddress().getCity() – volám metody „cizích" objektů přes řetězec. To zvyšuje provázanost.

Programování proti rozhraní:

• Rozhraní (interface) je kontrakt: definuje, co objekt umí, ne jak to dělá
• Rozhraní všude tam, kde jsou očekávány změny nebo rozšíření
• Zveřejněné rozhraní by mělo být „neměnné" – klienti závisí na kontraktu, ne na implementaci
• Signatura = název metody + parametry + návratový typ + výjimky
• Kontrakt = povolené hodnoty parametrů, garantovaná chování

🛡️ Další principy správné konstrukce

Ošetření chyb:

• Chránit program před nevalidními vstupy (importy, uživatelské vstupy, API)
• Způsoby zpracování chyby: vrácení neutrální hodnoty, zalogování varování, vrácení chybového kódu, vyvolání výjimky, ukončení programu
• Pozor: Vrácení neutrální hodnoty (null, 0) může „zamaskovat chybu" – problém se projeví až jinde a obtížně se debuguje

Logování:

• Úrovně: DEBUG, INFO, WARN, ERROR, FATAL
• Logger – třída pro zápis do logu; Appender/Handler – kam se logy zapisují (soubor, konzole, email, databáze)
• Formátování logů: datum, čas, zpráva, úroveň, třída
• Existující řešení: Java Logging (JUL), LOG4J, SLF4J (fasáda), NLog (.NET)

Štábní kultura (konvence psaní kódu):

• Pojmenování tříd, metod a parametrů musí být srozumitelné a samopopisné
• PascalCase pro třídy, camelCase pro metody/proměnné, SNAKE_CASE pro konstanty
• Špatný kód: float z = 50+y(x.x());. Dobrý kód: float pokuta = pokutaZaZpozdeni(delkaZpozdeni); float celkem = SPRAVNI_POPLATEK + pokuta;
• Konfigurace do externích souborů (ne hardcoded konstanty v kódu) – umožňuje přizpůsobení prostředím bez rekompilace
• Texty GUI do externích souborů – umožňuje lokalizaci

Délka metody: Čím delší metoda, tím vyšší pravděpodobnost chyby. Doporučení: jedna obrazovka (100-200 řádků max). Prázdný řádek v metodě = signál pro extrahování.

Nepodřizovat návrh optimalizaci: Není vhodné optimalizovat předčasně. Je důležitější připravit kód na budoucí změny. Optimalizovat teprve po profileru.

♻️ Refactoring

Proč refactoring? Kód se degraduje časem (technický dluh). Refactoring ho udržuje srozumitelným, testovatelným a rozšiřitelným. Investice do refactoringu snižuje budoucí náklady na údržbu.

Příznaky, kdy je vhodné začít s refactoringem (Code Smells):

• Duplicity – stejný nebo velmi podobný kód na více místech (porušení DRY)
• Dlouhé metody – metoda dělá příliš mnoho, těžko se čte a testuje
• Velké třídy – třída má příliš mnoho zodpovědností (nízká soudržnost, porušení SRP)
• Příliš mnoho parametrů – metoda s více než 3-4 parametry je příznakem špatné abstrakce
• Komentáře – vysvětlující komentář v kódu je příznakem, že kód není dostatečně samopopisný
• Složité struktury podmínek – hluboce zanořené if/else nebo long switch
• Nedodržené jmenné konvence

Vybrané techniky refactoringu: