Adame, dovolil bych si malou radu. Dobrý programátor se pozná tak, že když se po třech až pěti letech podívá na svůj kód a nechce se mu zvracet a ne ta že to o sobě tvrdí.

Pointa budiž v tom, že dobrý programátor píše kvalitní kód a když se k němu po dlouhé době vrátí je s ním stále spokojen. Ale to není pravda. Pak mě napadla další extrémní varianta:

Dobrý programátor se pozná tak, že když se po třech až pěti letech podívá na svůj kód tak by ho nejradši přepsal od základů.

To je samozřejmě taky úplně vedle. Ale hezky to vystihuje klasickou nemoc mnoha kolegů. Napsat – zahodit – přepsat – a tak dále a pořád dokola. Nikam to nevede a efektivita mizerná. Tak jak se teda pozná ten Dobrý programátor?

Na první pohled těžko. Nicméně myslím, že se dá vycházet z výše uvedeného. Ani jeden z případů není správně. V prvním případě máme tu čest s člověkem, který se za uplynulou dobu nic nenaučil a nikam se neposunul a v druhém případě v podstatě taky.

Já vidím kvalitu programátora v tom jak se dívá na svůj produkt. Dalo by se to přirovnat k rozdílu mezi kamenosochařstvím a modelováním z plastelíny. Sochař vytesá sochu a jakmile je hotová už se v podstatě nedá změnit. Modelář pracuje s pružnou hmotou, která reaguje a dá se dále tvarovat. Stejné je to s kódem. Jediná věc, která je při tvorbě programů jistá je, že nic není jisté. Svět kolem nás se neustále mění a stejně tak programy a požadavky na ně. Dobrý programátor toto ví a staví svoje programy jako modely z plastelíny, kterou je možné dále tvarovat, protože tesat to pokaždé znovu do kamene se prostě nevyplatí.

Nutno podotknout, že i pružnost se dá dotáhnout do extrému a pak člověk mezi všemi těmi abstrakcemi hledá kousky kódu, které něco dělají. Být dobrým programátorem znamená umět najít rovnováhu a to ať si říka kdo chce co chce v osmnácti neumí žádný.

Jakási programátorská poučka říká, že programátorské úkoly se dělí na ty trivální a na ty co už někdo řešil. Jiná poučka říká, že každý problém se dá rozložit na konečné množství triviálních problémů. Kdyby toto neplatilo, byly by nám všecky současné programovací jazyky k ničemu.

Osobně si programátorské problémy dělím na tři skupiny podle toho, zda si jejich řešení dokážu představit

1. a jsem si jím jistý
2. a jsem si jím jistý, ale nakonec to dopadne jinak

1. jenom velmi vágně

Zajímavá je samozřejmě druhá a třetí kategorie. Ta často vede k nekonečnému myšlenkovému procesu a pocitu beznaděje nebo ještě hůře inkompetence. Když jsem byl dotázán jak se s těmito situacemi vypořádávám podařilo se mi zformulovat řešení.

Pokud je daný problém nevelkých romzěrů tak se většinou stačí ponořit do kódování a prvotní řešení časem vyplyne tak nějak samo od sebe. Jelikož se ale velikost problému odhaduje velmi těžce, práce se nakonec zlomí do pravidelných iterací jako u na prvních pohled větších problémů.

Jak už to tak bývá proces je velmi jednoduchý. Hned na začátku je potřeba v sobě zapřít touhu porozumět hned všem sub-problémům, které mě čekají. Začít je nejtěžší. Druhým krokem je vymyslet nejmenší možný funkční celek. Nemusí to být programátorské veledílo, ale také to nesmí být úplná prasárna, aby se s tím dalo dále pracovat. Následně přichází ta úplně nejtěžší fáze. Je potřeba ten nejmenší možný celek naimplementovat. Nejtežší na tom je nepodlehnout pokušení dotahovat všechno do absolutní dokonalosti. To v drtivé většině vede k nekonešným smyčkám rozšiřování nekompletního díla a nakonec do propasti neudržitelného kódu.

Jakmile je první iterace u konce většinou získám docela dobrou představu o výsledném dílu a ta spousta nezodpověditelných otázek na začáktu mi připadá jako směšný vtip. V tu chvíli přichází čas pro iterace ve stylu: test, implementace, refaktoring a znova. V horším případě v pořadí implementace, test, refaktoring.

Nejvetší sranda je, že onen počáteční strach a nejistota se zatím vždy ukázaly jako neopodstatněné, takže v podstatě zatím pořád řeším triviální problémy.

Základní postup při sestavování softwarových týmů je následující

• vezmeme N senior developerů a ti systém navrhnou a naimplementují
• k nim přidáme M juniorů, kteří se v procesu něco naučí

• celé to bude řídit L manažerů protože potřebujeme zachovat učitý pomměr X = (M+N) / L

Tento proces vychází z přesvědčení, že

• na komplexní úkoly je potřeba zkušené programátory

• na ty hloupé věci okolo nám stačí junior

a to je základní kamen úrazu. Základní problém je v přesvědčení, že existují hloupé nebo jednoduché úkoly. Opačný názor, se kterým já souhlasím:

• dobrý programátor programuje byznys logiku
• dobrý programátor jednoduché úkoly automatizuje
• dobrý programátor testuje

• dobrého programátora zájímá klient více než zadání

V případě, že najímáte jenom takové programátory odpadá vám potřeba mít hromadu manažerů, stačí když se shodnou na jednom vůdci pro řešení oněch nerozhodnutelných filozofických problémů. Do mixéru se pak přihodí SCRUM nebo XP a tým je hotov.

V čem je rozdíl? Takový tým bude podstatně dražší to ano. Nicméně neporovnatelně efektivnější a hlavně dlouhodbě levnější na provoz. Nejdůležitější rozdíl je v kvalitě odevzdané práce a to by mělo být to co nás všechny nakonec zajímá. A kde je ten nový typ manažera? Kdo ho ještě hledá tak nepochopil.

Server-side security je prostě z mého pohledu vyřešená. Prostředky jak se 99% útoků bránit jsou jednoduché a tomu zbytku se jde bránit jenom velmi těžce. Řeknu-li to jinak, tak pokud se dá stránka hackout pomocí SQL injection nebo XSS je čistě blbost dodavatele/provozovatele. Tomu, že vám někdo nakonec hackne captchu, nezabráníte, ani kdyby jste se rozkrájeli.

Na straně klienta je to něco jiného. Nad člověkem, který vaši službu používá nemáte v podstatě žádnou kontrolu. Jediný bezpečnostní prvek na klientské straně je autentifikace, čili nějaký proces, kterým se propojí klient a jeho uživatelká data na straně aplikace. Většinou to vypadá tak, že zadáte jméno nebo email a heslo. Tomu se většinou říká jednoduchá autentifikace. Přidání dalších fází identifikace uživatele se bezpečnost svyšuje.

Bankovní sektor pomalu přechází na dvoustupňovou autentifikaci (někteří dokonce na 2 a půl stupně). Jak to vypadá?

• 1. stupeň: Uživatel něco ví (např. jméno a heslo).
• 2. stupeň: Uživatel něco má (např. mobilní telefon na který mu je zasláno další heslo s omezenou platností).

• 2,5. stupeň: Uživatel má ještě něco jiného (třeba šivrovací certifikát nebo čipovou kartu).

Vícestupňová autentifikace sice radikálně zvyšuje bezpečnost na straně klienta, ale její spolehlivost je taky diskutabilní a ještě k tomu snižuji použitelnost aplikace. Její nutnost vyšla najevo poté co lidem na staně serveru došlo, že:

• Lidé jsou hloupí a nepamatují si složitá hesla

• Lidé jsou líní a i jednoduchá hesla si píší na papírky a lepí na monitor

Toto se nidky nezmění. Běžný uživatel zůstane běžným uživatelem a klidně si jako heslo zvolí jméno svého psa. O důležitosti zvolit si bezpečné heslo můžeme uživatele školit jak chceme, ale 80% z nich stejně pořád bude mít hesla jednoduchá a ti co si zvolí složité je buď zapomenout nebo si je nějkam napíšou. Hesla se prosťě ztrácejí stejně tak jako mobily a míra škod způsobených útoky na iternetové bankovnictví v americe radikálně roste. V čechách zatím trpí jenom Česká spořitelna, ale zato docela často.

A východisko? Jediné co mě napadá je biometrika. Ke všem svým počítačům se přihlašuji pomocí čtečky otisků prstů a heslo mám nastavené bezpečné a málem si ho už taky ani nepamatuju. Jak to ale přenást na web?

Jednou možností je nastavovat si bezpečná hesla a nechat čtečku otisků je vyplňovat za nás na základě ověření otisku. To je ale spíše work-around než skutečné řešení. Moderní browsery se asi skutečně budou muset stát pravou aplikační platformou a pokud výrobci hardwaru přijdou se standardním API pro práci se čtečkami bio-údajů tak, aby browser nemusel řešit ovladače a podobné blbosti, snad se jednou dožijem bezpečnějšího webu.

Nepamatuji si kdy jsem poprvé napsal svůj první řádek kódu, ale mysím, že to bylo v BASICu před mnoha a mnoha lety. Měl jsem nějaký DOSový editor a v podstatě jsem moc nerozuměl tomu co dělám. Po nějaké době jsem si začal hrát s Pascalem a dokonce jsem se pokoušel psát applety v tehdy ještě mladičké Javě, ale celá ta objektovost mě přišla jakási divná a v podstatě jsem ji nechápal a nijak moc ani neřešil. Java mě tehdy nechytla.

S vážným programováním jsem se asi potkal až na střední škole. Sice jsem už jakési zkušenosti s programováním a měl jsem za sebou i díla jejichž velikost se počítala na tisíce řádků (!!!), ale ve škole jsem poznal disciplínu, která pro mě byla absolutní novinkou. Jmenovala se Algoritmizace. Stačilo něco na čmárání a zadání problému a pomocí vývojových diagramů jsme algorimizovali. Totálně to změnilo můj pohled na programování.

Proč tolik historie? Již zmíněný příspěvek evokuje jednoduchou otázku. Kdy jsem prvně použil nějaké IDE? Je dobré začínat programovat v IDE? Jednoduše odpovědět nelze. Mým prvním IDE byl TurboPascal, dá-li se tak nazvat. Byl to v podstatě jednoduchý MDI konzolový editor, který uměl zdrojáky kompilovat, spuštět a dokonce i debugovat. Žádný správce projektů, žádné build skripty, prostě jednoduchý zdroják a pár klávesových skratek pro compile, run a debug. Prostě pohoda. Dost těžko se mi představuje, že by mě po první hodině výuky programování někdo posadil před počítač, řekl “Tady máš IDE.” (Netbeans, Eclipse a pod.), tady je Java a tady je zadání a makej.

Myslím, že smyslem IDE je ulehčit programátorovi práci. K čemu je ale IDE človeku, který ještě nemá jasno v pojmech jako třída, metoda, kompilátor a bytecode? Akorát ho to zmate. Začínáte-li dnes programovat a nějak se v tom všem ztrácíte, tak to všechno zahoďte. Účelem IDE není člověka brzdit, ale pomoci mu. Pokud vás IDE jenom brzdí a nerozumíte jeho účelu, zahoďte ho. Vezměte se třeba InType, PSPad nebo vim a své první pokusy si kompilujte a spouštějte na příkazové řádce. Za pár let mi budete vděční.

O agilní metodiky se zajímám už nějakou tu dobu, ale tato přednáška mě hodně nadchla i pro opomíjené praktiky jako pair-programming a test first, code after. Celkové statistické zhodnocení vlivu Ruby a Agile na průběh projektu sice nelze brát na 100% (je to pořád jenom statistika), ale závěr je nevyvratitelný. Agilní metodiky v kombinaci s dynamickými jazyky jsou dobré nejenom pro vývojáře (práce je zábavnější), ale i pro manažery a byznys jako takový (projekty jsou úspěšnější a výdělečnější).

Zmíněný požadavek měl zhruba následující znění (pokusím se převést na jiný, ale podobný příklad):

Prosim o zmenu typu u 2 poli v nasi databazi:
1) tabulka Automobily – pole Otacky motoru – zmenit z typu Integer na String (zachovat jiz zadane hodnoty)
2) tabulka Motory – pole Otacky – zmenit z typu Integer na String (zachovat jiz zadane hodnoty)

Dále je potřeba upřesnit, že ke každému Automobilu je v databázi přiřazeno více motorů (mapř. různé výbavy) a Otáčky jsou u Automobilu i přiřazených motorů vždy stejné.

Klient má zřejmě nějaké znalosti práce s databází, protože se vyjadřuje pomocí termínů s databázemi souvisejícími pole, typ, Integer a String. Nicméně o vývoji aplikací nemá páru. Na tom není nic špatného. Je přirozeným projevem inteligentních lidí, že se snaží komunikovat s druhými jejich jazykem. V případě komunikace klient – implementátor, je ale to dle mého názoru vyloženě špatně. Ne, že bych si myslel, že každý si má mluvit po svém a na druhého kašlat Slovník komunikace by měl být založen víceméně na termínech klienta a dohodnutých termínech vyplívajících z kontextu vyráběné aplikace. Slova jako třída, tabulka, metoda a Integer nemají v takovýchto výměnách co dělat.

Smysl předchozího tvrzení se nám objasní po té, co se dozvíme, jak se výše zmiňovaná komunikace vyvíjela dále. Poté co se dodavatel logicky požadavku klienta vzepřel a dožadoval se vysvětlení potřeby takovýchto změn spolu s dodáním odůvodnění jejich nesystémovosti (u číselných polí se ztratí možnosti třídění a porovnávání a podobně), přišla následující odpověď:

Začali jsme do databáze přidávat auta na Hypermoderní pohon, u kterých se otáčky neuvádí, místo toho jsmě chtěli mít v poli Otáčky hodnotu Hypermoderní.

Tato věta se už se začíná přibližovat správému chování klienta. Říká, co chce, a ne, co má dodavatel udělat. Dodavateli logistiky taky říkáme “Převezte nám tento předmět na toto místo.” a ne “Pošlete řidiče, ať jdou pro auto, nasednou, natankujou, zařadí jedničku…”. Myslím, že podobnost je patrná. To, s čím měl klient přijít už v prvním okamžiku, je, že potřebuje rozšířít aplikaci pro správu Automobilů tak, aby uměla reprezentovat modely s Hypermoderním pohonem a představuje si, že to bude vypadat tak, že místo hodnoty Otáček se bude zobrazovat text Hypermoderní pohon. Obě strany by věděli na čem jsou, ušetřilo by se spousta času a hlavně možné katastrově při implementaci podle původního zadání.

Otázka nakonec zní, jak takového stavu dosáhnout? Klienty nám nikdo nevychová a nikdo je ani neučil jak se komunikuje s dodavateli software a poučený laik je vždy horší než úplné poleno. S lidmi se holt musí pracovat, vysvětlovat a hledat společně schůdné cestičky vedoucí k všestranné spokojennosti. Chtějte po klientech vědět, co potřebují, a ne, co máte dělat aby byli spokojení, to musítě vědět sami.

Je mi jasné, že jsem tu asi neobjevil nic nového nebo dokonce světoborného. Účelem tohoto zápisu je formalizovat jednoduchý osobní názor.

Dále přiznávám, že příklad je nic moc a vypadá docela absurdně, ale nic lepšího mě nenapadlo.