Špatné předpoklady v IT

Náš svět je obrovský, komplikovaný a neobyčejně komplexní, a tak není divu, že každý neví všechno a že zdaleka ne všechny informace se vždy ke všem dostanou. A tento problém se nevyhýbá ani IT odvětví. O konkrétních neznalostech v IT, se kterými jsme se setkali, si povíme právě v tomto článku.

 

IT odvětví by toho samo o sobě příliš nezmohlo. Stává se nástrojem pro byznys, který se snaží své fungování vštípit do budovaných IT systémů. Neznalost fungování světa, obzvláště pak fungování té či oné byznys domény, se nejčastěji projevuje ve formě špatných předpokladů, které jsou učiněny architekty, testery či samotnými programátory při analýze, návrhu, implementaci i testování. V tomto článku jsme se zaměřili zejména na špatné předpoklady relevantní pro Česko, protože o těch všeobecných bylo již napsáno mnoho.

 

Rodné číslo

Ačkoliv se řada z níže uvedených poznatků často zmiňuje už na VŠ, stále dokola vídáme i ve velkých systémech opomenutí některého z následujících bodů:

• Rodné číslo rozhodně není unikátní. V tomto státě existují lidé, kteří mají rodná čísla shodná. Můžete namítnout, že jde jen o výjimky a občasná dřívější selhání, ale tento fakt je potřeba brát v potaz a rozhodně není vhodné z r. č. dělat unikátní identifikátor v databázích.
• Ne všichni rodné číslo mají, je potřeba myslet i na lidi ze zahraničí.
• Nemusí mít vždy 10 číslic, starší jsou kratší.
• Nemusí být vždy dělitelné 11, opět například starší rodná čísla.

 

Adresy, geografie a mapy 

Velmi vděčné téma článků o špatných předpokladech. Zde zmiňme ty, na které jsme narazili my:

• Pro lidi z (velko)měst je dobré si uvědomit, že ne všechna místa mají ulice, takže vynucovat jejich zadání není úplně nejlepší nápad.
• Google Maps (a ekvivalentní služby) při určování adresy z bodu na mapě nemusí vždy vracet korektní lokaci, dokonce ani opačně k adrese nemusí vracet správné místo. V obou případech potřebujete povolit manuální zadání či úpravu, aby se na údaj mohli uživatelé systému spolehnout.
• Google Maps (a ekvivalentní služby) při napovídání nemusí mít všechny platné adresy, opět je třeba umožnit ruční zadání. Nespoléhejte se na to, že jde o dočasnou záležitost. Známe služby, ve kterých chybí adresy i víc než 4 roky.
• Územní (správní) celky nemusí představovat vždy jen jeden polygon, můžou to být i množiny polygonů. Případný úřad může ležet i zcela mimo dané území.

 

E-maily

Jejich formát a validace jsou bažina, ve které všichni doufají, že jim projde to, co zrovna dělají:

• E-mailové adresy lišící se velikostí písmen mohou být ve skutečnosti jiné e-mailové schránky, takže kontrola unikátnosti ignorující velikost písmen je taková vachrlatá. Na druhou stranu bazírování na velikosti písmen při každém přihlášení se vymyká uživatelskému očekávání.
• Někteří e-mailoví provideři přiřadí uživateli celou řadu adres lišících se pouze množstvím a rozmístěním teček, například máte-li example@gmail.com, pak vám dojde i e-mail pro e.x.a.m.p.l.e@gmail.com.

SMS

Mají je všichni, tak proč je nevyužít:

• Zasílání SMS opravdu není spolehlivé. Nelze se spolehnout, že dojdou obratem, ani že vůbec dojdou. Máme zkušenost s obojím a je dobré se na toto nespoléhat a klientům se snažit takové nápady vymlouvat. Jde zkrátka o best-effort službu, o kterou je potřeba se starat, protože její (ne)spolehlivost závisí na tom, jaký obsah budete posílat, jak často a jakou budete mít reputaci v odesílacích službách.

 

Časové zóny

Jsou evergreenem článků o špatných předpokladech, my zmíníme dva problémy, na které jsme narazili:

• Časové zóny tu nebyly odjakživa, proto když vaši vývojáři střílí kamkoliv data jako 1900, měli byste zpozornět. Obzvláště když používáte data a časy s časovými zónami, protože před jejich zavedením mělo prakticky vzato každé místo s hodinami svoji vlastní časovou zónu (podle skutečného poledne).
• Programovací jazyk (v našem případě PHP) nemusí mít podporu pro úplně všechny časové zóny (respektive jejich časové posuny). Narazili jsme na to tak, že jsme dostali od databáze časovou zónu s posunem o X minut a Y sekund (tzn. v roce 1900 na jistém místě před zavedením časových zón), přičemž PHP podporuje maximálně čtvrthodinové časové zóny a s tímto vás pošle do háje.
• Nespoléhejte se též na to, že si řeknete, že budete v celé aplikaci pracovat s daty a časy UTC a pak je do databáze budete ukládat (v našem případě Postgres) do datového typu bez časové zóny. Pak stačí jeden dotaz do databáze, ve kterém budete počítat hodiny v noci 28. března 2021, a nějak vám to nebude sedět (nápověda: změna času).

 

Ostatní

Náhodné perličky, které občas odhalí jen sám život:

• Nespoléhejte se na to, že řazení pro češtinu bude fungovat podle pravidel pro češtinu, ta jsou totiž ve své úplnosti počítačově neimplementovatelná.
• Skloňování příjmení je obtížně řešitelný problém, opravdu jej neudoláte regulárními výrazy a ani řada knihoven či externích služeb nepodává 100% výsledky.
• Zdaleka ne všechny knihy musí mít ISBN. Je zde řada těch, které tento identifikátor nemají, protože jsou vydány neoficiálně nebo byly vydány před rokem 1989, kdy nebylo používání ISBN zavedeno vůbec.
• Vyvolávací cena aukční položky opravdu nemusí být vždy alespoň 1 Kč, někdy to může být i 0 Kč.
• Výše daní či zařazení zboží do daňových tříd se může změnit i v průběhu měsíce. Při střetu s (právní/vládní) realitou se zkrátka pokaždé raději připravujte na to nejhorší.

 

Co si z toho odnést? Předpoklady vždy ověřujte a v případě nedostatečných odpovědí otravujte tak dlouho, dokud nezískáte kýžená zjištění. I přesto však některá porozumění přináší až sám život. Někdy za to nikdo nemůže, občas se prostě jen změní svět kolem nás.