U nás ve firmě máme jednu zajímavost, která mě postupem času pěkně leze na nervy a přijde mi jako dost trapná a velice nepřínosná věc. Stejně jako i v jiných firmách se u nás dělají čtvrtroční pracovní pohovory, kde si prostě programátor posedí se svým nadřízeným, oba se ohlédnout zpět a snaží se zhodnotit jak práci programátora tak práci onoho nadřízeného jak ho vidí programátor. Výsledkem takového pohovoru obvykle bývají cíle na další období, které se při dalším pohovoru opět zhodnotí a takhle se jede pořád dál.

Součástí pracovního pohovoru je programátorský test, který programátor musí ve stanovenou dobu vyřešit. Takový test vznikne, že si "nejlepší " borci ve firmě (bývají to šéfové týmů) sednou a dají dohromady zadání. To může být v lepším případě vymyšlení algoritmu řešící zadaný problém, nebo jen otázky týkající se např. frameworku Javy.

To že musím psát nějaký test, místo abych dělal smysluplnou práci mě už ani tak nevadí. Když na to firma má, ať si to dělá. Klidně budu psát takové testy každý den. Co ovšem nechápu je smysl onoho testu. Zkusím se nad tím tedy zamyslet.

V oblasti software engeneeringu se už ustálilo něco čemu se říká code review. Bohužel asi né každý pochopil k čemu je to vlastně dobrý. Soudím podle mých kolegů, především nadřízených. Code review si můžeme představit jako činnost, při které např. programátor prochází kód napsaný jiným programátorem. Primárně to nedělá za účelem kontroly práce onoho programátora, ale k odhalení slabých míst v programu, k pochopení částí programu, které on sám nepsal a k udržení určité jednoty psaní kódu. Důvodů může být spousta, cílem ovšem je zvýšit kvalitu kódu potažmo výsledného programu. A právě při této velmi přínosné činnosti se dá i kontrolovat kvalita výstupu programátora a na konkrétních místech ho upozornit na věci, které nejsou vhodné a měl by se přehodnotit. Programátor slyšíc kritiku na svůj produkční kód, s kterým si velmi vyhrál pokusí se argumentovat. A máme zde další přínosnou věc a tou je, že dva programátoři řeší kód a snaží se najít lepší postup jak onu myšlenku realizovat. Pro software samotný velmi pozitivní záležitost. A takových věcí bych mohl najít opravdu hodně.

U nás v týmu (nevím jak v ostatních) se žádné code review nedělá. Důsledky si každý asi domyslí sám. Nicméně co když vedení nabude pocit, že programátoři asi nebudou moc kvalitní a chtějí zjistit jak vlastně umí programovat? Nebo napadá vás jiný důvod proč by zaváděli programátorské testy? Mě teda ne, bohužel. Právě proto mě přijde takový test nejen zbytečný, ale celkem i ponižující. Tak buď pracuji na programu, produkuji kód, který si každý může přečíst a upozornit mě na nedostatky a nebo jsem nějaký studentík, který skládá testy z programování. Nemluvě o tom, že lidé vymýšlející tyto testy nejsou podle mě nikterak zázračnými programátory o čemž svědčí i fakt, že se v poslední době testy stali spíše testem znalostí frameworku, než ověření schopnosti algoritmizace.

Proč mi to vlastně přijde ponižující? Zadavatelé si sednou k dokumentaci frameworku a řeknou si, tak tam dáme třeba dotaz co je event, jaká je syntaxe metody daného objektu apod. Já jako vyplňovatel testu mám k dispozici pouze papír a tužku. A copak mám z hlavy vědět jaká je syntaxe oné metody? Asi těžko, nejsem robot. A tak přijdu s papírem k zadavateli, který mě zhodnotí. Řekne mi, že teda nic moc a měl bych se do příště zlepšit. Děkuji, pro mě velmi přínosná informace, začnu se tedy učit dokumentaci frameworku, abych i v noci když mě vzbudíte uměl říci jakou syntax má ta či ona metoda. Jen doufám, že se Sun s novou verzí Javy opozdí, abych toho neměl tolik.

Tak i takhle může fungovat software engeneering :-))