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

07ac3a80e69a6252140feb81b89cbb08?s=128

Filip Procházka

November 30, 2019
Tweet

Transcript

  1. 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
  2. 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
  3. 4.

    Architecture represents the significant design decisions that shape a system,

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