Říká se, že každá chyba nalezená v softwaru je ta předposlední. Může to znít banálně, ale vystihujete to podstatu věci, totiž, že žádný známý dostatečně složitý software není bez chyb. Ale proč jsou v softwaru chyby? A jaké další problémy s vývojem softwaru úzce souvisejí?
Zásadní nedostatek tkví samozřejmě v tom, že software píšou lidé – a lidé dělají chyby. Z různých důvodů. Pojďme se podívat na některé zlozvyky programátorů – a na další chyby, které vznikají při realizaci vývojových projektů.
Než se začneme věnovat samotným vývojářům, zastavme se na chvíli u definice projektu. Nepůjde nám ani tak o definici požadavků na výsledný software, to by byl totiž námět na několik dalších článků, ale na požadavky týkající se cílových platforem.
Jestliže ještě v nedávné minulosti bylo časté zaměřit se na jednu platformu, kterou bylo klasické PC s Windows, dnes je stále více softwaru multiplatformního, a to především díky nástupu mobilních zařízení. Mnohé softwarové produkty je třeba ihned, nebo v průběhu času zrealizovat pro Android, iOS, Windows... Na přenositelnost je ovšem vhodné myslet už na začátku projektu, což se ovšem mnohdy neděje.
Především obecně platí, že zatímco části kódu jsou přenositelné jen obtížně – často jsou to ty, které bezprostředně souvisejí s uživatelským rozhraním a s hardwarem zařízení a s jeho ovládáním na dostatečně nízké úrovni, jiné části jsou přenositelné relativně snadno – typicky logika aplikace. A to navzdory faktu, že každá ze současných mobilních platforem používá jiný nativní programovací jazyk. Tyto části kódu je tedy rozhodně vhodné od sebe při vývoji důsledně oddělovat.
Přenositelnost lze rovněž podpořit používáním vhodných vývojových nástrojů. V případě byznys aplikací, kde mnohdy výkon nehraje takovou roli, jako u graficky náročných aplikací (her), mnohdy dává smysl využít takových nástrojů, které vývojáře zcela odstíní od cílové platformy – a jsou schopny generovat nativní kód pro všechny významné mobilní operační systémy. Přitom ještě zpravidla nabídnou rozsáhlé (a rozšiřitelné) knihovny funkcí, které vývoj dále usnadní.
O tom, že je třeba důsledně naplánovat architekturu programovaného řešení a poté stejně důsledně pořizovat dokumentaci, již bylo napsáno mnohé. Zde to tedy jen takto letmo připomeňme – a připomeňme rovněž vhodnost tvořit kód dostatečně modulární (ano, je to samozřejmost – ale vždy a všude?) a pojďme o krok dál, k samotnému tvoření kódu. Jaké jsou nejčastější chyby?
Překvapivě časté jsou podle odborníků překlepy v kódu. Jistě, některé snadno odhalí automatické nástroje již při tvorbě kódu, ale pokud se programátorovi podaří nešťastný překlep ve jméně proměnné, nebo v operátoru, je na problémy zaděláno. Nebo alespoň na zbytečné chvíle otravného ladění.
Jaké se nabízí řešení? Samozřejmostí by mělo být integrované vývojové prostředí (IDE), které překlepy pomáhá odhalovat, pomoci mohou i s rozmyslem volené názvy proměnných, kde si překlepů snadno všimnete. Nicméně v mnoha případech je jediným řešením prostě dostatečně soustředěná pozornost.
Jestliže ovšem výše zmiňujeme roli IDE, jedním dechem je třeba dodat: Nespoléhejte na něj příliš. To, že vám samo nabízí jména funkcí i proměnných, ještě neznamená, že nabízí ty správné. Je tak snadné bezmyšlenkovitě potvrdit první volbu...
Dbejte na to, aby měl tvořený kód určitou štábní kulturu. Odsazování řádků ve smyčkách a podmínkách není zbytečné a je vhodné ho v rámci celého projektového týmu dělat podle stejných pravidel. Stejnou samozřejmostí by měly být komentáře, a to samozřejmě nikoli typu „zde zvyšuji proměnnou a o jedničku“. To každý, kdo daný řádek kódu vidí, jistě chápe. Proč se ale toto zvýšení děje?
Dalším nikoli ojedinělým prohřeškem je zanedbání bezpečnosti. Citlivá data je třeba šifrovat, a to na všech úrovních, kde se s nimi pracuje. A hesla se nepíší do zdrojového kódu. Jistě, všichni to víme. Ale někdy je tak lákavé si zjednodušit si život, alespoň v první fázi kódování s tím, že v budoucnu se to určitě vyřeší jinak a lépe...
A ještě několik obecně platných poznámek na závěr: Myslete dopředu. Možný zádrhel, který vyřešíte už při návrhu, se vám nevymstí v půlce práce. Zjednodušení, ke kterému sáhnete na začátku kódování, může znamenat velké zpoždění v okamžiku, kdy se ukáže jako nevyhovující a je kvůli němu předělat spoustu dalších kusů kódu.
Plánujte dobu vývoje realisticky. A nespoléhejte příliš na to, že když dojde ke zpoždění, resp. k většímu zpoždění, než které už od počátku tak nějak čekáte, že prostě přidáte k projektovému týmu další lidi. Ukazuje se totiž, že než dosáhnou na neznámém projektu dostatečné efektivity, dojde k dalším časovým prodlevám.
V našem letošním letním speciálu se věnujeme různým pohledům na software, konkrétně na některé aspekty jeho vývoje a – to...
