Obsah
- Agilní programování
- Extremní programování (Extreme Programming, XP)
- KISS (Keep It Simple, Stupid)
- Refaktoring
- Programování řízené testy (Test-drive Development, TDD)
- Systémy správy verzí
- Správa sestavování - Ant
- Maven
- Motivace
- Maven - charakteristika
- Project Object Model (POM)
- Projekt v Mavenu
- Maven repository
- Instalace a nastavení
- Příklad POM (project.xml)
- Příklad POM - pokračování
- Struktura POM obecně
- Proměnné (properties) v POM
- Struktura repository
- Cíle v Mavenu
- Maven Plugins
- Často používané cíle
- Vytvoření projektu
- Reporting
- Rozšíření možností Mavenu
Agilní programování (Agile Programming, AP) je relativně novým přístupem k vývoji software.
-
Není to jedna metodika, přesný návod, jak systém navrhnout a realizovat.
-
Je to spíše přístup, "filozofie", do které je třeba dodat konkrétní postupy pro jednotlivé úkony vývoje.
-
Označení Agilní programování bylo poprvé zavedeno skupinou autoritativních odborníků (praktiků) na SW metodiky.
-
Zastánci AP se sdružili při sestavení manifestu AP, formulující jeho hlavní zásady.
„We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: “
„Individuals and interactions over processes and tools“
„Working software over comprehensive documentation“
„Customer collaboration over contract negotiation“
„Responding to change over following a plan “
„That is, while there is value in the items on the right, we value the items on the left more.“
Motivací pro AP byla především řada neúspěchů při budování rozsáhlých softwarových děl a řízení realizačních projektů.
-
Projekty trvaly déle, než se předpokládalo.
-
Stály více peněz.
-
Objevovala se negativa typu "hraní na úspěch/výsledek" a nikoli výsledek sám.
-
K cíli se nešlo přímočaře, produkovaly se dále nevyužité (nevyužitelné) artefakty, věci do zásoby.
-
Mezi zadavatelem (zákazníkem) a tvůrcem byla propast (formalizmus místo spolupráce).
-
Vytvořené produkty pak často neodpovídaly aktuální potřebě...
Namísto jednorázového (obvykle složitého) jednání o smlouvách s přesnou (a v podstatě statickou) specifikací zadání:
Na vývoj software má vliv mnoho faktorů, které se neustále mění (zadání, návrh, technologie, trh, složení týmu apod.). Obecně lze říci, že změna je jedinou konstantou vývoje software. Problémem vývoje softwaru je schopnost úspěšného zvládnutí těchto změn za přijatelné náklady.
Od ostatních metodik se XP odlišuje v následujících vlastnostech:
- Automatizované testování
-
testy jsou tvořeny před samotnou tvorbou zdrojového textu za účelem následného ověření skutečného pokroku ve vývoji softwaru z hlediska jeho požadované funkcionality (testy navrhuje zákazník) a architektury programového modulu (testy navrhuje programátor).
- Verbální komunikace
-
společně s testy a zdrojovým textem slouží ke sdělování systémové struktury a záměru projektu.
- Intuice
-
Postupy, které podporují intuici programátorů a dlouhodobé zájmy projektu (testování, refaktorizace, integrace apod.).
- Komunikace
-
Udržení řádných komunikačních toků ovlivňuje kvalitu jednotlivých postupů XP (testování modulů, párové programování, stanovení metrik apod.).
- Jednoduchost
-
Vývoj software je řízen zásadou, že je lepší udělat jednoduchou věc dnes, s vědomím, že zítra bude možná nutné provést další změnu, spíše než udělat složitější změnu dnes, která nemusí být uživatelem využita. Jednoduchost a komunikace jsou spolu komplementární. Čím více tým komunikuje, tím je mu jasnější co přesně má dělat. Naopak čím je jednodušší systém, tím méně potřebujeme komunikovat.
- Odvaha
-
Členové týmu jsou ochotni experimentovat s vyšším rizikem a ziskem.
- Hraní na výhru
-
představuje soustředění práce týmu na kvalitu vyvíjeného produktu, nikoli na zbytečné alibistické činnosti, kdy tým pracuje „podle předpisů“ (mnoho papírů a porad), aby se tzv. „neprohrálo“.
- Konkrétní experimenty
-
kdy všechna abstraktní rozhodnutí by měla být převedena do řady experimentů, které jsou následně otestovány.
- Práce v souladu s lidskými instinkty
-
a nikoli proti nim představuje práci s krátkodobými zájmy lidí, kteří se rádi učí, vyhrávají, komunikují s ostatními apod.
- Cestování nalehko
-
představuje hodnotné a účinné nástroje vývoje softwaru, které tvoří především testy a zdrojový text.
-
Plánovací hra stanoví šíři zadání následující verze software pomocí kombinace obchodních priorit a technických odhadů.
-
Malá verze představuje rychlé uvedení jednoduchého systému do provozu. Následně jsou uvolňovány malé přírůstky systému ve velmi krátkých cyklech.
-
Metafora pomáhá všem v projektu pochopit základní prvky systému a vztahy mezi nimi na základě jednoduchého přirovnání.
-
Jednoduchý návrh u něhož je nadbytečná složitost ihned odstraněna v okamžiku jejího zjištění z návrhu.
-
Testování představuje činnost programátorů a zákazníků, kdy programátoři testují zdrojový text z hlediska jeho programových vlastností, aby mohli pokračovat v jeho dalším psaní, a kdy uživatelé otestují funkcionalitu modulu, která je úspěšným provedením testu dokončena.
-
Refaktorizace představuje restrukturalizaci systému s cílem zdokonalení jeho nefunkčních kvalit (pružnost, zjednodušení) bez vlivu na jeho chování.
-
Párové programování představuje vývoj zdrojového textu dvěma programátory na jednom počítači.
-
Společné vlastnictví
-
Nepřetržitá integrace - okamžitá integrace dokončeného otestovaného přírůstku do systému.
-
40 hodinový týden plus se nepracuje nikdy přesčas dva týdny za sebou.
-
Zákazník na pracovišti - odpovídá na otázky programátorů při vývoji software.
-
Standardy pro psaní zdrojového textu
- Plánování
-
představuje stanovení termínu programátory společně se zákazníky na základě postupu plánovací hry. Do uvolnění první verze by mělo trvat mezi dvěma až šesti měsíci.
- Smrt
-
představuje stav systému, kdy je software neschopen své existence z důvodu neekonomického rozšíření jeho funkcionality, entropie (tendence k většímu počtu chyb). Zákazníci i manažeři by měli souhlasit s ukončením údržby systému s tím, že se snaží identifikovat příčiny zániku systému.
Netýká se jen programování, je to obecný princip vývoje či realizace čehokoli.
Snahou je produkovat co nejjednodušeji, bez zbytečností, bez nadbytečností, s minimem chyb.
KISS přístup patří do základního arzenálu Agilního programování.
Ideovými předchůdci principu jsou např.:
-
tzv. Occamova břitva (Occam's Razor)
-
Klasický způsobe vývoje SW předpokládá testování jako následnou fázi - testy se píší a spouštějí až po návrhu software
-
To je však paradoxní, protože návrh testů vychází - stejně jako návrh vlastního kódu - ze specifikace a to dokonce přímočařeji. Test je přímý odraz specifikace, protože programovým kódem hlídá chování, které je specifikací očekáváno.
-
Programování řízené testy proto předřazuje návrh a implementaci testů před vývoj vlastního SW.
-
Jde o metodiku vývoje samotného SW, ne testů.
-
Napsat test - na základě specifikace (požadavků) reprezentovaných např. případy užití (usecases).
Test bude používat samotný kód prostřednictvím rozhraní.
-
Napsat kód - aby splnil specifikaci a komunikoval se světem pomocí rozhraní (API).
-
Spustit automatizované testy.
-
V případě chyb kód přeprogramovat (refactoring) a
-
spustit testy znovu.
některé převzaty z Wikipedie, hesla Test-driven Development:
- commit
- publikuje (odešle, potvrdí) změny z lokálního pracovního prostoru do skladu (repository)
- remove
- maže soubory z lokálního pracovního adresáře, ze skladu se smažou až po "commit"
- add
- přidá nový soubor do pracovního adresáře, do skladu se přidají až po "commit"
- update
- aktualizuje lokální kopii pomocí změn zaregistrovaných ostatními ve skladu
- ckeckout
- vytvoří soukromou lokální kopii požadovaných souborů ze skladu, tyto můžeme lokálně editovat a posléze potvrdit (commit) zpět
![[Varování]](http://www.fi.muni.cz/~tomp/slides/images/warning.png)
Pro sestavování, správu a údržbu SW projektů menšího a středního rozsahu se delší dobu úspěšně využíval systém Ant.
Oproti klasickým nástrojům typu unixového make poskytoval Ant platformově nezávislou možnost popsat i složité postupy sestavení, testování a nasazení výsledků SW projektu.
-
pro každý projekt (i když už jsme podobný řešili) musíme znovu sestavit - poměrně velmi technický - popisovač (
build.xml
) -
popisovač je vždy téměř stejný a tudíž
-
neříká nic o obsahu vlastního projektu, je jen o procesu sestavení, nasazení...
-
neumožňoval zachytit metadata nezbytná pro zařazení projektu do širšího kontextu, mezi související projekty, atd.
-
nástroj řízení SW projektů
-
open-source, součást skupiny nástrojů kolem Apache
-
dostupný a popsaný na http://maven.apache.org
-
momentálně (září 2004) již jako použitelná, ostrá, verze 1.0
-
projekt řízený Mavenem je popsán tzv. POM (Project Object Model), obvykle
project.xml -
POM nepopisuje postup sestavení, ale obsah projektu, jeho název, autora, umístění, licenci...
-
postup sestavení je "zadrátován" v Mavenu, protože je pro většinu projektů stejný
-
programátor není frustrován opakováním psaní popisovačů
build.xml, návrhem adresářové
struktury... -
nicméně, Maven je založen na Ant, jeho
build.xml popisovače lze znovupoužít
-
základním organizačním nástrojem pro správu vytvořených (nebo používaných) artefaktů je repository
-
artefakt, tj. výstup projektu, se může v repository vyskytovat ve více verzích
-
repository je:
- vzdálená (remote)
-
slouží k centralizovanému umisťování jak vytvořených, tak používaných artefaktů
dosažitelná pro čtení pomocí HTTP: je to de-facto běžné webové místo
- lokální (local)
-
slouží k ozrcadlení používaných artefaktů ze vzdálené repository
typicky zvlášt každému uživateli - v jeho domovském adresáři
slouží též k vystavení vytvořených artefaktů "pro vlastní potřebu"
-
Maven má nástroje (pluginy) pro vystavování artefaktů do repository
Maven lze stáhnout z http://maven.apache.org v binární i zdrojové distribuci.
Binární distribuce je buďto čistě "java-based" nebo ve formě
windowsového .exe.
Pak se nainstaluje do Program Files
Po instalace je třeba nastavit proměnnou prostředí
MAVEN_HOME na adresář, kam se nainstaloval.
Kromě toho ještě přidat adresář
%MAVEN_HOME%\bin do
PATH.
Příklad minimálního popisovače
project.xml:
<project>
<pomVersion>3</pomVersion><!-- verze POM - zatím vždy 3 -->
<id>RunningCalculator</id><!-- jednoznačné id projektu -->
<name>RunningCalculator</name><!-- (krátké) jméno/nemusí být jednoznačné -->
<currentVersion>0.1</currentVersion><!-- momentální verze -->
<organization><!-- organizace vytvářející projekt -->
<name>Object Computing, Inc.</name>
</organization>
<inceptionYear>2004</inceptionYear><!-- rok zahájení projektu -->
<shortDescription>calculates running pace</shortDescription><!-- stručný popis -->
<developers/>
Příklad minimálního popisovače
project.xml:
<dependencies><!-- závislosti -->
<dependency><!-- závislost -->
<groupId>junit</groupId><!-- skupina artefaktu -->
<artifactId>junit</artifactId><!-- označení artefaktu -->
<version>3.8.1</version><!-- verze artefaktu -->
</dependency>
</dependencies>
<build><!-- odkud se co a jak sestavuje... -->
<sourceDirectory>src/java</sourceDirectory><!-- adresář zdrojů -->
<unitTestSourceDirectory>src/test</unitTestSourceDirectory><!-- adresář zdrojů testů -->
<unitTest><!-- které soubory jsou třídy testů -->
<includes>
<include>**/*Test.java</include>
</includes>
</unitTest>
</build>
</project>
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="MAVEN_HOME/maven-project.xsd">
<pomVersion>3</pomVersion>
<id>unique-project-id</id>
<name>project-name</name>
<groupId>repository-directory-name</groupId>
<currentVersion>version</currentVersion>
<!-- Management Section -->
<!-- Dependency Section -->
<!-- Build Section -->
<!-- Reports Section -->
</project>
-
Jsou podobně jako u Antu definovatelné a využitelné (odkazovatelné) v popisovači, zde
project.xml. -
Vyskytne-li se zavedení určité vlastnosti (property) vícekrát, uplatní se poslední.
-
Vlastnosti jsou vyhledávány v pořadí:
-
vlastnosti specifikované na příkazové řádce -D
key=value
-
Na vlastnost se lze odvolat pomocí
${property-name}
Týká se jak vzdálené, tak lokální repository.
Obecně je relativní cesta v rámci repository k hledanému
artefaktu:
repository/resource-directory/jars/jar-file
Cíle (goals) v Mavenu odpovídají zhruba antovým cílům (target).
Spouštění Mavenu vlastně odpovídá příkazu k dosažení cíle ("attaining the goal"):
Zásuvné moduly (plugins) obsahují předdefinované cíle (goals) a jsou taktéž uloženy v repository.
Většinou jsou jednoúčelové, slouží/směřují k jednomu typu artefaktu, např.:
- clean
-
smaže vygenerované soubory (podstrom
target) - java:compile
-
přeloží všechny javové zdroje
- test
-
spustí všechny testy
- site
-
vygeneruje webové sídlo projektu
- dist
-
vygeneruje kompletní distribuci
-
vytvořit prázdný adresář pro vytvářený projekt
-
spustit maven genapp
(Zeptá se na id
projektu, jeho jméno a hlavní balík. V něm předgeneruje jednu
třídu.) -
tím se vytvoří následující soubory:
-
project.xml, project.properties
-
src/conf/app.properties
-
src/java/
package-dirs/App.java -
src/test/
package-dirs/AbstractTestCase.java -
src/test/
package-dirs/AppTest.java -
src/test/
package-dirs/NaughtyTest.java
-
Generování reportů (zpráv) je jednou se základních funkcí Mavenu.
Které reporty se generují, je regulováno v project.xml v sekci reports:
<reports>
<report>maven-checkstyle-plugin</report>
<report>maven-javadoc-plugin</report>
<report>maven-junit-report-plugin</report>
</reports>
Cílů (goals) je sice v Mavenu řada, ale přesto nemusejí stačit anebo je třeba měnit jejich implicitní chování.
Potom lze před nebo po určitý cíl připojit další cíl pomocí preGoal a postGoal.
Ty se specifikují buďto v nebo.
-
maven.xml ve stejném adresáři jako
project.xml nebo -
v zásuvném modulu (pluginu)
Zcela nové cíle je možné napsat ve skriptovacím jazyku jelly (s XML syntaxí).