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 :-))