Evolving architecture @ProchazkaFilip 

Intro: Kdo jsem? ● ~10 let PHP ○ Nette Framework (~9 let), Symfony (~1 rok), Doctrine ○ Kdyby (původní autor) ○ Damejidlo.cz, Rohlik.cz, Lavito.cz ● Cogvio (2017 - now) ○ Pharma & Health ○ Java (Spring, Hibernate), Docker, AWS, ... ○ Nabíráme! cogvio.com/jobs @ProchazkaFilip 

Obsah ● Kontext: stavíme vlastní produkt ● (Můj) proces přípravy/vymýšlení a aplikace architektury ○ Evolution - gradual change, adaptation, progression, metamorphosis ○ Designing for change ● Konkrétní tipy z praxe 

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. - Grady Booch (author of UML) 

“Mám nápad na business! Všechno je vymyšlený, už potřebuju jen programátora” 

“Mám nápad na business! Všechno je vymyšlený, už potřebuju jen programátora” 

Extrémy ● Žádný design/architektura ○ Infinite monkey theorem ■ “A monkey hitting keys at random on a typewriter keyboard will almost surely write the complete works of William Shakespeare” ■ Spoiler alert: You don’t have infinite time and infinite monkeys ○ “Weeks Of Coding Can Save Hours Of Planning” ● Overengineering ○ Nestihnutí deadline ■ Zatímco jsi si maloval(a) entity diagramy, firma zbakrotovala ○ Operations cost ■ Licence za Oracle nás zbankrotovaly ○ …. 

https://xkcd.com/974/ 

(My) Architecture design process 

Všechno vždy zpochybňujte - proč? ● Slyšíte to, co chcete slyšet (ne to, co se vám snaží sdělit zákazník) ○ Zamyslete se, co vám zákazník sdělil a co jste si domysleli ○ Konzultujte, jestli vaše domněnky platí ■ Zopakujte svými slovy jak jste pochopili zadání ■ Můžete dojít k jinému/jednoduššímu řešení 

Všechno vždy zpochybňujte - proč? ● Product owners rádi přichází s řešením problémů, místo s problémy ○ Ne vždy je to špatně - pokud vám nevnucují i implementaci ○ Product owner rozumí businessu, ne technologii ○ Ptejte se ■ Co je to za problém ■ Jak k řešení došli ■ Proč si myslí, že takto je to správě ■ …. ○ Nerozumím problému => velice špatné podmínky pro implementaci správného řešení 

Všechno vždy zpochybňujte - proč? ● Product owners rádi přichází s řešením problémů místo s problémy ○ Některé požadavky můžou být úplně zcestné ■ “Použijeme tenhle hosting” ● Problém: staré verze platformy ● Advanced verze: to, že to na tomhle hostingu rozhodně musí jet, vám řekne až potom, co celou aplikaci napíšete ○ Většinou to myslí dobře ■ Málokdo chce ublížit svému businessu ■ Přístup může mít příčinu ve špatné zkušenosti ● “Chtěl jsem vám ušetřit čas na vymýšlení” ● “Nechtěl jsem abyste se zdržovali přemýšlením o budoucnosti” 

Jaký problém řešíme? ● Chtějte vědět všechno o doméně, o businessu/sales, i jak se to marketuje ○ Všechno tohle může ovlivnit nějaké zásadní rozhodnutí ○ Braňte se slibování deadlinů zákazníkům ■ Sales rádi slibují, že něco bude, aniž by konzultovali s DEVem náročnost a priority ○ Příklad: Šťastná hodinka v DJ ■ Nikdo nevaroval dev, že/kdy bude a zákazníci zahltili web ● Přehození sessions na Redis jsme provedli během downtime 

Přiznejte si, že o dané doméně skoro nic nevíte ● Potřebujete začít něco programovat ○ Zároveň potřebujete znalosti, které budete mít až za rok od teď. ● Programujte tak, aby bylo co nejsnadnější měnit věci, které jste si museli domyslet. 

Jaké use-cases musíme umět řešit? ● Nestačí “udělejte na web anketu” ○ Jak se bude plnit? ○ Jaká bude mít omezení? (Max počet odpovědí?) ○ Jaké bude mít ochrany? (Zneužití uživateli?) ○ Bude možné jí nastavit platnost do kdy je možné vyplňovat? ○ Půjde anketa předčasně vypnout? ○ Půjdou ankety nejenom vytvářet, ale i mazat? ○ Budeme rozlišovat publikované/nastartované ankety? ○ Půjdou ankety po zveřejnění editovat? 

Jaké to má implikace? ● Bezpečnost? ○ Přihlašování: jméno+heslo vs 2FA vs HW Key vs VPN-Only vs … ? ● Výkon? Objem dat? ○ Jak data porostou? Počítáme s tím v SQL dotazech? Umíme takovou DB spravovat? ● Spolehlivost? ● Škálovatelnost? ○ Více instancí (externí sessions, filesystem)? Cloud native? ● Monitoring? Logování? ● Compliance? GDPR, ... 

Daleká budoucnost? ● Jaké features víme, že bychom rádi měli v daleké budoucnosti ○ Třeba za půl roku, za rok? ● Potřebujete vědět maximum informací, co ví business ○ Je těžší plánovat/implementovat aktuální features, když netušíte, kam se produkt ubírá ■ Můžu pak zvolit řešení, které mi “zavře vrátka” k nějaké feature 

Které use-cases mají jaký benefit? ● Business často potřebuje vyřešit některé úkony prioritně ○ Identifikujte ty, které mají pro zákazníka největší benefit. ○ Když priority zná business i DEV, snadněji se domluvíte ● Když je všechno priorita, nic není priorita 

Náročnost (na implementaci) a proč? ● Promyslete náročnost ● Konzultujte s businessem ○ Můžou si myslet, že něco je složité, byť to má velký benefit, takže to odkládají a ani vám o tom neřeknou 

Osekání features 

Osekání features ● Osekejte scope, ne kvalitu ● Implementace některých procesů je možné odkládat i delší dobu za cenu trochy manuální práce ○ Získám tím možnost nabrat zkušenosti s procesem a později ho implementuji lépe ○ Příklad: registrace zákazníků ○ Opportunity cost 

https://xkcd.com/1205/ 

Plán implementace ● Co je MVP? Čím začneme? ○ Definujte si MVP a krátký backlog. ● Implementační závislosti ○ Co se může dělat paralelně? ■ Čím větší systém tim snazší paralelizace práce ○ Co určitě nechcete dělat paralelně? ■ Komplikace upfront designu ● Malé tasky ○ Rychlejší začlenění nové knowledge zpatky do systému ○ Rychlejší feedback na features 

Definování “implementační” architektury ● Frameworky, knihovny ● Vrstvy kódu (model) ● Používejte známé technologie ○ Fulltext? Elastic vs PostgreSQL ■ Operations cost druhé databáze ■ Learning curve ○ Nepotřebujete Kubernetes, naklikejte systém v AWS ECS ○ Neučte se úplně nový technologický stack na úplně nové doméně ■ Změnit framework, jazyk i projekt zároveň je velké sousto 

Systémové komponenty ● Definujte si komponenty a hranice mezi nimi ○ Snažte se držet komponenty systému co nejvíce oddělené ■ => Snadnější upravování/přepis ● Kašlete na microservices ○ Začněte monolitem 

https://twitter.com/alvaro_sanchez 

Kreslení - datový model ● Nakreslete si datový model a plánujte hodně do budoucna ○ Do detailů zpracujte jen věci, které jsou na řadě v hodně blízké budoucnosti. ● Hůře se mění než logika aplikace 

Začít bez abstrakcí ● Duplikace ○ Boilerplate ○ Logiky ○ Dvě komponenty systému s podobnou logikou ● Odkládejte abstrakce na později ○ Nechte svoje čerstvě nabyté znalosti domény uzrát v expertízu. 

Nevymýšlet kolo ● Potřebujete vystavovat faktury? ○ Zaplaťte si třeba Fakturoid ● Píšete systém na správu vedlejších účinků léků? ○ Najděte hotové specifikace ○ Inspirace pro datový model ● Nelíbí se vám knihovna na 3rd party API? ○ Stejně si nepište vlastní 

Buďte co nejstriktnější ● Defenzivní programování ○ https://ocramius.github.io/extremely-defensive-php/ ● Používejte VO a DTO, validujte hodnoty ● Předcházejte nedefinovaným/nevyžádaným stavům ○ Neignorujte chyby ○ Házejte výjimky ■ Error 500 je lepší než zaseklá objednávka 

Používejte minimum VO z knihoven ● Často je lepší celou knihovnu obalit do vlastních objektů než mít pak její třídy prorostlé celým projektem ○ Problém je leakování knihovny přes více úrovní abstrakce ● VO z knihovny na datetime - Ano ● VO z Twitter API knihovny - Ne 

Jednoduché objekty, které půjde lehce rozšířit ● Více menších tříd ● Kompozice ● Minimum dědění ● Minimum interfaces ○ Když vím, že bude více implementací ○ Když potřebuju vytvořit abstrakci a implementaci si nechat dodat ● Méně kódu “je více” ● Jasný záměr je důležitější než výkon nebo estetika 

Pište automatizované testy ● Zvolte vhodnou testovací strategii ○ Co testovat ○ Jak testovat ○ Co netestovat ● Typy nenahrazují testy ● Testy nenahrazují typy ● Testeři nenahrazují testy ● Testy nenahrazují testery 

Co s těmi “odfláknutými features”? ● Osekejte scope třeba na 40% ● Naimplementujte (co nejlépe umíte) ● Při příští iteraci vyberte dalších 30% feature ● Naimplementujte a u toho zrefaktorujte předchozích 40% ● … ● Repeat 

Shrnutí ● Komunikujte s businessem ● Vždycky z nich dostaňte důvody pro rozhodnutí ● Odkládejte rozhodnutí, které můžete odkládat ● Kroťte se s abstrakcí 

http://geek-and-poke.com/geekandpoke/2013/7/13/foodprints Bonus meme 

Otázka do publika: Máte nějaké tipy čemu se vyvarovat, aby šly aplikace snadněji měnit (když se změní požadavky) ? 

@ProchazkaFilip