Quo vadis, programování

Stejně jako mnohé jiné disciplíny i programování prodělalo v průběhu svého života řadu vln. Po prvních programát...


Stejně jako mnohé jiné disciplíny i programování prodělalo v průběhu svého
života řadu vln. Po prvních programátorských nadšencích, opojených samotnou
možností vysvětlit stroji, jak má pracovat a dokonce jak má přemýšlet, přišli
ke slovu praktici, kteří přemýšleli zejména nad tím, jak na tvorbě programů co
nejvíce vydělat.
Je ironií osudu, že na prosazení většiny pokrokových myšlenek mají největší
zásluhu právě tito praktici, kteří drží měšce, z nichž jsou programátoři
vypláceni. Většina těchto pokrokových myšlenek totiž vedla ve svém důsledku k
výraznému zvýšení produktivity práce a právě tento důvod vedl praktiky k tomu,
aby začali pokrokové techniky zavádět i přes odpor "opravdových" programátorů.
Než se rozhovoříme o vlastních technologických převratech v dějinách
programování, je třeba upozornit, že každá další novinka implicitně
předpokládá, že programátorská obec již akceptovala jejího předchůdce. Zvláště
je dobré si uvědomit, že nebudeme-li programovat strukturovaně, neměli bychom
se vůbec snažit o programování orientované objektově. Totéž platí o většině z
následně popisovaných etap. Vraťme se ale nejprve do historie a podívejme se na
první výrazné programátorské revoluce.

Vyšší jazyky
První vlaštovkou byl nástup vyšších programovacích jazyků. Tvůrci prvních verzí
jazyka Fortran se tak báli, že by jejich překladač nemuseli programátoři kvůli
snížené efektivitě výsledného kódu přijmout, že při překladu dokonce simulovali
běh programu, aby mohli optimálně přidělit registry procesoru. Když se později
používání vyšších jazyků prosadilo, soustředili se tvůrci překladačů spíše na
jiné vlastnosti jazyka, takže programy ve Fortranu IV z počátku 60. let byly
kupodivu pomalejší než programy ve Fortranu II z druhé poloviny let padesátých.

Modulární programování
Rozšiřující se nasazení počítačů umožnilo vývoj prvních velkých programů. Při
něm se ukázalo, že s rostoucí velikostí programů exponenciálně klesá
produktivita programátorů. Objevilo se modulární programování, které učilo, že
velké programy se mají rozbít na řadu relativně samostatných modulů, které o
sobě zveřejní jen přesně definované rozhraní, jehož prostřednictvím spolu budou
komunikovat.

Strukturované programování
Největší bouři vyvolaly v programátorském světě myšlenky strukturovaného
programování, které rozdělily programátorský svět na dva nesmiřitelné tábory,
jež Ed Post ve známém posteru (otištěném posléze v Datamation, 7/83 český
překlad viz například www.sh.cvut.cz/~robik/jokes/pascal .html) pojmenoval
"opravdoví programátoři" a "pojídači koláčů".
Strukturované programování definovalo několik základních pravidel, které
programátor musí při psaní programu dodržovat. Vedly se pak bouřlivé diskuse o
tom, lze-li za pomoci těchto pravidel napsat opravdu jakýkoliv program.
Diskutéři přitom často zapomínali na základní myšlenku, která stála v pozadí
celého hnutí za strukturované programování: "Piš program tak, aby jej po tobě
mohl kdokoliv (včetně tebe po letech) přečíst a pochopit."
Slovní přestřelky a vzájemné napadání ukončili opět "praktici", kteří
zareagovali na článek v IBM Journal of Research and Development, kde vedoucí
týmu, jenž vyvinul databázový systém pro New York Times, ukazoval, že přísné
dodržování zásad strukturovaného programování umožnilo jeho týmu přibližně
ztrojnásobení očekávané produktivity práce.

Orientace na objekty
Na počátku 80. let se objevila další novinka: OOP, tedy objektově orientované
programování. To se sice narodilo na přelomu šedesátých a sedmdesátých let, ale
mezi širokou programátorskou obcí se začalo prosazovat až v letech osmdesátých,
a to především zásluhou jazyka C++ (a částečně, zejména v Evropě, také zásluhou
objektových verzí jazyka Turbo Pascal), který umožňoval plynulý přechod od
klasického programování k programování objektově orientovanému.
Jak postavení OOP sílilo, začaly se jeho rysy objevovat ve všech rozšířených
programovacích jazycích. Své objektové verze postupně získalo nejenom C a
Pascal, ale i Fortran, Cobol, Ada, Forth a řada dalších firma Borland dokonce
začala v osmdesátých letech distribuovat objektově orientovaný assembler. OOP
se stalo pro některé zaklínadlem, pro jiné strašákem a pro další módní vlnou,
která opadne tak jako mnohé jiné. Zopakujme si, co OOP přináší a co vše má ve
svém důsledku vliv na zkrácení vývoje:
Zvýšení hladiny abstrakce, v níž uvažujeme o zadaném problému.
Zvýšení stability knihoven, které je důsledkem důsledného zapouzdřování
implementačních detailů a komunikace s klientskými programy pouze
prostřednictvím bezpečného rozhraní.
Zvýšení flexibility vyvinutého kódu díky možnému využití dědičnosti a
polymorfismu při doplňování stávajících knihoven o další funkce.
Zvýšení stability celého řešení rozdělení celého problému do tříd výrazně
snižuje objem kódu, který musí mít programátor při psaní programu na paměti, a
tím snižuje pravděpodobnost "výroby" chyb.
Objektově orientované programování se nyní používá v celém spektru
programátorských úloh od čipových karet a jednočipových mikropočítačů až po
rozsáhlé rezervační systémy, jejichž počítače jsou rozprostřené po celém světě.
Kritické aplikace si dnes už nikdo jinak než objektově naprogramovat nedovolí.
Od jisté míry "obludnosti" projektu totiž nelze jinak dostatečně spolehlivě
zabezpečit, aby byl program stabilní, robustní a bezpečný.

Návrhové vzory
V devadesátých letech se OOP stalo dominantní metodologií vývoje softwaru. Tomu
napomohlo dotažení metodiky objektově orientovaného návrhu a vydání několika
fundamentálních knih, které ukazovaly, jak lze objektově orientované programy
navrhovat efektivně. Klíčovou roli mezi nimi hraje bezesporu titul Design
Patterns, který se stal biblí všech programátorů-architektů (letos vyšel její
český překlad).
Autoři knihy Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides označovaní často jako "gang of four", v ní publikovali 23 základních
programových konstrukcí řešících nejčastější programátorské úlohy. Vytvořili
katalog objektově orientovaných řešení základních problémů, které jejich
následovníci již nemusejí objevovat, ale mohou je pouze aplikovat. Učinili tak
jeden z důležitých kroků k převodu programování ze sféry umění do sféry
technologie.
Časem se pak objevily publikace, shrnující základní návrhové vzory i v dalších
oblastech programování. Použití návrhových vzorů je jeden významných trendů
současného programování. Přináší s sebou dvě výhody:
Autor nemusí při návrhu programu vše znovu vymýšlet, ale může pouze vytáhnout
předpřipravené řešení z knihovny.
Při popisu architektury programu jinému programátorovi stačí pouze pojmenovat
použitý vzor (např. "třída je implementovaná jako jedináček") a druhému
programátorovi je bez dalšího vysvětlování hned jasná nejen rámcová
implementace, ale také to, co lze od této implementace požadovat a co od ní lze
očekávat.
Používání vzorů je krásnou implementací jedné ze základních myšlenek OOP:
"Řešení nemá být znovu objeveno, ale znovu použito." Všechny klíčové vlastnosti
OOP, tj. zapouzdření, dědičnost a polymorfismus, slouží právě tomu, aby jednou
napsaný kód bylo možno co nejsnadněji kdykoliv znovu použít, aniž by jej bylo
nutno upravovat. Vzory pak tuto myšlenku staví na vyšší úroveň.

Nové jazyky a platformy
Dalším důležitým stimulem nástupu OOP bylo masové rozšíření jazyka Java, který
se postupně stal nejrozšířenějším programovacím jazykem dokonce se mu podařilo
vytlačit z této pozice i dosavadního krále Visual Basic (viz
www.sdtimes.com/news/057/ story7.htm). Java se ukázala jako téměř optimální
jazyk pro výuku programování: Je jednoduchá, objektová orientace je v ní dobře
implementovaná, je zadarmo a běhá prakticky všude. Proto se také na většině
světových univerzit stala hlavním jazykem výuky programování.
Java začala postupně nahrazovat C++ v dalších a dalších oblastech jeho do té
doby zdánlivě neotřesitelného království. V současné době se Java (a objektově
orientované programování obecně) používá v aplikacích všech velikostí od
čipových karet až po rozsáhlé distribuované systémy běžící na několika
počítačích.
Důvodů pro nasazení Javy v praxi bylo několik. Jedním bylo přibližně
zdvojnásobení produktivity programátorské práce oproti obdobnému vývoji v C++,
druhým byla její multiplatformnost: program stačilo napsat a odladit jen jednou
a pak již bylo možno jej spouštět na všech platformách (tj. kombinacích
hardwaru a operačního systému), na nichž byla implementována. Za tento dvojí
nárůst produktivity jí byli manažeři softwarových společností ochotni odpustit
i některé její počáteční nedostatky.
Neměli bychom však zapomínat na další důležitý moment: sílící potřebu řady
firem nasadit velké distribuované aplikace řešící strategické oblasti života
firmy. Tady se Java ukázala jako velice výhodné řešení. Tuto potřebu vycítila
firma Sun Microsystems, když na jaře 1999 ohlásila tři platformy Javy a mezi
nimi především platformu J2EE (Java 2 Enterprise Edition), určenou právě pro
distribuované systémy. Tato platforma syntetizovala do té doby roztříštěné
směry a nabídla vývojářům společný základ pro další vývoj.
Distribuované aplikace začaly postupně zaměstnávat většinu vývojářských
kapacit. Pokud Microsoft nechtěl, aby mu ujel vlak, musel vytáhnout do
protiútoku: přišel proto s vlastní verzí obdobného řešení, přičemž se snažil
zachovat vše, co se osvědčilo. Jako protiváhu triumvirátu Java VM J2EE uvedl na
trh obdobný triumvirát C# CLR .Net.
Cílem článku není posuzovat, která koncepce je lepší a v čem. Podívejme se, co
mají obě koncepce společné a co tu s námi pravděpodobně ještě chvíli zůstane.
Jazyk: Použitý programovací jazyk je důsledně objektově orientovaný. Oproti C++
zavádí speciální typ třídy označované jako rozhraní, automatickou správu
dynamické paměti (garbage collector) a zavádí zpracování výjimek a paralelních
procesů přímo v definici jazyka.
Nutnost důsledné objektové orientace uváděné platformy dokonce přinutila
Microsoft opustit původní Visual Basic a vytvořit nový, objektově orientovaný
jazyk, který sice vychází ze syntaxe původního Visual Basicu, ale je to opravdu
nový jazyk. (Původní Visual Basic sice s objekty pracoval, ale objektově
orientovaný nebyl.)
Microsoft tím připravil řadě programátorů obrovské dilema: Buďto musejí
vstřebat pro ně naprosto nové paradigma objektově orientovaného programování,
nebo musejí oželet moderní trendy, zůstat u původního Visual Basicu a smířit se
s tím, že se tento jazyk už dále rozvíjet nebude.
Virtuální stroj: Zdrojový kód se nepřekládá do strojového kódu, ale pouze do
mezikódu, který se při spuštění programu předá speciálnímu programu označovaném
jako virtuální stroj, jenž tento mezikód interpretuje. To má dvě klíčové výhody:
Daleko snáze se dosahuje platformní nezávislosti, protože stačí na novou
platformu implementovat virtuální stroj, a všechny programy pak na ní běží.
Současné virtuální stroje dokáží zjistit, které části kódu se budou provádět
vícekrát, a je proto výhodné si je někam stranou přeložit, a které části kódu
se překládat nevyplácí a stačí je pouze interpretovat. Při překladu jsou
schopny vycházet ze svých zkušeností z dosavadního běhu kódu a překlad
dynamicky optimalizovat, takže v některých případech je běh těchto
"interpretovaných" programů rychlejší, než běh ekvivalentních programů
překládaných, protože ty mohl překladač optimalizovat pouze staticky.
Často se lze setkat s tvrzením, že platforma Java nabízí jediný jazyk, kdežto
pro platformu .Net jsou k dispozici 4 jazyky (C#, VB, C++ a JavaScript) a jsou
připravovány další celkem asi 20. Z toho, co zde bylo doposud napsáno, je
jasné, že stejná koncepce vede i ke stejným možnostem. Není problém vyrobit
překladač jiného jazyka do bajt-kódu, jenže programátoři si Javu tak oblíbili,
že nevidí důvod, proč ji opouštět.
Platforma: Celá platforma poskytuje nástroje a prostředky k tomu, aby bylo
možno co nejsnadněji vyvíjet distribuované aplikace, jejichž jednotlivé části
komunikují prostřednictvím standardizovaných protokolů a díky internetu je lze
umístit prakticky kdekoliv. U obou platforem je přitom patrný silný důraz na
implementaci prostředků umožňujících vývoj webových služeb.

Distribuované systémy
Dlouhou dobu byla tvorba rozsáhlých distribuovaných systémů považována za
okrajovou oblast programování, která je vysoce náročná, a proto se jí věnuje
pouze hrstka specialistů. Poslední dobou se však dostal vývoj tohoto druhu
aplikací do hlavního proudu a většina programátorů dnes pracuje právě na vývoji
těchto rozsáhlých systémů.
S nástupem nových technologií a myšlenky webových služeb tento trend ještě více
sílí. Mohli bychom říci, že většina myslitelných aplikací pro desktopy (myslím
tím aplikací, na nichž se dá vydělat) již byla "rozebrána" a že v budoucnosti
lze očekávat rozumné zisky právě na dosud nepříliš zoraném poli distribuovaných
systémů.
Ostatně obě výše jmenované soupeřící platformy, tj. J2EE a .Net, byly vyvinuty
právě proto, aby umožnily tvorbu takovýchto systémů (přesněji řečeno, byly
vyvinuty proto, že se jejich mateřské firmy domnívaly, že v této oblasti na ně
čekají velké peníze a měly pravdu).

Komponenty
Vraťme se ještě jednou k Visual Basicu jemu totiž patří zásluha za to, že na
počátku devadesátých let uvedl mezi širokou programátorskou veřejnost
komponentové programování.
Komponenty jsou vlastně dotažené moduly. Jsou to objekty schopné relativně
samostatného života a bezproblémového použití v nejrůznějších aplikacích. Na
počátku byly komponenty používány zejména k usnadnění návrhu grafického
uživatelského rozhraní (komponentou bylo např. tlačítko, zaškrtávací políčko
nebo seznam), ale časem se koncept komponent zobecnil a nyní jsou jako
komponenty vyvíjeny např. části, z nichž jsou skládány rozsáhlé distribuované
systémy.

XML
Zajímavým fenoménem posledních let je nástup XML, které se prosadilo nejen jako
univerzální "dorozumívací jazyk" komunikujících počítačů. Na XML je nyní
založena řada komunikačních protokolů mezi jednotlivými částmi distribuovaných
systémů a zejména pak protokoly pro vzájemnou komunikaci mezi různými systémy.
Pomocí XML ale komunikují systémy nejenom vzájemně, ale také samy se sebou. Ve
formátu XML jsou totiž stále častěji ukládány instalační a konfigurační
parametry aplikací. Hlavní výhodou tohoto řešení je, že při jakýchkoliv
problémech se systémem jsou k dispozici soubory v čitelné podobě, v nichž se
lze dopátrat informací, k nimž jsme se donedávna probojovávali jen velice těžko.

UML
V našem přehledu událostí posledních let bychom neměli zapomenout na vznik a
rozšíření grafického jazyka UML, který se postupně stal standardem, v němž jsou
zobrazovány návrhy programů v učebnicích i v praxi. Tento jazyk sjednotil
doposud roztříštěné způsoby zápisu jednotlivých etap vývoje programů a jeho
autoři jej doplnili i velice komplexní metodikou, jak program navrhovat a řídit
jeho návrh, vývoj i následné nasazení.
Architekti ani vedoucí týmů se již bez znalosti tohoto jazyka neobejdou a v
souvislosti s jeho postupným začleňováním do vývojových nástrojů se brzy stane
každodenním nástrojem i pro běžné programátory.

Automatizace vývoje
Stále více se prosazují nejrůznější systémy automatizující tvorbu programů.
Roste obliba systémů, které jsou schopny převést UML diagram na funkční program
a naopak z programu vytvořit jeho UML diagram. Vývojář si pak může vybrat,
jestli je pro něj v daném okamžiku výhodnější psát přímo kód anebo modifikovat
UML diagram.
Vlastnosti současných objektově orientovaných jazyků a jejich platforem tak
vlastně umožňují, aby program sám vytvářel nový program. Současná vývojová
prostředí již nabízejí bohaté sady "průvodců", kteří po zadání několika
parametrů vytvoří relativně rozsáhlé části programu, do kterých pak programátor
doplní pouze specifické části řešící speciální úkoly.
Začínají se objevovat i systémy, jimž pouze popíšete, jaké má mít výsledná
aplikace vlastnosti, a ony sami prakticky celou aplikaci vygenerují a na
vývojářích nechají pouze doprogramování některých specialit.
Programování udělalo další velký krok od umění směrem k technologii a profese
programátora se tak stále více blíží profesím konstruktérů jiných typů
zařízení. Návrhové vzory, komponenty a stále rozsáhlejší a komplexnější
standardní knihovny nabízejí obrovskou paletu "katalogizovaných řešení", které
by měl programátor znát a z nichž svá řešení sestavuje.

Agilní metodiky
Myšlenky a proudy, které výrazně ovlivňují celé odvětví, nevzniknou vždy jako
výsledek nějakého cíleného výzkumu, ale často také jako výsledek empirie a
experimentů programátorských týmů. Mezi takovéto proudy bychom mohli zařadit
také stále více se prosazující agilní metodiky, z nichž nejznámější je extrémní
programování. Extrémní se přitom jmenuje proto, že autoři všechny zásady
správného návrhu programu dotáhli až do extrémů. Zmiňme se zde o dvou novinkách
zavedených extrémními vývojáři, které výrazně ovlivnily i ty, kdo extrémně
neprogramují.

Automatické testování
Jednou z převratných myšlenek extrémního programování je zásada, že při vývoji
programů je třeba nejprve napsat testy vyvíjeného programu a teprve pak začít
vytvářet vlastní program. Objevily se dokonce i nástroje, které takovýto
přístup maximálně usnadňují. Z nich nejslavnější je JUnit (www.junit.org),
který byl původně vyvinut pro Javu, ale postupně vznikají jeho deriváty určené
pro další a další jazyky. Ne všichni jsou ochotni psát testy dříve než vlastní
program, nicméně programy umožňující automatické testování vytvořeného kódu
jsou stále oblíbenější a řada programátorů si již svůj život bez nich dokáže
těžko představit.

Refaktorizace
Dalším zásadním přínosem extrémního programování je, že zrušilo mýtus o tom, že
cena změny nepříjemně (někdo tvrdí exponenciálně) roste s dobou jejího
zapracování do systému (jinými slovy: změna, která mne ve fázi analýzy přijde
na pár set korun mne v závěrečných fázích vývoje velkého projektu může přijít
na pár desítek tisíc).
Extrémní programátoři nespekulují nad tím, co bude potřeba udělat zítra, a řeší
dnes pouze to, co je potřeba udělat dnes. Spoléhají přitom na to, že budou
kdykoliv schopni svůj program upravit tak, aby zahrnul jakékoliv nově vzniklé
požadavky a kupodivu se jim to opravdu daří.
Refaktorizací kódu chápeme jeho úpravy, při kterých se změní (pokud možno
směrem k lepšímu) vnitřní struktura programu při zachování veškeré jeho
funkčnosti. Toto umění se snaží si osvojit i programátoři, kteří extrémně
programovat nehodlají. Všichni totiž jednou za čas musíme svůj program
přebudovat tak, aby se nám lépe udržoval a případně i rozšiřoval. Refaktorizace
bez nástrojů, které ji automatizují, je však čirý masochizmus. Proto se
refaktorizační nástroje intenzivně vyvíjejí a zlepšují a jejich přítomnost se
stala důležitým kritériem kvality vývojových prostředí.

Programování malých systémů
Sílící zájem je možné pozorovat i na druhém konci spektra u programování
jednočipových počítačů a telefonů. I to bylo donedávna považováno za
vnitropodnikovou záležitost příslušných výrobců. Nástup platformy J2ME však
rozpoutal obrovský boom vývoje programů pro mobilní telefony, které budou jistě
záhy následovány dalšími zařízeními.
Prozatím jsou z těchto aplikací známé většinou pouze hry, ale objevilo se již i
pár zajímavých praktických aplikací. Hlavní proud aplikací pro mobilní telefony
však nepůjde cestou her ani cestou lokálních aplikací uzavřených uvnitř
telefonu. Největší peníze, a tím i největší zájem vývojářů lze očekávat v
oblasti aplikací, v nichž bude telefon sloužit pouze jako vzdálený terminál
(tenký klient) pro aplikace běžící na serveru. Terminál, jehož prostřednictvím
vám budou tyto servery nabízet svůj výpočetní výkon, přístup ke svým databázím
a řadu dalších služeb.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.