Úvod

„Vysvětli mi, proč věnovat čas a úsilí architektuře a návrhu kódu při vývoji PHP webového projektu?“ ptal se mě jeden IT manažer, který neprogramuje, ale všeobecný technický i programátorský background má. Na hrbu nese jednu starší PHP aplikaci psanou strukturovaně bez „dobrých návyků“.

Po malých krůčcích bych ráda objasnila, jak nějaké ty dobré návyky zavést. Možná inspiruji také vývojáře začátečníka či toho, co tyto věci nezná, nebo se je bojí implementovat.

Upozornění! V článku nenarazíte na odborné poučky. Forma článku je lidská, aby mu porozuměl i takový IT manažer. To je důležité, protože o nás vývojářích a životech aplikací, na kterých pracujeme, rozhoduje.

Musíme pracovat s tím, co máme

V reálném prostředí dostaneme nějaké vstupní podmínky, přesto je v silách každého vývojáře držet se alespoň průměrného proudu.

Vývoj většiny PHP webových aplikací se bohatě obejde bez kryptografických a nadpřirozených schopností programátora. Skromně si vystačí s několika osvědčenými technikami a nástroji, jež se nevyplácí opomíjet. Lze tak snížit náklady – minimalizovat chybovost, časovou náročnost, usnadnit a zpříjemnit práci celému týmu.

Hned v úvodu zmíním důvěryhodnost kódu, protože tu může bez většího úsilí zcela zásadně ovlivnit každý programátor. Co si představit pod tímto pojmem?

Třeba, že kód nelže …

Důvěřuj, ale prověřuj není totiž rčení vhodné pro programátorskou praxi. Zjednodušeně řečeno, proměnná $zastupci vrací zástupce a proměnná $podrizeni vrací podřízené. Člověk se může spolehnout na to, co čte. Použije-li vývojář k psaní kódu chytrý nástroj, přejmenování je záležitostí chvilky.

Dobrá orientace také není k zahození. Nahlédnete-li do aplikace a nemáte potíž zorientovat se v jejích částech, to se hodí v každém okamžiku. Navigací mohou být adresářová struktura, namespace či návrhové vzory.

Návrhové vzory? O co vlastně jde?

Vyskytují se všude kolem nás a jeden se pomalu ostýchá, nezná-li nějaký.

Jde o předpřipravená řešení k implementaci určitého konkrétního případu. Chci-li získat z databáze data o uživateli, postará se o to nejspíše Repository, konkrétně se může jednat o třídu UserRepository.

A k čemu návrhové vzory slouží?

Umožňují sestavit kód dle pravidel či názvosloví. Vývojář pak často jen z názvu souboru ví, jak se kód chová. Zná-li návrhový vzor, nemusí vymýšlet implementaci, stačí implementovat existující. Guru přes návrhové vzory je Martin Fowler.

Šetřeme zdroje

Neplýtvejme úsilím tam, kde je to zbytečné. Především energií – lidskou energií.

Méně bývá někdy více

Gró programátora je jeho hlava – nikoliv ruce. Snaží se chytře napsat jednu věc – co možná nejúsporněji. Použít ji může na více místech. U případné změny úprava bude pouze jedenkrát. Jde o princip odborně nazvaný DRY – Don’t repeat yourself (tj. „Neopakuj se“).

Šetřeme i tu hlavu – není zapotřebí objevovat Ameriku …

Jako do zemědělství přišla mechanizace a usnadnila lidem práci, také tvorba aplikací v dnešní době zaznamenává shodný proces. Existují nástroje šetřící práci vývojáře. Příkladem mohou být třeba frameworky. Mají implementovanou funkcionalitu, co programátoři používají stále dokola – jako je práce s formuláři, routování, sessions, validace, vykreslení dat, zabezpečení, práce s databází … Pro PHP je dostupný Packagist, což je aplikace k dohledání PHP knihoven.

Design principles

Používáme-li návrhové vzory, jen o krůček vpředu potkáme design principles. Tyto principy byly vymyšleny proto, aby kód byl jednoduchý, dobře udržovatelný, rozšiřitelný, modifikovatelný, přehledný a výkonný. Hojně skloňovaným příkladem je SOLID od Uncle Boba, který je vzorem snad každého vývojáře.

Pocit bezpečí

Ve škole nás učili, že program bez chyby neexistuje. Ověření, že stránky vracejí správný HTTP status (třeba 200), se hodí před každým novým releasem. Test lze vytvořit s minimálním úsilím. Dobrý nástroj pro nejen takové testování je Codeception. Kolem testování je nyní velký ruch. Někdo potřebuje mít pokrytí na procenta, jiný netestuje, další dle svého svědomí či citu. Jde o individuální přístup daného projektu případně vývojáře. Ať je to jak chce, čím větší jistoty nabudete v testech, tím větší ji získáte v provádění změn.

Když nevíš, přečti si návod

Nemusí se nutně jednat o román, ale mám ráda po ruce nějakou tu dokumentaci. Bohatě mi vystačí stručné jasné informace o na první pohled nejasných souvislostech. Pokud hoří, je dobré mít po ruce nějaký ten hasící přístroj. Mohu uvést příklad ze života, kdy mi chybělo info, kde se spouští automatizované úlohy. Jsou-li v aplikaci black boxy, dokumentace může ušetřit mnoho času tápání.

Z hluboké propasti se leze těžko ven a ne všem se to podaří

V IT plyne čas rychleji než jak koluje pornočasopis v kláštěře. Co jsme vytvořili před několika lety, je z dnešního hlediska technologický pravěk. K běžné pracovní náplni vývojáře patří zavádění novějších technologií. Co si budeme povídat, aplikace s námi nějakou dobu žijí a my se o ně musíme starat. Většina žijících zastaralých aplikací technologický dluh dřív či později musí řešit. Bezpečnější, příjemnější a levnější je vydat se cestou pravidelných menších kroků.

Jak naložit s nevzhlednou aplikací? … co není čitelná, lehce modifikovatelná, bez testů?

Záleží na zdrojích. I za běžného provozu lze provádět malá zlepšení. V rámci změnových požadavků například provádím malé úpravy vedoucí k zlepšení bez změny funkcionality. Tento proces se nazývá refactoring. Doporučuji co nejvíce oddělit refactoring backgroundu od vzhledu. Můžete aplikaci mnohokrát zrychlit, zjednodušit, ale pokud změníte vzhled či design, uživatelé mohou být velmi zmatení. Případné chyby se špatně dohledávají a řeší. Uživatel je zmaten změnou designu, často nedokáže chybu správně popsat.

Jak může být vývojář efektivní, má-li přemýšlet o těchto věcech? Neměl by raději místo toho programovat?

Práce programátora nespočívá v produkci řádek kódu, ale vytváření chytrého řešení zadaného úkolu.

Jak to?

Je mnohem levnější pracovat na projektu, který lze jednoduše a bezpečně modifikovat a rozšiřovat, než luštit dlouhé texty hieroglyfy.

Co když budu muset změnit dodavatele – vývojářský tým?

Rozumně napsaný program by nemělo být zas takový problém předat jinému vývojáři, či týmu, co umí dané technologie.

Zákon padajícího

Špatný kód se často dědí z generace na generaci a činí mnoho lidí nešťastných. Nejen programátorů, ale i manažerů, investorů, personalistů…

Kdo uteče, vyhraje

Znám několik vývojářů, co změnili práci právě kvůli špatně napsanému projektu. V dnešní době sehnat vývojáře, natož dobrého, není snadný úkol. A sehnat dobrého vývojáře ochotného pracovat se špatnou aplikací?

Nikdo není dokonalý

Na kódu většiny smrtelníků je stále co zlepšovat. To je fakt.

Děkuji, že jste se dočetli až sem. A teď to tajemství

Nejdůležitější jsou lidé. Aktuální stav a budoucnost software přímo závisí na lidech. To, jak naloží s danými prostředky, je na nich. Čert vem technologie, lidský faktor nelze ničím nahradit.