Je toho plný Facebook a Twitter a web vůbec: nechápavé pozastavování se nad tím, proč proboha tak velká firma, jako je {Vodafone, Google, Alza, Twitter, Seznam, …}, neudělá něco s XYZ. Vždyť je přece každému jasné, co je třeba udělat. Na co mají ty firmy X zaměstnanců? Spravit to je přece pro dobrého {programátora, designera, překladatele, …} záležitost jednoho dne, nebo není?
Není.
Například: Něco jiného je spravit PHP web, který si programuju sám, a který má maximálně desetitisíce řádků kódu běžících na jednom serveru, a něco úplně, úplně jiného je opravit byť maličkost v tisícihlavém monstru programovaném stovkami lidí, běžícím na dynamickém počtu serverů a obsluhujícím v náporech {desetitisíce, statisíce, miliony} simultánních požadavků. Tady je neúplný výčet důvodů, proč tomu tak je:
- Skoro každé takovéto monstrum nevyhnutelně spolupracuje s jedním nebo více zastaralých (=legacy) systémů.
- Věděli jste, že některé německé bankovní systémy pořád ještě běží na COBOLu? Ano, na tom COBOLu.
- Přepsat vše od nuly by bylo určitě krásné, ale… v legacy systémech bývají desetitisíce člověko-dní práce. Přepisování od nuly většinou znamená: návrat starých bugů, zastavení vývoje nových věcí, a nakonec vyprodukování stejně hnusného kódu, se kterým se začalo.
- Práce ve velkých týmech je jiná.
- Už není možné, aby každý věděl všechno o všem.
- Je nutné co nejvíc vyloučit, aby se do produkční verze dostala chybka jednoho programátora. Velkou část práce zabírají věci, které v malém týmu tolik neřešíte, jako code reviews nebo psaní neprůstřelných unit testů. To znamená: vše je (mnohem) pomalejší.
- Distribuované systémy jsou větší bolest, než si většina lidí uvědomuje.
- Spusta věcí vypadá na papíře lehce, ale v reálu je to mnohem těžší. Jestli v centralizovaném systému rozšíření funkcionality o 10% zabere týmu
x
hodin práce, v distribuovaném systému to může být v klidu10x
.
- Spusta věcí vypadá na papíře lehce, ale v reálu je to mnohem těžší. Jestli v centralizovaném systému rozšíření funkcionality o 10% zabere týmu
Příklad z jiného soudku je článek A Localization Horror Story: It Could Happen To You. Sean M. Burke a Jordan Lachler v něm popisují, na jaké složitosti můžete narazit u něčeho "tak jednoduchého", jako je lokalizace dvou výstupů z programu...
He elaborates: In "I scanned %g directories", you'd expect "directories" to be in the accusative case (since it is the direct object in the sentence) and the plural number, except where $directory_count is 1, then you'd expect the singular, of course. Just like Latin or German. But! Where $directory_count % 10 is 1 ("%" for modulo, remember), assuming $directory count is an integer, and except where $directory_count % 100 is 11, "directories" is forced to become grammatically singular, which means it gets the ending for the accusative singular... You begin to visualize the code it'd take to test for the problem so far, and still work for Chinese and Arabic and Italian, and how many gettext items that'd take, but he keeps going... But where $directory_count % 10 is 2, 3, or 4 (except where $directory_count % 100 is 12, 13, or 14), the word for "directories" is forced to be genitive singular -- which means another ending... The room begins to spin around you, slowly at first... But with all other integer values, since "directory" is an inanimate noun, when preceded by a number and in the nominative or accusative cases (as it is here, just your luck!), it does stay plural, but it is forced into the genitive case -- yet another ending... And you never hear him get to the part about how you're going to run into similar (but maybe subtly different) problems with other Slavic languages like Polish, because the floor comes up to meet you, and you fade into unconsciousness.
Abychom si rozumněli:
- Neříkám, že to “pozastavování se” občas sám nedělám. Naopak. Ve skutečnosti jsem se právě nedávno chytil za nos — a výsledkem je tento blogpost.
- Myslím, že je dobře, že si takových věcí všímáme a že na ně aktivně upozorňujeme.
- Tohle nepíšu kvůli Googlu, byť jsem ho do toho výčtu nahoře raději zahrnul. První impuls k napsání tohoto článku vzešel z komunikace s úplně jinou firmou.
Až příště někomu spadne eshop nebo zákaznický systém, budu se snažit mít tohle všechno na paměti. Ale stejně se mi to asi nepodaří a brzy budu zase hlasitě vykřikovat: “Proč to proboha nespraví? This is broken!”
7 komentářů:
S tou lokalizací je to vtipné - v našem frameworku to lze vydefinovat obecně pro různé jazyky a číselné výrazy a bylo to na pár řádků kódu, stačilo na to předem myslet (ale uznávám, pro nás vývojáře z neanglického prostředí je přemýšlení nad parametry a důsledky lokalizace větší samozřejmostí). Stačí jen netrpět představou, že napíšu aplikaci v angličtině a pak jen přeložím tabulku pevných resource stringů a mám hotovo.
A k té změně ve velkých systémech - dělali jsme jeden platební systém na zelené louce, běží na nových technologiích a na více serverech, a změny zdaleka nejsou takový problém. Možná u nějaké zkostnatělé banky a podobných institucí ano, ale příčinou není softwarové inženýrství a distribuované systémy, ale jejich přebujelé a nezvládnuté procesy (dělal jsem outsourcing pro jednu banku a operátora - bankomatové a mobilní aplikace - takže vím, co kolečko změn obnášelo. A bez ohledu na to byl draze placený audit kódu jen zbytečná formalita).
A v neposlední řadě, i když se s tím nějaká instituce takto fláká, výsledek je často žalostný. Prim samozřejmě hrají veřejné zakázky ušité na míru (např. aplikace České pošty pro šifrování, klíčování složenek, nebo elektronické podpisy, datové schránky, to je fakt žrádlo), ale i komerční instituce jako banky to těžce nezvládají - viz příklad ČSOB a jejich starší verze internetbankingu http://nasrany.blozinek.cz/wp-content/uploads/2008/12/csob_ib.png
Na COBOLu? Ani nemusíme přes hranice, i české..
@Mem: Rozumím. Dokážu si představit, že to vše se dá použít jako praktická výmluva. Chtěl jsem říct, že ne _vždycky_ to je jenom prasárna na straně vývojářů... :) Že za tím často stojí reálná komplexita, kterou si mnohdy komentátoři neumí nebo nechtějí představit.
@Josef: Wow. To jsem netušil.
Podle největší problém velkých koorporací je prasení IT. Pokud firemní kultura proti tomu není nastavena, problém velkých IT systémů je nekonzistence a jakési zanášení (než to spravit pořádně, radši to jen fixnu, hlavně do toho nedrbat, aby se to nerozsypalo), podobně jako třeba filtr akvárka.
Bohužel lidí, co jsou vyvoleni pro IT je nesrovnatelně méně, než by jich bylo potřeba :-(
Ale většina těch důvodů jsou spíše skutečné chyby těch firem.
- Jak mohly dopustit, že mají produkční web v pravěkém jazyku?
- Jak mohly dopustit, že nemají web pokrytý testy, který by chytnul tu "chybu jednoho programátora" a minimalizovat také dobu nasazování nové funkcionality?
- Proč mají velké týmy a ne množství malých?
Atd. atd.
Teď nemluvím o Googlu a změně v algoritmu řazení - mluvím spíš o věcech na frontendu, protože (jak jsem teda pochopil úvod článku) to jsou věci, které lidé zvenku často kritizují na webu velkých firem. A spolu s nimi si myslím, že schopná firma musí být za běžných okolností do jednoho dne schopná opravit nějaký frontendový bug.
@Michal: Jo, frontendové chyby beru. Myslel jsem spíš případy, kdy si člověk říká: "Jaktože jim to furt padá?" nebo "Proč je to tak pomalý?" nebo "Proč musím tohle vyplňovat?"
Často jde o věci, které jsou sice neomluvitelné, ale nejdou zas tak rychle opravit. Přitom člověk (třeba já) má tendenci podceňovat práci, kterou to dá.
Souhlasím, že je to chyba těch firem. Ale už je těžké určit, koho přesně v těch firmách. Často to není chyba těch, kteří se to horko těžko snaží řešit.
Zkuste pokryt testy treba 2 mil. radku. Byl jsem v tymu co spravoval takove mnozstvi kodu 7 let (Deutsche Börse, Frankfurt). COBOL, C, OpenVMS, OracleRdb, Embedded SQL, SWIFT protokol ... Do toho vseho kodu vam pise dalsi veci 20 programatoru protoze trh nepocka a konkurence je velka. Nebo tohle mnozstvi kodu zkuste prepsat do neceho jineho, stejne rychleho.
Okomentovat