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 L. - Pokud jsem to dobře sledoval, tak hlavní problém...

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

    L.

    Pokud jsem to dobře sledoval, tak hlavní problém byl v tom, že našeptávač adres neměl žádnou minimální délku ani debounce a posílal dotaz po každém napsaném znaku. To je za mě fatální chyba člověka, co ho implementoval, na to není potřeba žádný super-architekt, to je základní (ne)znalost best practices.

    Když tohle odstranili, tak se systém rozjel v pohodě, takže to nejspíš bylo opravdu jediné úzké hrdlo. Větší architektonické změny by za necelý den nestihli, i nějaké posílení HW by asi nestihli moc velké (?)

    Co jsem tak slyšel o procesu, oni i dělali pilotní test a výkonnostní test. Chyba ale byla, že zátěž pro výkonnostní test generovali uměle, místo co by v rámci pilotu chytali requesty a pak je spustili komprimovaně. To je snad jediné, co by se tomu dalo vytknout na high-level úrovni.

    Jinak až na ten jeden lapsus je ta aplikace nadesignovaná slušně. Jak z hlediska UX (pro typickou kvalitu státních aplikací se podívejte třeba na portál Moje daně), tak i celková architektura - udělat to jako SPA aplikaci co má business logiku v sobě, posbírá si data a pak je jen pošle na server dává v případě takovéto zatížené aplikace smysl.

  • 6. 4. 2021 10:41

    Jakub Valenta (neregistrovaný)

    Mě teda UX přijde úplně otřesný. Vlastně vytvořili jen verzi pro mobily s dotykovým displejem. Vždy se zobrazuje jen jedna otázka obřím písmem a klikací odkaz na další, Pro desktop by mi přišel lepší ten závěrečný přehled.

    Vzhledem k tomu, jak jednoduchý problém to byl (asi 20 otázek s možnostmi a 4 se vstupem od uživatele), tak to skoro vypadá, že to střihli za týden na první dobrou.

  • 6. 4. 2021 10:49

    L.

    Protože jste to vyplňoval jen za sebe a vidíte jen ten jeden svůj průchod. Já to vyplňoval za celou rodinu a je tam dost otázek navíc / jinak podle toho, co vyplníte v předchozích otázkách. Pak vyplňování po krocích dává smysl.

  • 6. 4. 2021 11:14

    Zdeno Sekerák

    Ja zase uvital že jsem tam naklikal všechny lidi v domácnosti a už nemusel vyplňovat adresu (protože máme strašne dlouhou adresu se všema háčkama co čeština zná).
    V porovnáním s tím co mají slováci to bylo rychlejši.

  • 6. 4. 2021 11:20

    Miroslav Šilhavý

    Tak to může být jedině "nábřeží Svazu protifašistických bojovníků", s tím už si zadá jedině příšerně žluťoučký kůň.

  • 6. 4. 2021 10:51

    Miroslav Šilhavý

    Takové chyby, jako je našeptávač bez debounce, se stávají dnes a denně. Jejich zákeřnost tkví v tom, že neexistuje žádný způsob, kromě know how mnoha lidí v řetězci, jak chybu odhalit zavčas. Během testování nenarazíte na problém, takže chyba zůstává skryta až do kritického okamžiku.

    Jistě, součástí testování by mohlo / mělo být i otestování funkčnosti v případě zpomalení či výpadku podpůrných služeb (API našeptávače). Jenže takových oblastí "co by se mohlo", je nespočet.

    Osobně vidím spíš chybu na té straně, která vystavuje API. Ta by měla v dokumentaci požadovat, aby byl debounce implementován, a ideálně umět detekovat / reagovat na to, když není. Aspoň nouzově. Taky je na pováženou, že se na každý hint musí odeslat požadavek, s veškerou režií. Taková služba by měla jet na socketu - pak si tempo může řídit i služba, nejen prohlížeč. Jenže praxe je taková, že API a služby (ať už veřejně nabízené, nebo interní) se prasí v demo kvalitě a v celém procesu se jich nedotkne ruka nikoho, kdo by je správně navrhl.

    Podívejme se, jak vypadají API služeb, které se dnes nejčastěji používají. Našeptávače, pobočky doručovacích služeb apod. Děs a hrůza, v lepším případě to mají offline (píšu v "v lepším případě", protože to ušetří programátora něčemu rozumět do hloubky), v horším případě jsou to API na jednotlivé požadavky a k tomu dokumentace v nulové úrovni (a programátore, přijdi si na problémy sám, od nuly).

    I když to třeba není pokaždé spravedlivé, domnívám se, že je potřeba vyžadovat odpovědnost po dodavateli - ať už jde o externí firmu, nebo o interní jednotku. Dodavatel by měl vystavit takovou službu, která funguje podle dokumentace. Tedy, měl by mít potřebu specifikovat limity, požadavky na implementaci, doporučení na otestování apod. Házet to na programátora, který implementuje, že nemá know-how je moc jednoduché, ale nepovede to ke zlepšení stavu. Neznalého programátora vyměníte za dalšího, ale je jen věcí náhody, jestli do podobné pasti nespadne i on.

  • 6. 4. 2021 12:48

    vdx

    Našeptávač jsme taky řešili x krát a nikoho by ani ve snu nenapadlo, tam nedat prodlevu na keypress a check na minimální (smysluplný) počet znaků, a celý datový engine nebo aspoň část nechat v cache nebo v paměti serveru. A stejně si myslím, že to je zástupný problém pro to, proč to nefungovalo a že tam takových bottlenecků bude víc. Když není nezávislý audit kódu, tak se to stejně nedozvíme. Chtělo by se mi říct na závěr, Čau lidi ! :-D

  • 6. 4. 2021 13:05

    Miroslav Šilhavý

    Jasně, našeptávač je jen viditelná část ledovce nad vodou.

    Debounce je docela běžný instrument, ale není nijak povinný. Když budete hledat odpovědnost, těžko ji můžete klást na bedra programátora, pokud to neměl ani v zadání (projektu), ani v dokumentaci ke službě. Jeho role není v tom, aby hledal problémy (druhých), ale aby splnil zadanou práci.

    Jistě, bylo by samozřejmě nejlepší, aby každý programátor měl rozhled, zkušenosti, čas a rozpočet, aby mohl dělat svoji práci absolutně nejlépe, jak se v oboru umí. Jenže to byste musel mít na každé pozici překvalifikované pracovníky, kteří 99 % času budou dělat práci pod jejich úroveň a v 1 % času se využije jejich znalost. Za pár let takového fungování poklesne jejich úroveň pod průměr, protože nebudou mít dostatek příležitostí k novým zkušenostem.

  • 6. 4. 2021 15:23

    vdx

    No, tak v tom případě je něco hodně špatně. Pracovníci by měli mít definované role tak, aby využili svůj potenciál a nefungovali jako roboti-kodéři. Tento obor by měl být na určité výši a ne obdoba "montovny", kdy všichni jedou na minimální plat, akorát v oboru software.

    Vidím v tom vliv módy outsourcování do Indie a dalších rozvojových zemí, kdy se projekty rozdrobí tak, aby práci zvládli kodéři bez znalostního přesahu a snahu to pak vše uřídít přes zuřivé Agile řízení. Myslím, že tímto přístupem si mnoho firem zadělává na problémy, které zatím vůbec neumí dohlédnout.

  • 6. 4. 2021 15:36

    Miroslav Šilhavý

    Pracovníci by měli mít definované role tak, aby využili svůj potenciál a nefungovali jako roboti-kodéři.

    To je nereálné i nehospodárné. Potřebujete mít armádu robotů-kodérů, kteří rozumí řemeslu, ale nic nového nevymyslí. Mnozí jsou skvělí, ale nechtějí přemýšlet do stran. Programátora často nezajímá, jak rychle obslouží server požadavek, jak se sečtou latence a kolik požadavků zvládne API. On je placený za svoji práci, kterou má mít hotovou. Když se začne vrtat v těchto dalších otázkách, možná by něco zlepšil, ale možná taky ne. Ale rozhodně by nestihl svoji práci, za kterou je hodnocen.

    Vidím v tom vliv módy outsourcování do Indie a dalších rozvojových zemí, kdy se projekty rozdrobí tak, aby práci zvládli kodéři bez znalostního přesahu a snahu to pak vše uřídít přes zuřivé Agile řízení.

    Zrovna toto ale může fungovat a mnohdy funguje. Kvalifikovaný je zadavatel, který umí sepsat a popsat, co se má vyrobit. Dělník provede - a může být třeba v Indii. Zrovna tento typ práce moc hezky ukazuje, kde leží odpovědnost - v rámci Česka se dohadujeme, že na to měl myslet programátor "protože přeci ví". U Inda to neočekáváme a víme hned, že něco zbabral zadavatel. To je nápověda, jak by to rozdělení odpovědností mělo fungovat.

    Myslím, že tímto přístupem si mnoho firem zadělává na problémy, které zatím vůbec neumí dohlédnout.

    Opačným přístupem taky. Zase Vám uletí čas na projektu. Je sice hotovo, ale proděláváte - to je stejně nefunkční model.

  • 6. 4. 2021 15:55

    vdx

    To všechno co píšete je určitě pravda, ale je to z extrému do extrému - netvrdil jsem, že ty přístupy nemůžou fungovat ale kritizoval jejich nadužívání. Co se týká outsourcingu, tak i z toho co píšete vyplývá, že musíte mít další mezičlánek, který se postará o ty závislosti, které externí kodér nevidí. A zadavatel už vůbec, pokud to zadání nebude dopracované do všech detailů, se znalostí konkrétní technologie, a tu mu zase nejspíše sděluje zhotovitel, takže se kruh uzavírá.

  • 6. 4. 2021 16:09

    Miroslav Šilhavý

    @Václav Dvořák

    Ten mezičlánek byste měl mít, i když neoutsourcujete. Když ho nemáte, přináší to ty samé problémy, jen trochu jinou formou. Při outsourcingu do zahraničí se to projeví nefunkčností. Když Vám to chybí interně, tak se to projeví na prodělku na projektu. Nikdo nemůže pracovat s trvalým prodělkem, musí si to někde vynahradit, nebo zkrachovat. Právě tento moment vede ke korupci. Soutěžitel zanedbá některý aspekt projektu, ale domluví se se zadavatelem (úředníkem), že nad tím pak přimhouří oči nebo nebude tlačit na pilu. Ostatně, takto se sichrují i výběrová řízení. Podají je dvě spřátelené firmy - jedna levně, ale s formální chybou, druhá draze, bez chyby. Pokud to stačí na vítězství drahé firmy, tak se formální chyba najde a levná nabídka se vyloučí. Pokud tam skočí nějaký konkurent, tak se formální chyba přehlédne a vyhraje to levná nabídka.

    Když budete mít aspoň soubor minimálních požadavků na specifikaci projektu, omezí se tím ta prázdná místa a nebude tolik docházet ke korupci. Ani pro jednoho nebude platit "že přehlédl, nedomyslel" a úředníkovi se nedostane do ruky moc nad tím přimhouřit oko. Nebude mít co rozhodovat, kromě objektivních skutečností. Pokud rozhodne proti faktům, bude postihnutelný.

  • 6. 4. 2021 11:37

    regine

    CITACE: "Chyba ale byla, že zátěž pro výkonnostní test generovali uměle, " KONEC Že by vůbec neprovedli 3. fázi testů - produkční testy se scénářem s "nezkušenými uživateli"?

  • 6. 4. 2021 11:43

    Uncaught ReferenceError:

    pokud ale tohle nemají řádně ošetřené na backendu a je možné ho několika tisíci požadavky odstavit, že celá aplikace odpadne, jedná se o zranitelnost náchylnou na DoS.

    Tohle vypadá na nevhodně použitou architekturu řešení pro výpočetně náročné operace, neošetření na frontendu jen velice rychle problém odhalilo.