55 - Návrh řízený testem, refaktorizace, vlastnictví a správa zdrojového kódu v týmu Flashcards
Software Design and Development
• Mapování návrhových modelů na implementační a ty přepsat
• Není to pouze převedení návrhu do implementace (jako by tomu bylo v MDD)
• Typicky bude třeba změna návrhu na základě technických problémů, integraci atd.
○ Nakonec se návrh bude dost možná hodně lišit - Což nevadí – návrh je pro pochopení/načtrtnutí – NE pro dokumentování
* Design lze přeskočit, pokud je nám jasné, co máme dělat * Upřesnění vícenásobných asociací – kardinalitou * Při psaní kódu je důležité dodržet pořadí jeho implementace – řídit se class diagramem
Podstata vývoje řízeného testem (TDD)
= nejprve testuj (test-first development).
- Praxe prosazovaná iterativními a agilními metodami, aplikovatelná rovněž u UP.
Podstata = Nejprve se napíše test a teprve potom se implementuje to, co se testuje.
Výhody:
1. Jednotkové testy se skutečně napíší.
2. Uspokojení programátorů vede ke psaní konzistentnějších testů
3. Ujasnění si detailního rozhraní a chování.
4. Prokazatelná, opakovatelná automatizovaná verifikace.
5. Důvěra v provádění změn - refaktorizace a rozšiřování.
6. Podpora TDD – rámce (frameworky) podporující jednotkové (a jiné) testování
Nevýhody: přidává režii, zpomaluje vývoj, občas trvá déle napsat test nežli samotný kód
Obecný postup TDD při implementaci třídy (napiš test, dokud neprochází opravuj kód, pokud prochází uprav test, nebo je hotovo)
1. Vytvoř testovací třídu. 2. Vytvoř „přípravek“ testované třídy. 3. Do a. Vytvoř testovací metodu: i. Aplikuj metodu, kterou testuješ. ii. Ověř očekávané výsledky. b. Implementuj testovanou metodu. c. While implementace vykazuje chyby do i. Uprav implementaci 4. Until implementace třídy je úplná
Např.
Před programováním třídy Sale naprogramujeme testovací metodu pro testovací případ ve třídě SaleTest:
1. Vytvoření instance Sale (tzv. přípravek (fixture)).
2. Přidání několika položek prodeje pomocí metody makeLineItem (tu chceme testovat).
3. Zjištění celkové částky prodeje (použitím getTotal a assertTrue)
Co je to Refaktorizace a hlavní cíle
Refaktorizace = změna zdrojových kódů tak, že se nezměnı́ chovánı́ systému, ale pouze jeho vnitřnı́ struktura.
Přínosy: Vyčištěnı́ kódu od dočasných nebo starých konstrukcı́. Zlepšenı́ designu nebo postupu, optimalizace, přejmenovánı́ pro vhodnějšı́ pochopenı́.
Hlavnı́ oblasti:
• Duplicitnı́ kód
• Dlouhé metody
• Velké třı́dy (nebo třídy co dělají moc věcí) (např. mnoho atributů,..)
• Přı́liš mnoho parametrů
• Odstraněnı́ závislostı́ pro změny (shotgun surgery)
• Odstraněnı́ silného provázání (coupling) mnoha objektů
• Data, která jsou použı́vána na mnoha mı́stech a měla by být objektem
• Feature envy – čtenı́ dat z mnoha jiných objektů k vlastnı́mu výpočtu
Cíle (i viz výše): • Zvýšení srozumitelnosti • Zkrácení dlouhých metod • Odstranění „natvrdo“ kódovaných literálových konstant • Tzv. „pachy v kódu“ (code smells): ○ duplicitní kód ○ rozsáhlé metody ○ třída s mnoha atributy ○ nápadně podobné podtřídy
Metody refaktoringu:
• Extract class - rozděluje velkou třı́du na několik menšı́ch, původnı́ třı́da je pak volá.
• Extract interface - tvořı́ vı́ce rozhranı́ pro jednu třı́du namı́sto jednoho velkého.
• Subsume method - eliminuje metodu jejı́m začleněnı́m do jiné, vhodné pro duplicitnı́ výskyty kódu.
Extract Method = Transformuj dlouhou metodu na kratší vyčleněním logické části do privátní pomocné metody. Extract Constant (Replace Magic Number with Symbolic Constant) = Nahraď literálovou konstantu konstantní proměnnou. Introduce Explaining Variable (Extract Variable) = Ulož výsledek výrazu nebo části výrazu do přechodné proměnné se jménem vysvětlujícím smysl. Replace Constructor Call with Factory Method = V Javě se nahradí použití new a konstruktoru voláním pomocné metody, která skryje detaily vytvoření.
Proč, kdy refaktorizujeme, zásady a problémy
Proč refaktorizujeme (M. Fowler) • lepší návrh software. • lepší srozumitelnost software. • pomáhá hledat chyby - lepší pochopení kódu (K.Beck: „Nejsem skvělý programátor, jsem pouze dobrý programátor se skvělými návyky.“) • ...
Kdy refaktorizujeme
• místo třetího opakování („Poprvé to prostě uděláš, podruhé se rozmýšlíš kvůli duplicitě, ale uděláš to, ale potřetí bys měl refaktorizovat.“)
• před přidáním funkcionality (nejčastější případ refaktorizace).
• při opravách chyb (lepší pochopení kódu) a při revizi kódu.
Užitečné zásady
• Když zjistíte, že do programu musíte přidat novou funkci a přitom jeho struktura k tomu není vhodná, nejprve v programu refaktorizujte tak, aby přidání funkce bylo snadné a teprve pak funkci přidejte.
• !!! Než začnete refaktorizovat, zkontrolujte, jestli máte kvalitní sadu testů, které se samy vyhodnocují.
• Refaktorizace mění programy po malých krocích. Pokud se spletete, je jednoduché chybu najít.
• Kód, kterému rozumí počítač, dokáže napsat každý. Dobří programátoři píší kód, kterému rozumí lidé.
• Stop when you are unsure - (if the code is already better, stop and release; throw away the changes otherwise)
• Work in pairs, refactor with someone.
Problémy
• Jednou z problematických oblastí jsou databáze (většina podnikových aplikací je těsně spojena se strukturou databáze, navíc problémy s nutností migrace dat při změně struktury).
• Řešení u neobjektových databází: vrstva oddělující databázový a objektový model (při změně nutno aktualizovat jen oddělující vrstvu).
* Changing interfaces may not be possible (a refactoring may change an interface, which is not possible for stable/published interfaces; do not publish interfaces prematurely) * Design changes can be difficult to refactor (if there wont be a simple way to refactor, you must put more effort into the design)
Verzování + různé přístupy vlastnictví kódu
Tým pracuje na stejném projektu, potřebují společně měnit kód.
Různé přístupy vlastnictví kódu:
• žádné vlastnictví kódu (všichni programátoři mohou měnit jakoukoliv oblast kódu)
• silné/individuální vlastnictví kódu (jednoznačný vlastník, jedinec; programátor muže měnit jen to, co vlastní)
• slabé vlastnictví kódu (opět vlastník-jedinec; lze měnit cokoliv, se souhlasem/informováním vlast.)
• společné/kolektivní vlastnictví kódu (extrémní programování) (každý by měl vylepšovat jakýkoli kód, kdykoliv je k tomu příležitost - vyžaduje podporu správy verzí)
Zavedené praktiky při vývoji software
- Předpokládáme slabé případně společné vlastnictví kódu. (tyto jsou v praxi malých a středních týmů většinou nejvhodnější)
- Vyvíjený kód je uložen ve společném repositáři a měněn:
• implementací nových funkcí (tj. „feature“)
• opravou chyb způsobujících problémy (tj. „bug-fix“)
• Rychlým řešením chyb-incident ̊u (tj. „hot-fix“)
• laděním kódu pro vydání (tj. „release“)
• refaktorizací kódu (tj. „clean-up“)
• atd.
Běžný postup:
1. vývojář začne pracovat na kódu v určitém stavu (tj. „base“) 2. vývojář vyvíjí/implementuje (tj. „coding“) 3. občas vývojář aktualizuje svoji (měněnou) kopii kódu dle aktuálního společného kódu a vyřeší případné nekompatibility (tj. „rebase“) 4. až je hotovo, tak vývojář promítne svoje změny do aktuálního společného kódu (tj. „merge“)
Sdílený kód s lineární historií - fujky
- Historie sdíleného kódu je vidět jako přímka, bez větvení (tj. nikdy veřejně neexistovalo více variant sdíleného kódu):
• Vývojář musí před aplikací své změny na společný kód provést „rebase“, tj. sladit změnu s aktuálním stavem sdíleného kódu. (pak aplikuje změnu bez konfliktů a tedy pouze posune stav sdíleného kódu)
• Výhodou je přehlednost a jednoduchost správy kódu. (každý okamžitě ví, jaký je aktuální stav)
• Nevýhody však převažují:
○ existuje jen jedna varianta sdíleného kódu, musí být vždy perfektní (zejména musí jít vždy přeložit, spustit, případně také uvolnit jako „release“)
○ na společný kód lze aplikovat pouze hotové změny (důsledek) (těžko zveřejníme k posouzení/pomoci/diskuzi nedokončenou změnu)
○ vývojáři těžko spolupracují, rozpracované kopie kódu se nesdílí (sdílený kód existuje pouze v jedné variantě; spolupráci si musí řešit sami)
○ mezi „rebase“ změny a její aplikací se sdílený kód nesmí změnit (jinak musí být další rebase; není tedy čas na diskuzi o změně)
Sdílený kód s větvenou historií - yees
- Historie sdíleného kódu je vidět jako acyklický graf (tj. veřejně existovalo více variant/větví sdíleného kódu):
• Každá větev (tj. „branch“) může mít svůj účel,
- např. stabilní/produkční kód bez známých chyb (tzv. „master“ větev), sdílený aktuálně vyvíjený kód (tzv. „development“ větev), kód v přípravě na konkrétní „release“ (odštěpením z „development“, tj. zmrazením, dokončený půjde do „master“), sdílený kód pro implementaci rysu, opravu chyby, čištění, atp. (feature, bug/hot-fix, clean-up, atp.; odštěpený z a tekoucí do různých větví)
* Vývojáři mohou lépe spolupracovat na sdíleném kódu. (větve, kde se spolupracuje, se sdílí) * Vlastníci kódu mohou lépe kontrolovat přijetí změn. (není třeba spěchat s aplikací změny; ta postupně probublává větvemi)
