dotNETportal.cz

Všimol som si 2 mesiace starý príspevok, ktorého pisatel si sťažuje (?!) na to, ako sa zmenilo programovanie. Je mi lúto, že (zrejme mladíci) pamatníka starého dobrého programovania tak strhali, mne hovoril z duše.

Mám jednu bizardnú skúsenosť z poslednej doby, ktorá sa dotýka danej temy :

Uchádzal som sa o zamestnanie v jednej firme. Poslali mi testovací príklad, išlo o to naprogramovat riešenie nejakej geometrickej úlohy, nájsť jedinú vyhovujúcu z nejakých miliárd možností. Vymyslel som riešenie, ktoré sa mi zdalo optimálne, naprogramoval som ho v C# a poslal. Odpoveď ma zdrtila, ze vraj som to síce naprogramoval rýchlo a program správne nájde jediné riešenie ulohy, ale z hladiska princípov OOP ( ktoré samozrejme ovládam, ale v danom prípade som na ne vedome kašlal kuoli maximálnej efektivite ) je to hrúza a vobec je to celé akési zbytočne komplikované a neprehladné ... Na ukážku ako to malo vypadať, mi poslal svoj program na riešenie tej úlohy a to som sa zdesil ja. Dal som do obidvoch programov stopky, výsledok bol taký, že jeho vzorový program hladal riešenie 80 msec, ten moj bastard to vyriešil v jednej milisekunde. Samozrejme som mu napísal niečo v zmysle, ze moj program mu pripada komplikovaný, pretože je chytrý a on sa samozrejme urazil a z práce nebolo nič ;-(

Svojim kamarátom som to komentoval tak, že chytré riešenie v programovaní može byť ocenené len vtedy, ked sa to nedá urobiť hlúpo, ale dnes sa už bohužial takmer všetko dá urobiť aj hlúpo. Kedysi hodne dávno by moj program hladal riešenie štvrthodinu, kým ten jeho celý deň ( takže by bol prakticky neodladitelný, predstavte si, ako ladíte niečo, čo vám na nejakú chybičku padne po niekolkých hodinách ), to by bol brutálny rozdiel. Teraz sú obidva programy "rovnako funkčné", pretože tisícina alebo desatina sekundy, to je prašť ako uhoď ...

V iných prípadoch, keď sa uchádzam o prácu, končím banálnejšie, obvykle na tom, že nemám nič moc prehlad o nových skvelých technológiách. Súčasný programátor je už ako lekár, mal by len vedieť a ovládať co najviac nástrojov a postupov, ktoré boli vymyslené "hore" a radšej nič vlastné nevymýšlať ... Kto s tým nesúhlasi a myslí, že tvorivosť v programovaní sa ešte stále dá nejako využiť, može ma zamestnať ;-)

S tím vymýšlením vlastních věcí namísto použití X let osvědčených postupů a nástrojů asi opravdu půjdete žebrat. Dnes se vyplatí vymýšlet jen velmi úzce specializované konkrétní věci, všechno ostatní už bylo vymyšleno a realizováno. A pokud se chcete uplatnit, musíte mít samozřejmě alespoň obecný přehled o nejnovějších věcech z daného oboru. Co se týče aplikací tak dnes už skutečně nezáleží na maximální optimalizaci kódu pro rychlost, ale na dobře navržené architektuře a z toho plynoucí rozšiřitelnosti a škálovatelnosti.

Bohužel / bohudík programování není jen o tom napsat rychlý algoritmus. Je to o používání technologií, které jsou pro danné řešení ideální, znalosti jazyka a schopnost navrhnout dostatečně kvalitní architekturu. Rozhodně je potřeba schopnost komunikovat v týmu a řešit problémy okolo. Prací, kde dostanete jasný úkol a musíte ho co nejoptimálněji vyřešit je bohužel většinou jen minoritní množina.

Díval som sa na pekný kurz pana Hercega k VB. Je tam zaujímavy moment. Ako zistíme, či číslo je prvočíslo ? No, skúsime ho vydelíť všetkými menšími číslami. Keď som to videl, pohoršene som pokrútil hlavou a pustil som cyklus len po odmocninu. Na konci príslušného článku je výzva, aby sa čitatelia pokúsili zamyslieť nad tým, či naozaj treba prejsť všetky menšie čísla, či nestačí po odmocninu. To mi prijde velmi symbolické. Pre starých programátorov bolo základnou axiomou najprv sa zamyslieť a potom písať kod. Opačne to fakt nešlo, pretože kód napísaný bez rozmýslania bol v 99 % prípadov na houby. Dnes sa píše bez rozmýslania, pretože beštiálna technika toleruje aj hodne velké hlúposti ( povedané politicky korektne : aj značne neoptimálne riešenia sú dostatočne kvalitné ) a ak chceme, aby sa mladý programátor aspon a posteriori zamyslel nad tým, čo napísal, je treba ho k takému neštandardnému úkonu explicitne vyzvať.

Inak, kto viete o technológiách, ktoré ešte stále rozmýšlanie vyžadujú, tak sem s tým, pre nás staromilcov by sa to mohlo hodiť. Mňa z toho mála, čo v súčasnom IT poznám, napadá len t-sql. Hlúpe dotazy na velkých databázach ešte stále chvalabohu chodia neúnosne pomaly ;-) Stroje síce svinsky zrýchlujú, ale aj databázy svinsky rastú, takže možno ten problém tu ešte chvílu bude (?!)

T-SQL - problém tu za pár let nebude, optimalizátory budou tak chytré, že udělají cokoliv, aby i špatně napsaný dotaz zpracovaly co možná nejrychleji.

Pro mě osobně má čitelnost kódu a jeho rozšiřitelnost taky přednost před rychlostí zpracování. Je to pochopitelné. Za pár let bude mít každý ňouma na stole PC s 32 jádrovým procesorem a terabajtem paměti, takže mu o rychlost fakt nepůjde. Ale čitelnost kódu bude i nadále důležitá.

K tej čitatelnosti kódu si dovolím malinko oponovať. Jeden zo zakladných princípov OOP je predsa ten, že objekt má byť čierna skrynka, ktorá reaguje na svoje vstupy správnym výstupom. Kolega, s ktorým by som mal spolupracovať, potrebuje odo mňa funkčné objekty, rozumieť mojmu kódu je zbytočné, znamená to duplicitnú prácu.

To máte sice pravdu, ale jde o to že je potřeba udržovat i tu třídu kterou napíšete a která se navenek chová jako černá skříňka. Nikdy totiž nevíte jestli do ní nebude potřeba v budoucnu něco dopsat nebo změnit. A pokud nebude kód dobře čitelný, tak si třeba za rok už nebudete pamatovat co a proč tam tak je. A to nemluvím o tom kdyby tento kód měl udržovat někdo jiný.

S vámi bych na nějakém týmovém projektu skutečně pracovat nechtěl. A to se ani nezmiňuji o komentářích, které jsou pro vás také zcela jistě zbytečná hovadina a ztráta času.

Skutečně si přečtěte Co programátory ve škole neučí, aneb softwarové inženýrství v reálné praxi a zjistíte, jak hloupé vaše názory jsou. Několik kapitol se tam zabývá problematikou, proč je lepší psát přehledný a čitelný kód na úkor rychlosti.

To by mě zajímalo, jak to mají ty optimalizátory udělat. Jedna věc je optimalizace samotného dotazu (exekuční plán), které jsou dnes v lepších databázích na opravdu excelentní úrovni. A druhá věc je způsob uložení dat. Pokud nebude vhodně navrhnuté uložiště, optimalizátor v ničem nepomůže. To je stejné u přímého zápisu do sektorů na disk i u automaticky udržovaných indexů. Abstrakce se může zvyšovat, ale návrh bude vždycky nutný.

Ono je vždycky důležité optimalizovat, jen prostě dnes to není potřeba dělat v takové míře. Pokud chce zákazník funkci XY a ta bude neoptimalizovaně napsaná za 5 hodin, bude žrát 50MB paměti a trvat 10 vteřin, komu pomůžete tím, že to budete psát 10 hodin, bude to žrát jen 5MB paměti a bude to hotové za 5 vteřin? Zákazník si dvojnásobnou cenu za rozdíl ve výkonu nezaplatí. Otázkou tedy je, proč to dělat?

Optimalizátory - přijde prostě doba, kdy nebudeme databázím říkat KAM mají data ukládat, ale pouze CO chceme uložit. V současné době jsou tu relační a objektové databáze, kdoví, co tu bude za pár let.

Ono to tak i dnes je. Také neříkáme kam data ukládat. Například SQL Server si podle množství dat sám organizuje paměťový přístup (malé tabulky jsou v mixed extends a větší mají samostatné extends) nebo fungování statistik (neříkáme jak daty iterovat, optimalizátor to matematicky odhaduje). Úrovně abstrakce se zvyšují (sektory disku > soubory > datový soubor > alokace > extends > pages > data rows).

Vyšší výkon počítačů a rychlejší disky dokáží takové abstrakce řešit dobře. Ale ať to budou jakákoliv data (relační i jakákoliv jiná), počítač nemá věšteckou kouli, aby dokázal předpovídat jak se s daty bude pracovat. A to jak se s nimi bude pracovat je důležité dopředu znát a podle toho na to uložiště připravit (ať už je to i třeba jen obyčejný index). Pokud to neuděláme, bez ohledu na databázi, výkon nikdy nemůže být dobrý.

Zase další diskuse na téma "staré dobré časy". Bohužel rychlejší program neznamená lepší program.

Jestli některá operace trvá 1ms nebo 80ms, je většinou úplně jedno. Pokud optimalizace z 80 na 1ms trvá třeba 3 hodiny, tak byste musel aplikaci spustit cca 15000krát, aby se vám ta investice vrátila. Pokud to tak je, fajn, optimalizace se vyplatí.

Nedávno se mi kdosi chlubil, že týden optimalizoval úložiště dat tak, aby nezabíralo 10GB, ale 9GB, přičemž jeho velikost nijak dramaticky nenarůstá. Docela koukal, když jsem mu spočítal, že strávil týden ušetřením 1 Kč (2TB disk stojí 2 000Kč).

Že některé problémy nemá smysl řešit ale neznamená, že dnešní programátoři nic neumí a že dnes je programování jednodušší. Naopak, řešíme jiné problémy, dnešními buzzwordy je testovatelnost, dependency injection atd. Nejběžnější algoritmy za nás již někdo napsal a vymyslel, jen zřídkakdy je potřeba napsat je rychleji, nevyplatí se to. Navíc dnes se často výkon obětuje právě rozšiřitelnosti a lepší udržovatelnosti.

Btw k mému článku, o kterém píšete - to zamyšlení je schválně až na konci. Je třeba si uvědomit, že se jedná o tutoriály pro začátečníky, kde je potřeba záměrně zjednodušovat a nevychrlit moc věcí najednou. V článku je tuším hlavní důraz na pochopení for cyklu, a vzhledem k tomu, že seriál čtou i děcka, co ve škole ještě odmocniny neměly, nechtěl jsem odbočovat od tématu.

Pokud jste u předchozího pohovoru pohořel, zkuste mi poslat kousek svého kódu. Ve své firmě zrovna programátory hledám a člověk s dobrou znalostí algoritmů a schopnostmi optimalizace by se mi hodil. Třeba jste jen narazil na firmu, kde tomu šéfoval nějaký neumětel. Na druhou stranu zahodit principy OOP chce velmi pádný argument a v kódu určitě nějaký vysvětlující komentář, proč tak činím. Důvody, které jsou jasné vám, nemusí být jasné tomu, kdo ten kód čte.

V podstate s Vami súhlasím, pán Linhart, ale nedá mi, aby som tu neuviedol jeden citát:

" Everything that can be invented has been invented."

Charles H. Duell , Commissioner, US patent office, 1899

Pánovi 178.20.136.60 odporúčam skúsiť na tejto adrese:

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052-6399

USA