Hlavní navigace

Vlákno názorů k článku Sčítání.cz: jak to příště zvládnout lépe aneb úvahy o dnešním IT od Pavel Stěhule - Díky za úvahu a dobrý článek - ve...

  • Článek je starý, nové názory již nelze přidávat.
  • 6. 4. 2021 6:30

    Pavel Stěhule

    Díky za úvahu a dobrý článek - ve všech bodech s vámi bezvýhradně souhlasím.

    Vývojáři dnes mají hodně specializované znalosti, a mají i dobré nástroje - od hardware po software - ale postrádají intuici - co je vhodné, co je robustní, co je praktické. Nevycházím z údivu, že i u relativně důležitých aplikací dokážu odstranit kritický bottlneck po X měsících (letech) provozu. Něco, co už mělo být dávno opravené.

    Nemyslím si, že všechny chyby je možné opravit před provozem. To je hodně drahé, ale lze dělat mnohem víc než se dělá, a díky post startup tuningu získat mnohem lepší parametry aplikace - rychlejší odezvy, větší rezervy ve výkonu, a tím i větší šance na zvládnutí nečekaných špiček.

    Chce to zkušenosti, chce to i nějaké obecnější znalosti a přehled všech vrstev. Když jsem po vojně v roce 2001 začínal fulltime vývoj - a tunili jsme databázové aplikace ve Visual Basicu, tak díky tomu, že jsme věděli kulové o SQL serveru, tak jsme honili mikrosekundy a minuty nám utíkaly. A navíc (a to platí stále) - zbytečné nebo špatně napsané dotazy způsobují zátěž databáze, díky které i ty správné, správně napsané dotazy mohou být pomalejší.

    6. 4. 2021, 06:32 editováno autorem komentáře

  • 6. 4. 2021 15:33

    TomK

    Ad "vývojáři postrádají intuici":
    Ano, ale jak ji získají? Jen praxí. Intuice je takový koncentrát zkušeností, vlastních i cizích chyb. Pak už se stačí jen podívat a člověk vidí. Akorát to dost dlouho trvá ten nadhled získat.

  • 6. 4. 2021 17:28

    dw

    To co popisujes je dedukcia, intuicia je nieco ine. Suvisi so schopnostou odvodit zatial nepoznane z uz poznaneho.

  • 6. 4. 2021 18:02

    Pavel Stěhule

    I ta intuice se musí trénovat. Je dobré mít hodně načteno - třeba z stackoverflow, z mailing listů. Drtivou většinu z toho si člověk nepamatuje, ale tam někde v mozku je poznámka, že tu už tu někde bylo, a že to třeba šlo. Taky zjistíte, co je možné, a jaké jsou možnosti. Google ví všechno, ale musíte znát pár klíčových slov, a musíte vědět, že to co hledáte vůbec existuje.

  • 6. 4. 2021 18:27

    dw

    Trenovat sa daju vedomosti( skusenosti), inteligencia moc nie. Pravda je ze ak nejdu ruka v ruke su osamote k nicomu.

  • 6. 4. 2021 17:53

    Pavel Stěhule

    Ano - jen praxí, a to ještě ne každá praxe vám pomůže. Jako docela velký problém vidím plochost kariéry drtivé většiny vývojářů - umí používat několik málo produktů, ale už neví, proč a jak ty technologie fungují, nevědí, co je společné, a co je rozdílné - chybí jim nadhled, přehled.

    Určitě tu chybí určitá formalizace kariéry. To, že je někdo seniorní programátor vůbec nic neříká o profesionálních a lidských kvalitách. Certifikace a obecně neuniverzitní vzdělávání v IT je také dost problematické, protože se učí primárně používání produktů. Neučí se obecné znalosti, obecný přehled.

  • 6. 4. 2021 18:34

    Miroslav Šilhavý

    umí používat několik málo produktů, ale už neví, proč a jak ty technologie fungují, nevědí, co je společné, a co je rozdílné - chybí jim nadhled, přehled

    On je to takový paradox. Nadhled, přehled zadavatelé někdy ocení jako přidanou hodnotu, něco navíc, co dostanou v ceně. Většinou je ale pracovník s těmito vlastnostmi za potížistu, komplikátora, toho, kdo hledá problém tam kde (jen zdánlivě?) není. Chci hamburger, takže si zajdu pro etalon fastfoodů od McD a nepřemýšlím, jestli má být houska z brioškového těsta, jaké maso namlít a jakou omáčku připravit. Pracovník s nadhledem a přehledem se na to bude ptát. A to se nenosí.

  • 6. 4. 2021 19:17

    dw

    Většinou je ale pracovník s těmito vlastnostmi za potížistu, komplikátora, toho, kdo hledá problém tam kde (jen zdánlivě?) není.
    To je vacsinou ale problem v teame, par krat som sa uz stretol s tym ze team je tvoreny sektou seberovnych, ktori zdatnejsieho kolegu pokladaju za hrozbu. A tiez s tym ze v niektorych pripadoch je projektak len velmi dobre platena sekretarka a v dopadovej analyze vidi len to ze preco to neurobit, nie to ze by to bolo lepsie urobit inak.

  • 6. 4. 2021 20:25

    Pavel Stěhule

    To, že má někdo přehled ještě neznamená, že se nemůže chovat jako blbec :). A i normální a slušní lidi se chovají občas jako blbci, když jim někdo dlouho brnká na nervy. Člověk by si asi měl říct, co je pro něj důležité, co zásadní, s čím se dá smířit, a kdy je lepší v klidu odejít, proč v té firmě je, a jaký je jeho přínos.

  • 6. 4. 2021 21:45

    Zdeno Sekerák

    Aniz bych obhajoval mlade programatori skuste se zamyslet kdy k tem vedomostem maji prijit? Ano my stary harceri jsme prosli vsim od 8 bitu pres DOS, k Windows a nebo tak nejak. Zazili jsme peklo preruseni IRQ, jak se pisou rezidentni programy. Proc je dulezite instalovat ten a ne ten ovladac. Bitove posuny, TurboVision, OOP, Javu, C# ... a meli jsme na to cely svuj zivot. Oni ale musi v 26 programovat v C#/Java kde jen jedna blba knihovna o kryptaci ma tolik funkcii jak cele C v slavne knize od Herouta. Navic to maj komplikovane tim ze nemaj sanci pochopit jak to funguje protoze naabsolvovali cestu jako my kdy jsme si lepili MD5 z lib. Proste funkce bud funguje nebo ne. Nic mezi tim.
    ...
    Jo uz jsem stary.

  • 6. 4. 2021 22:28

    Miroslav Šilhavý

    @Zdeno Sekerák

    Však já to chápu a přijímám. Ve svých dvaceti jsem se taky smál starším, když vykládali, jak leštili plotny disků a jaký pokrok byl Winchester.

  • 11. 4. 2021 19:06

    neřeknu

    jo souhlasím, ale když vidím dnešní seniory, kteří programují třeba 1/2 roku v Reactu nebo C# a považují se super programátory, tak je blivno. Na druhou stranu je ale chyba ve školství (osobní zkušenost), která plodí podobný ...

  • 6. 4. 2021 22:41

    Ján Regeš

    Souhlasím. Když už jste zmínil databázi a článek pojednával hlavně o výkonu - já osobně databázi vnímám jako srdce každého projektu a její kvalitní návrh vnímám jako základní stavební pilíř pro dlouhodobou udržitelnost projektu. Hodně programátorů v tomto se mnou nesouhlasí a srdce vidí spíše v aplikačním kódu. Ruku na srdce - jakýkoliv kód starší pár měsíců, bude každá další generace programátorů, či programátorů preferující jiná paradigmata, kritizovat a chtít přepisovat. I ten samý tým po pár měsících, nedej Bože, po letech.

    Z praxe vím, že naprostá většina výkonnostních problémů, které nešli vyřešit v řádu desítek minut, souvisela s nevhodným návrhem, či prací s databází. Ať už šlo o jakoukoliv formu databáze.

    Dobře navržená databáze pouze s minimem úprav, v mé praxi často přežila i několik úspěšné zvládnutých FE, či dokonce BE přepisů v průběhu let. Pro lepší kontext - vedle role hlavního vývojáře, jsem byl pro cca. 20 projektů i analytikem a architektem, kde jsem navrhnul kolem 1 000 DB tabulek pro OLTP i OLAP workload. Omlouvám se - vím že to zní jako chlubení, ale je to pravda :-) Řešil jsem desítky výkonnostních potíží v mých či cizích projektech. Za všechny projekty dodnes po výkonnostní a celkově provozní stránce, zodpovídám v režimu 24x7 a jakékoliv faily si beru osobně.

    Při realizaci projektu jsem vždy začínal a učil i mé kolegy postup, kdy je na začátku potřeba precizně domyšlený, okomentovaný, konzistentní návrh celé relační databáze. Ideálním podkladem byla kombinace funkční specifikace a wireframů všech aplikačních obrazovek. Takový luxus jsme ale někdy neměli - to známe všichni. Návrh databáze zahrnoval rovnou i případné views (typicky pro složitější agregace, se kterými by aplikační vývojáři zbytečné bojovali), triggery, constrainty a občas i funkce či procedury, které by byly v aplikačním kódu extrémně neefektivní. Zde ale musím přiznat, že jsem u jednoho z projektů udělal fail a značný část business logiky je i v databázi, co se zpětné ukázalo jako nešťastné, pokud v projektu není dobrá zastupitelnost pro složitější SQL. Obecně pro časovou představu – pro projekt o rozsahu 1 000 hodin vývoje, tento detailní návrh databáze zabral cca. 50-100 hodin. Obvykle ale při implementaci nebyly potřeba žádné změny, nebo opravdu pouze minimálně.

    Z navržené databáze se pak automaticky generuje/přege­nerovává celá aplikační ORM vrstva, která pozná a generuje natypované atributy pro belongs-to, has-many i many-to-many relace. V kódu a anotacích odpovídajícím jednotlivým tabulkám a sloupečkům, pak aplikační vývojáři vidí, jak/kdy/proč/co do těchto tabulek ukládat. I když projekt vyvíjí hodně vývojářů, ukládání a workflow práce s daty je jednotné, efektivní a přímočaré. Vývojáři používají striktně natypovaný kód, všude jim všechno hintuje a když se náhodou DB struktura změní a ORM přegeneruje, statická typová kontrola hned poukáže na nekompatibilní kód. Vývojáři taky vědí, kdy můžou použít cache i jak ji invalidovat, kdy mají použít transakce, jak dát ORM vrstvě optimalizační hinty u některých složitějších dotazů, či kdy naopak ORM vrstvu pro fetch dat nepoužít a pouze si od ní získat plánovaný SQL dotaz.

    Dopředu jsem vnímal a znal potenciálně výkonnostně riziková místa a měl úvahu nad tím, jak bych je případně efektivně vyřešil v řádu minut či max. jednotek hodin. Některé byly třeba o nahrazení per-query agregovaného sloupečku ve view za indexovaný virtuální sloupeček, nebo fyzický udržovaný triggerem. Některé byly o tom, že je bude agregovat periodicky DB eventa na pozadí. Některé o tom, že aplikačním vývojářům řeknu, aby některé sloupečky plnili pouze zástupkou a v předpřipraveném sloupečku přednastavili status “in-queue“ a budou se dopočítávat paralelně na pozadí úplně jinými procesy. Často se tím povedlo zabránit zbytečnému overengineeringu a preventivnímu zavádění dalších technologií, které sebou nesly další problémy k řešení.

    Vím, že je to opačný přístup k některým paradigmatům, kdy je struktura databáze pouze vygenerovaným derivátem aplikačního kódu (typicky u DDD, BDD či FDD s klasickým uchopením ORM). Může to být ale dobrý námět pro další článek. Následná diskuze by mohla být velmi inspirativní a poukázat na další silné či slabé stránky možných řešení. Všichni máme různé zkušenosti, různé projekty, různé týmy, různé technologie...

  • 7. 4. 2021 6:20

    Pavel Stěhule

    Samozřejmě, že databáze jsou přirozené úzké hrdlo - je to to místo, kde se data zapisují na perzistentní médium, a u webových aplikací je databáze tím místem, kde dochází k synchronizaci přístupu k datům, a tudíž čekání na zámky.

    Obecně považuji ORM za neštěstí - z mnoha důvodů. Kromě jiného, ORM brání programátorům získat důležité znalosti a zkušenosti ohledně práce s databází. Nemyslím si, že by ve výsledku ORM uspořilo nějakou práci, a při větší zátěži nebo větších než malých datech to může být katastrofa, kterou nelze opravit a ani vyřešit než přepisem aplikace. Ale doba je taková. Samozřejmě, že je dobré přístup do databáze mít nějak obalený, ale je dobré aby i poslední programátor měl databázi v ruce, zažitou. Protože i ten poslední programátor může napsat takovou blbost, že shodí produkci.

    Nicméně to je jiné téma. Když už přijdete k hotovému produktu, tak se chca nechca musí pokračovat ve stávajícím vývoji. Když se ale začíná s nějakým produktem, tak je dobré, když máte v týmu někoho, kdo má přehled - a kdo dokáže zvolit správnou technologii, a správný přístup (záleží na budoucí aplikaci, zátěži, i vývojářích, kteří jsou k dispozici). Jinak se používá Oracle, jinak Postgres, jinak MySQL a úplně jinak Mongo nebo Cassandra. Některé aplikační patterny jsou překonané - ví se, že vedou k monstrům a pomalým aplikacím. Je potřeba aplikace průběžně testovat během vývoje, včas odhalovat potenciální problémová místa.

    A je hrozně důležité (a to se asi nedá naučit) mít technický cit (aspoň jeden člověk v týmu), a znalosti. Několikrát jsem zažil, že vývojáři narazili na výkonnostní problém, a při jeho řešení spálili neskutečně hodin, a navíc si zadělali na mnohem větší problém v budoucnu. Bohužel drtivá většina vývojářů nedokáže správně identifikovat zdroj výkonnostních problémů (ono to kolikrát není jednoduché), a tudíž ho neumí ani správně opravit. Dost vývojářů ani netuší, že tam mají výkonnostní problém. Pro mne je to obživa, ale říkám si, jak je to zbytečný. Uživatelé by mohli mít apky 100 x rychlejší, pro provozovatele by provoz mohl být jednodušší - méně stresující. Z neznalosti věci se vymýšlí se neskutečné pí....

  • 7. 4. 2021 9:10

    nil nil (neregistrovaný)

    Kromě jiného, ORM brání programátorům získat důležité znalosti a zkušenosti ohledně práce s databází.

    To bych podepsal. A nejenom brání získat, ale nechá Vás po pár letech taky pěkně "vyjít ze cviku" a nerozvíjíte dál a dál znalosti. Osobní zkušenost. Na větší data, katastrofa a ještě to vlastně přidává další vrstvu komplikací a užírá výkon.
    Tak ono ORM uspoří nějakou práci ve smyslu toho, že je možno zrovna pracovat s objekty, ale (osobní zkušenost) ve finále nějaké větší produkční aplikace stejně polovina dotazů letí čistě jako SQL, protože to se prostě nedá a zrychlení aplikace tím přichází v násobcích ...

    7. 4. 2021, 09:12 editováno autorem komentáře

  • 11. 4. 2021 19:13

    neřeknu

    pod toto se velmi rád podepíši :-) Plně s tím souhlasím. Rozhodně má ORM své klady, ale když to tak vidím, přijde mi, že mám spíše samé nevýhody. Bohužel, ORM má nesmyslné režie a na systémech, kde je potřeba optimalizace, je spíše na překážku.

    Hlavně nechápu, proč se u ORM vždy zdůrazňuje, že mohu použít jakýkoliv driver, a nemusím nic dělat navíc. Programuji přes 25 let, byl jsem i na opravdu velkých systémech a nikdy se nestalo, že by se měnila DB, resp. pokud se přecházelo třeba z MSSQL na cokoliv, vždy se řesily migrace a DB byla kompletně nově navržena.

  • 7. 4. 2021 9:42

    Miroslav Šilhavý

    V praxi se setkávám přesně s tím, že úzké hrdlo aplikace je v práci s databází a neodstranitelné právě díky ORM. Je však zajímavé, že i tak zákazníci nechtějí slyšet o tom, kde je problém a jak ho řešit. Obvykle je zákazník v kleštích, má proinvestovánu spoustu peněz a vývojář odmítá často i z ješitnosti přiznat (nebo si připustit), že je problém zrovna v tomto místě. Zákazník, který to platí, si pak musí vybrat. Pokud dá na konzultanta, musí zvládat překonat ješitnost vývojářů a připravit se na přepis. Často ale na to nemá odhodlání, takže místo toho, aby nezoptimalizo­vatelnou část nechal přepsat, tak se další měsíce i roky plácá na místě, nahání mikrosekundy v aplikaci, posiluje hardware na to, aby nakonec ten boj stejně prohrál. Zajímavé je, že ORM-nemoc se nevyhýbá ani jinak hodně dobrým programátorům.

  • 7. 4. 2021 9:56

    nil nil (neregistrovaný)

    @Miroslav Šilhavý

    Můžu napsat mou poslední zkušenost. Vy jste tady básnil o nějakém cechu. Tak podívejte. Poslední dva roky (i pár dalších) pracuji se Symfony a nějaký standard daný Symfony je ORM Doctine. A už jste v tom. Pokračuji na projektu, který už byl v době mého nástupu v Symfony + Doctrine nemohu přepsat celou aplikaci. Je to vlastně takový interní ekosystém. A proč to nejde? Protože to nikdo nezplatí. Firma po letech vývoje a dohadování s klientem nedá např. 5 milionů (pár lidi a 3/4 roku) na to, aby to přepsali. Ano, tak je to jednoduché.

    To není o ješitnosti. Manžeři tomu nerozumí, standard máme (Symfony + Doctrine) a jediné co mohu udělat je, že tam kde je to kritické, tak použiji přes Doctrine Native Query zrovna. Na druhou stranu, potřebujete také ošetřovat dotazy a co si budeme, krýt si záda, že. Poslední dobou je přístup, abych tak řekl "deleguj a zapomeň" velmi moderní. Je to v podstatě takový, jak to říct ..., "blind decoupling" ... A ORM je na to výtečná.

    Doctrine není jediný ORM framework a počítám, že v jiných jazycích je situace podobná.

    7. 4. 2021, 09:58 editováno autorem komentáře

  • 7. 4. 2021 12:43

    Adam Kalisz

    Máte nějaké zkušenosti s "database as a value" přístupem z Datomicu/ OpenCruxu? OpenCrux by mělo snad jít provozovat i přímo nad PostgreSQL a kromě datalogu lze použít pro specifické dotazy/ využití specifik i SQL.

  • 7. 4. 2021 12:28

    Adam Kalisz

    Je strašně vidět, že pracujete tendenčně projektově místo produktově, i když máte třeba osobní zodpovědnost za provoz. Nemáte prostě jeden produkt, který řešíte ze všech různých úhlů pohledu. (Tedy aspoň to tak působí a je to úplně v pořádku, ale ovlivňuje to Váš pohled.)

    Díky různým zkušenostem od dobrovolné práce ve studentské síti, práce ve velmi tradiční firmě, různé další pozice až nakonec po velmi netradiční startup (OrgPad jsem teď) je to všude diametrálně odlišné. U projektu samozřejmě může být střídání gard poměrně rychlé, může být pomalé. Kód může být dobrý natolik, že se základní myšlenka především rozšiřuje a nebo se pořád znovu dokola přepisuje pomocí jiných přístupů. To samé samozřejmě může být u produktu, ale obyčejně je tam kontinuita větší, co tak vnímám.

    Startup je zajímavý tím, že exponenciální růst přináší různé výzvy v rychlé řadě za sebou. Věci se ze začátku udělají nějak, aby se neztrácela data, aby to nějak chodilo apod. potom se kontinuálně věci zlepšují. Přidává se postupně dle potřeby schopnost běžet např. s více aplikačními servery, přidává se HA, více se řeší monitoring a metriky atd. Kdyby se ale všechno dělalo od začátku "správně", tak by se nikdy nezačalo/ došly by finance před vstupem na trh. Ano, taky jsem si musel na tento přístup nejdřív zvyknout, to je rozdíl v tom, že už nejsem zaměstnanec v etablované tradiční firmě, ale vlastně spíš jakoby v roli zakladatele/ investora v něčem úplně novém. Rozdíl je taky v tom, že se vhodné řešení vlastně pořád hledá, zatímco jinde je často nasnadě. To je velká výhoda (a současně nevýhoda) tradiční firmy, kdy je problematika do určité míry již prozkoumaná - není moc prostor na nový pohled.

    Nakonec bych řekl, že bychom se měli vyvarovat tomu označovat něco, na čem pracujeme zrovna my za to nejdůležitější na daném projektu/ produktu. Důležitý je celek. Každopádně uživateli je databáze fakt jedno, když mu neztrácí/ nerozbíjí data a nečeká zbytečně na výsledky - zajímá ho ale rozhraní ať už je to GUI nebo nějaké API, se kterým komunikuje, třeba ten našeptávač a celkový dojem ze sčítání.

    Mimochodem k tomu výkonu a důležitosti je jednoznačně z těch tvrdých kompetencí u OrgPadu důraz na frontendu. Přenos dat/ čekání na data je minimum stráveného času. Spíš se čeká na DOM v prohlížeči s čímž lze udělat poměrně málo, pokud nechceme dělat rendering úplně ve vlastní režii. Mimochodem na výkonu backendu se pracovalo třeba 2 týdny za rok a půl fungování, z toho většinu času ale šlo o zásadní změnu infrastruktury pro migraci z Heroku na vlastní infrastrukturu, což mělo za vedlejší efekt lepší výkon, fokus měly ale spíš jiné provozní vlastnosti. Explicitně na výkonu frontendu čistě z hlediska kódu se pracovalo minimálně měsíc, spíš déle.

    I z hlediska kódu je backend zlomek frontendu a to i kdybych srovnal jen části s logikou (tedy bez GUI na frontendu). Uživatelé OrgPadu používají produkt jen a pouze kvůli tomu, jak se ovládá a jak funguje. To, že běží a že neztrácí data se tiše předpokládá. Nikdo tohle zmiňovat nebude, podobně jako nezmiňujeme u auta, že je fajn, že ve většině případů jede.

    Je zajímavé si ale počíst o tom, jak jdete od databáze k aplikaci, jak různé věci řešíte. Váš poslední odstavec to dobře shrnuje.

  • 7. 4. 2021 13:27

    Ján Regeš

    Adame, děkuji Vám za tento inspirativní komentář.

    Máte naprostou pravdu s tím, že převážně pracuji spíše projektově, než produktově. Uvědomuji si ale rozdíl těchto 2 světů a rád si vždy poslechnu i pohledy lidí spíše z produktové firmy/týmu. Ty naše finální cíle by ale měly být stejné - dlouhodobě spokojení uživatelé produktu/projektu, co pak znamená i spokojeného klienta a tím ve výsledku i nás, dodavatelů. Ze své role odpovídám u mnoha projektů, a to i před všemi klienty/produkty, za to, že jde všechno kolem vývoje i provozu těchto projektů/produktů hladce a ke spokojenosti všech zapojených. To mně přirozeně nutí vnímat a dávat důraz těm podstatným oblastem, které nás jako celek, trápí nejvíce. Projekty, které si vybíráme mají vždy dlouhodobý charakter i z pohledu vývoje či provozu, za které dlouhodobě odpovídáme. Takový "projekt" pak musí naplňovat stejné parametry, jako "produkt", ať už z pohledu klienta, či nás - dodavatelů.

    Co se týče procesu vývoje IT projektů, hodně dbám na to, abych co nejlépe rozuměl jak potřebám klienta/produktu a jeho uživatelů, tak i technickým aspektům vývoje, provozu i mindsetu a potřebám všech zapojených lidí. Tyto světy se v něčem vzájemně pozitivně či negativně ovlivňují a mám za to, že největší technologický důraz je potřeba dávat právě těm věcem, které jsou vidět a ovlivňují nejvíce vnímání produktu/projektu jeho uživateli. I proto se vždy snažím zdůrazňovat, aby např. vývojáři bezhlavě neovergineerovali a nedávali energii a čas věcem, které na výsledný produkt/projekt nemají viditelný vliv - ať už na jeho používání, či dlouhodobou udržitelnost. Vždy ale existují při návrhu architektury jakéhokoliv IT řešení nějaké možné quick-winy a drobné dopředně-kompatibilní myšlenky, které nezpůsobí zvýšení nákladů na vývoj (nebo pouze z 1-2%). Když se pak ale začnou objevovat např. výkonnostní problémy, je možné je efektivně vyřešit bez zásadních zásahů do samotné aplikace. Je třeba předvídat a mít připravené zadní vrátka, ale samotnou implementaci odložit až na moment, kdy přijdou první indicie možných problémů. Často to nenastane ani po letech provozu. Když ale ano, stačí nějakou volitelnou součástku (se kterou architektura dopředu počítala) doplnit, ale není třeba zahazovat a přepisovat jinou práci.

    U projektů jako zmíněný OrgPad musí být samozřejmě maximální důraz na skvělé zvládnuté UX a FE obecně. BE má u takového projektu, minimálně v kontextu časových investic, sekundární roli - ten musí fungovat spolehlivě, být rychlý pro očekávaný počet uživatelů, kvalitně monitorovaný a být vždy dostatečně přitažlivý i pro stávající či budoucí BE vývojáře kvůli dlouhodobé udržitelnosti.