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. 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
  2. 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
  3. Architecture represents the significant design decisions that shape a system,

    where significant is measured by cost of change. - Grady Booch (author of UML)
  4. 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 ◦ ….
  5. 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í
  6. 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í
  7. 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”
  8. 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
  9. 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.
  10. 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?
  11. 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, ...
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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.
  21. 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í
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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í
  28. 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) ?