Slide 1

Slide 1 text

Evolving architecture @ProchazkaFilip

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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 ○ ….

Slide 8

Slide 8 text

https://xkcd.com/974/

Slide 9

Slide 9 text

(My) Architecture design process

Slide 10

Slide 10 text

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í

Slide 11

Slide 11 text

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í

Slide 12

Slide 12 text

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”

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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?

Slide 16

Slide 16 text

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, ...

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Osekání features

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

https://xkcd.com/1205/

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

https://twitter.com/alvaro_sanchez

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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.

Slide 29

Slide 29 text

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í

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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í

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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) ?

Slide 38

Slide 38 text

@ProchazkaFilip