středa 25. prosince 2013

Webová aplikace - co byste měli znát vs. problém inteligentních programátorů

V podstatě všechny webové aplikace typu "evidence" jsou na jedno brdo. Přesto se pořád někdo pokouší něco vymyslet, nějakou svojí geniální cestičku, jak to udělat jinak (bráním se slovu lépe, protože lidi podezřívám, že je to spíš jejich vzpoura z rutiny).

Standardní zpracování jakéhokoliv požadavku by mělo být zhruba následující:
  1. Validace Javascriptem na formuláři; ten může volat speciální servlety, nebo naopak JS může být generovaný z Javy, či psaný duplicitně (alespoň minimalisticky), příp. lze použít JQuery či jinou knihovnu komponent ... možností je hodně, v krajním případě se dá tento stupeň vynechat a nechat ho na později, byť nezanedbatelně ulevuje zatížení serveru.
  2. Odeslání požadavku - nikdy ne nějakým "hackem" skládáním URL, ale vždy přes formulář! Ale to je jiné téma)
  3. Validace na serveru - úplná a přitom rychlá. Proč? Proč "duplikovat" integritní omezení databáze? Protože ...
    1. Integritní omezení databáze nepokrývají vše, ale jen nějaký minimální/přiměřenou část skutečných omezení. 
    2. Nevyplatí se aplikaci nechat dojít do nějaké fáze ukládání a pak dělat  rollback. Ten je vždycky velmi drahý. Transakce zaplňuje transakční log databáze, uzamyká záznamy a musí pak nutně spravovat fronty požadavků a hlídat, aby se nedostaly do kolize ... Vždy navíc skončíte při první chybě, pokud uživatel porušil pravidel víc, bude totéž opakovat několikrát: je otrávený, aplikáče i db přetížené, občas navíc přijde nějaká záhadná chyba, kterou uživatel už vůbec nechápe a programátor jí dlouho nedokáže nasimulovat.
      Uživatel opraví nahlášenou chybu, vzápětí dostane jinou, a tak než zpracuje jediný formulář, uteče hodina, databáze nezpracovala jeden nebo dva požadavky, ale desítky, a vy stojíte za úředním okýnkem a tečou vám oběma nervy.
      Nevyplatí se ale validovat extrémně náročné věci (co to je není tak jednoduché říct, leccos se dá optimalizovat; čili výjimečně se může stát, že něco skončí až na constraintech databáze. VÝJIMEČNĚ!)
  4. Transformace dat - uživatelské rozhraní téměř nikdy nekopíruje schéma databáze, nicméně obvykle jde už o relativně snadné namapování entit. (slovo snadné je tu klíčové).
  5. Hurá na databázi, ať relační nebo objektovou nebo třeba CSV.

Pokud si někdo "ušetřil" práci tak, že implementoval jen 2) a 5), sice napsal méně kódu, ale strávil s ním víc času a nasekal mraky chyb, které bude těžké opravovat, a aplikace nikdy nebude dost rychlá.

Slovo "snadné" je tučně, protože programátoři jsou obvykle inteligentní lidé a nenávidí jednoduchou práci "pod jejich úroveň", podceňují jí a velmi často jí udělají špatně nebo, aby se vyřádili, jí neskutečně zkomplikují.
K tomu si vypomůžou například tím, že vynechají validace. Ty pak "dolepují" všude možně, a postupně pak v kódu přibývá zpracování výjimek na různých místech, tak, jak jim uživatel nachází chyby.

To inteligentního programátora ponižuje a uráží, a tak vynalézá nebo nasazuje různé frameworky, obvykle neúspěšně, protože na něco tak složitého už je nikdy nepřilepí a nedotáhne to do konce.
Nakonec ho to už vůbec nebaví, a vydá se "prznit" na jiný projekt nebo do jiné firmy ...

Velmi důležité je vzpomenout si na základní myšlenky objektového programování - co všechno je objekt? Ano, všechno! Tak proč na všechno používáte String? Takový hloupoučký objekt na 50 řádek kódu vám ale může při validacích a kompletním zpracování ušetřit spoustu práce. Například takový VIN karoserie auta ... vážně stačí Integer nebo String? A co kdyby to byl samostatný objekt? Měl by statickou metodu parse, byl by nemodifikovatelný ... od chvíle, kdy se data z formuláře úspěšně naparsují do instance, víte, s čím máte tu čest ;)

KISS (Keep It Simple, Stupid) má jeden pro někoho nemilý důsledek - váš kód vypadá hloupě, naivně, jednoduše, brzy se pak vykládá, že píšete jen jednoduché věci, zatímco jiní se dřou na těch složitých. Nenajdete argument, nepřesvědčíte nikoho, že to není pravda. Na to, abyste to takového člověka nechali napsat po svém znova a bez přístupu k vašemu vzoru, vám žádný zaměstnavatel nedá čas. Byl by sám proti sobě ...