Evolving architecture

Jak navrhovat aplikace takovým způsobem, aby první verze nebyla úplně na vyhození, ale abyste zároveň nespálili budget dřív než budete mít prvního zákazníka

Transcript

1. Evolving architecture @ProchazkaFilip
2. 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
3. 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
4. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. - Grady Booch (author of UML)
5. “Mám nápad na business! Všechno je vymyšlený, už potřebuju jen programátora”
6. “Mám nápad na business! Všechno je vymyšlený, už potřebuju jen programátora”
7. 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 ◦ ….
8. https://xkcd.com/974/
9. (My) Architecture design process
10. 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í
11. 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í
12. 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”
13. 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
14. 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.
15. 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?
16. 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, ...
17. 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
18. 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
19. 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
20. Osekání features
21. 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
22. https://xkcd.com/1205/
23. 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
24. 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
25. 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
26. https://twitter.com/alvaro_sanchez
27. 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
28. 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.
29. 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í
30. 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
31. 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
32. 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
33. 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
34. 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
35. 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í
36. http://geek-and-poke.com/geekandpoke/2013/7/13/foodprints Bonus meme
37. 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) ?
38. @ProchazkaFilip