Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Evolving architecture

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

Filip Procházka

November 30, 2019
Tweet

More Decks by Filip Procházka

Other Decks in Technology

Transcript

  1. Evolving
    architecture
    @ProchazkaFilip

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  8. https://xkcd.com/974/

    View full-size slide

  9. (My) Architecture design process

    View full-size slide

  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í

    View full-size slide

  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í

    View full-size slide

  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”

    View full-size slide

  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

    View full-size slide

  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.

    View full-size slide

  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?

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  20. Osekání features

    View full-size slide

  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

    View full-size slide

  22. https://xkcd.com/1205/

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  26. https://twitter.com/alvaro_sanchez

    View full-size slide

  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

    View full-size slide

  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.

    View full-size slide

  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í

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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í

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  38. @ProchazkaFilip

    View full-size slide