29. června 2013

Joel test, má ještě smysl?

Jste vývojáři? Pak už jste se možná někde setkali s Joelovým testem. Možná jste to zaslechli někde na internetu, možná se vás na to ptali na pohovoru (nebo vy jich) a možná jste to dokonce sami ve firmě zaváděli.

Joelův test je skvělý. Když jsem na něj cca před osmi lety narazil, bylo to pro mne jako zjevení. Měl jsem tehdy tři, čtyři roky zkušeností s PHP a začal jsem pronikat do enterprise Javy. A pracoval jsem ve společnosti, jejíž skóre v tomto testu bylo... ehm, nula.

The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

Expozice

Jak říkám, bylo to pro mne zjevení. A výzva. Ze své pozice jsem toho nemohl formálně mnoho ovlivnit, nicméně se mi podařilo to skóre zvednout na 3. První, co jsem udělal, nechal jsem vytvořit virtuální server, rozchodil na něm Subversion repozitory, všechny své projekty jsem tam naimportoval a začal SVN denně používat. Hned jsem se cítil o moc dospělejší :-)

OK, takže máme Joelův test - stačí si to odškrtat, co ještě nemáme, tak zavedeme a hned je z nás světová firma. Asi tušíte, že mezi odškrtnutím položky a každodenní praxí může být nebetyčný rozdíl. Já bych ale chtěl poukázat ještě na jednu věc.

Joelův test je minimálně 13 let starý - Joel ho publikoval v roce 2000. Nevím, jak to připadá vám, ale já bych řekl, že za tu dobu se svět docela změnil. Já jsem se změnil. Joel se změnil (už nemá tolik vlasů, co míval). Ten test by se taky měl změnit.

Dnes se běžně setkávám s tím, že společnosti mají v testu kolem deseti bodů. Dvanáctku jsem nikdy nepotkal. A i kdyby - už jste v softvarovém vývoji viděli něco, co by nepotřebovalo zlepšit? Většinou toho bývá docela dost.

Nemám ambice, napsat novou verzi Joelova testu. Spíš bych se nad ním chtěl zamyslet. Bude to  takový rozpracovaný materiál - rozvrtám to a třeba se to někam vyvine.

Co mi na testu vadí

Joel Spolsky (zdroj Joel on Software)
Joel Spolsky je určitě autorita, které stojí za to naslouchat. Ale není nutné se vším souhlasit. Podobné je to i s jeho testem - ten prostě vyjadřuje (tehdejší) Joelovy preference (jak to dělat), priority (co dělat) a potřeby (ne všechny body jsou možné, nebo vhodné v každé doméně). Je docela možné, že Joel žije ve světě, který je vaší realitě velmi vzdálen: 5 Reasons Why Joel's Business (Probably) Isn't Like Yours.

Tím chci jen říct, že ten test je potřeba brát s rezervou. A pokud už se s tím někde veřejně chlubím, třeba firma, měl by to být jen střípek do mozaiky. Když mi někdo řekne, že mají v testu 12 bodů, tak mě nezajímá, že to mají, ale jak to dělají a hlavně kam to chtějí dál rozvíjet. Uvedu příklad.

Do you use source control? No, znáte někoho, kdo nepoužívá v softwarovém vývoji VCS? Je možné, že někdo takový existuje, ale mě to přijde podobný "standard", jako když má dnes každý mobilní telefon. Co mě bude bude u VCS zajímat je, co mají navíc - mají nějaké metodiky/guidelines (pro branchování, mergování, tagování, komentování atd.), nějaké propojení na další nástroje? Chápu, že se někdo cítí jako šampion, že používají Git. Ale že by mi z toho spadla čelist? Asi ne :-/

Kde zůstal agilní vývoj?

Joel svůj test publikoval v létě 2000. Půl roku poté byl publikován jiný dokument, který měl nesrovnatelně větší vliv na celou následující dekádu. A je platný podnes - Agile Manifesto. Věřím :-) že všichni čtenáři ví, co tím myslím. A jen pro jistotu - agilní vývoj existoval dávno před manifestem (např. Scrum Methodology byla publikována v roce 1995).

Zdá se mi to, nebo v Joelově testu mnoho z agilních technik není? Při troše dobré vůle se některé body dají interpretovat agilně. Třeba Do you fix bugs before writing new code? Ale když si přečtete Joelovu argumentaci, tak zjistíte, že se opírá o zkušenosti a manažerská rozhodnutí v Microsoftu při psaní Wordu.

Očekával bych, že něco z agilního vývoje by se mělo do testu promítnout. A když už ne v době jeho vzniku, tak alespoň později, kdy už byly jednotlivé techniky široce adoptovány.

Je to jediný test k dispozici?

Joel má štěstí, že je slavný a tak jeho test zná (a uctívá ;-) hodně lidí. Ale jsou i jiné testy. Například když jsme o tomhle tématu disputovali na Twitteru s Banterem, tak mě odkázal na The Rands Test.

Randse mám rád a jeho test má taky něco do sebe. I když je o něčem jiném. Ale pro SW engineera je stejně podstatný, jako ten Joelův.

Jiným příkladem obdobného testu je ten uvedný v knize Leading Lean Sotfware Development. Mary Poppendieck v něm radí, ať si jednotlivé "disciplíny" obodujete od 0 do 5. 0 znamená, že jste o ní nikdy neslyšeli a 5, že o ní můžete přednášet. Pokud máte z nějaké disciplíny 3 a méně, měli byste se zaměřit na to, jak se v ní zlepšit.
  1. Coding standards (for code clarity)
  2. Design/code reviews
  3. Configuration/version management
  4. One-click build (private and public)
  5. Continuous integration
  6. Automated unit tests
  7. Automated acceptance tests
  8. Stop if the tests don't pass
  9. System testing with each iteration
  10. Stress testing (application- and system-level)
  11. Automated release/install packaging
  12. Escaped defect analysis and feedback
Mary má svůj test zasazený do daleko širšího a hlubšího kontextu - test se nachází v kapitole Technical Excellence, což je jedna ze složek Lean Developmentu.

Kdyby člověk hledal, určitě najde nějaké další testy. Uvedl jsem jen ty, na které jsem narazil, aniž bych je nějak hledal. Pokud znáte nějaké zajímavé exempláře, budu rád, když je zmíníte v komentářích.

Joel test, má ještě smysl?

Má, samozřejmě, že má. Jenom je potřeba si uvědomit, že dobrý výsledek v něm není známkou nějaké výjimečnosti. Z mého pohledu je to (v dnešní době) jen checklist, že firma/projekt dosahuje v našem oboru běžného standardu.

Joelův test také může být inspirací, pokud si chci podobný test vytvořit, s přihlédnutím ke svým potřebám (technologická/business doména, používané/zamýšlené nástroje a metodiky atd.). Určitě je to dobrý základ, na kterém se dá stavět.

Mám-li zhodnotit Joelův přínos historii :-)  tak spíš než za tento test, jsem mu vděčný, že založil Stack Overflow. Jeho test je výrazným počinem v historii našeho oboru. Ale jak říká Roy Batty: "All those moments will be lost in time, like tears in rain."

8. června 2013

Měl by mít vývojář portfolio?

Jednou z činností, které vás, jako seniorního vývojáře, mohou potkat, je dělání pohovorů s kanditáty, kteří by chtěli ve vaší firmě pracovat. Řekl bych, že je to docela zodpovědná (a zajímavá) činnost. Přece jenom, vybíráte své potencionální kolegy.

Přesto bývá (dost často) tento úkol pojat nekoncepčně a nahodile. Pohovor dělá, kdo má zrovna čas, zkouší se věci, které s prací přímo nesouvisí, v rámci firmy to každý dělá "trochu" jinak... Tak jako v jiných oblastech, i zde je známkou kvality konzistence.

Před časem jsem psal, jak dělám java pohovor já, kde jsem popsal postup, který používám cca poslední dva roky. (Teď se změnou zaměstnání jsem v něm provedl dvě úpravy, o kterých napíšu, až si to trochu "sedne".) Jedním z bodů, který po vývojářích vždycky chci, je, aby mi před pohovorem poslali ukázku svého (java) kódu dle vlastního výběru. Pojďmě se na to podívat trochu zevrubněji.

Proč chci ukázku kódu?

Kromě úvodní informační části pojímám interview jako diskuzi. Je to diskuze mezi mnou - team leaderem, či architektem - a potencionálním kolegou. Své názory umím hájit, ale nejsem autoritativní - myslím, že nejlepší řešení vyrůstají z kvalitní diskuze.

Kód, který mi kandidát pošle (a který pak spolu probíráme), je pro mne podkladem pro takovou diskuzi. V kódu si pomocí TODO označím místa, na která se chci zeptat. Jsou to místa, která mě nějak zaujmou - nejsou mi třeba jasný, jsou inspirativní, anebo je považuji za chybná. Nad tím pak diskutujeme.

Jak říkám, nejsem autoritativní, nemám dopředu připravený jedno řešení, které chci slyšet; takže pokud je kandidát schopen své řešení obhájit, je to skvělé. V pořádku je, i pokud přizná chybu, že něco není úplně OK, dneska by to udělal jinak apod. Špatným znamením je, pokud k tomu kandidát nemá co říct.

Je to podobný, jako bychom  byli spolu na projektu a diskutovali refactoring nějakého staršího kódu. Nebo dělali code review. Takže věc, kterou - pokud se staneme kolegy - budeme v budoucnu běžně dělat.

Dobré je, že nediskutujem nějaké moje řešení. Je to kandidátův přínos k diskuzi - on zná kontext kódu, on může poukázat na pěkný design, zajímavou implementaci, efektivní algoritmus. A nebo aspoň dobře odvedenou práci. Pamatujete? Je to kód dle vlastního výběru. Čili kandidát volí prostor k diskuzi. Protože nejde jen o tu diskuzi - také se ptám: Proč jste se rozhodl mi ukázat právě tento kód?

Ta otázka je důležitá. Občas lze narazit na kandidáty, kteří prostě "obcházejí pohovory". A stejně tak, jako nevěnují pozornost dané firmě (prostě jen hledají jakoukoliv práci), nevěnují pozornost ani kódu, kterým se prezentují. Přitom je to úžasná možnost představit se v dobrém/nejlepším světle a vystoupit z řady (jiných kandidátů).

Kde vzít kód?

Někdy se setkám s tím, že daný vývojář řekne něco ve smyslu: "Ale já žádný kód na ukázku nemám. A to co momentálně píšu na projektu, nemůžu/nesmím dát k dispozici třetí straně." To zdánlivě vypadá jako show-stopper. Ale není.

Já samozřejmě nechci, aby někdo porušoval NDA. To je neetické. Ale i v takové situaci se dají věci řešit. Když se chce. V první řadě, je dobré si zjistit, co je předmětem NDA. Moje osobní zkušenost je, že to vývojáři většinou nevědí. Zkrátka "něco" podepsali. V takovém případě je dobré se zeptat někoho, kdo to ví.


Já když jsem chtěl ve své diplomové práci použít část práce, kterou jsem dělal pro tehdejšího zákazníka, tak jsem se jednoduše zeptal firemního právníka. Ten se podíval do příslušné smlouvy a řekl: "jo, můžeš to použít, akorát uveď zdroj. A pro jistotu, udělej tyhle anonymizační kroky: ..."

Čímž je řečena jedna možnost, jak to řešit. Ať už jste podepsali cokoliv, nikdo vás nemůže zbavit autorství vašeho kódu. A pokud kód "dostatečně" zanonymizujete, neměl by nikdo nic namítat. Otázkou je, jak určit, kolik to je "dostatečně". Nevíte-li, máte "tvrdé" smlouvy, máte pochybnosti - konzultujte.

Další možností je napsat nový kód. Cože?! Mám napsat nový kód? Práce navíc?! Jo, přesně tak. Chcete tu práci. Nebo ne? Já prostě chci vidět na pohovoru váš kód. Pokud nemůžete využít předešlou, nebo následující možnost, je to také jedna z cest. Já vám umožňuji prezentovat kód dle vašeho výběru. Tak napiště něco, co vás baví. A nemusí toho být moc. Nějaký návrhový vzor, vychytaný algoritmus, vyřešený problém, co vás před časem zaujal? To je ono! Myslím, že byste si to mohli užít. Pokud ne, asi jste se minuli povoláním. V tom případě... nemám zájem.

Nejjednodušší samozřejmě je, pokud nějaký kód, který můžete ukázat, máte k dispozici. Možná ho máte na GitHubu, Bitbucketu, nebo doma v kredenci. Třeba máte archiv minulých projektů, nebo schované nějaké prototypy. Každopádně máte něco, co se dá rovnou vzít a ukázat. Za takový kód se asi nebude stydět - nechali jste si ho přece z nějakého důvodu, ne? A tím se dostáváme k jádru tohoto článku.

Měl by mít vývojář portfolio?

Pokud přijdete (jako vývojář) někam na pohovor a přinesete s sebou ukázku své práce, buďte si jistí, že jste minimálně vystoupili z řady ostatních uchazečů. Téměř nikdo to totiž nedělá. A pokud vaše úkázky za něco stojí (nebo jsou dokonce excelentní ;-)  je dost pravděpodobné, že jste ostatní kandidáty zastínili. To ještě neznamená, že to máte v kapse. Ale výrazně jste zvýšili svoji šanci na úspěch.

Řeknu vám svůj příběh. Když jsem se ucházel o práci  (java vývojáře) u svého minulého zaměstnavatele, byla to jediná firma, kterou jsem oslovil - líbila se mi a vybral jsem si ji jako místo, kde bych chtěl pracovat. Na pohovor jsem si (sám od sebe) přinesl ukázky svého kódu, screenshoty aplikací (tehdy jsem dělal hodně frontendů) a taky generovanou dokumentaci ke svým aplikacím. A krátce jsem svou práci u pohovoru představil. Nevím, jaký to mělo vliv na mé přijetí. Faktem je, že jsem dostal vyšší nástupní plat, než jsem si sám řekl.

Když jsem se ucházel o svou současnou práci, nepřinesl jsem si na pohor nic. (Ha!) Důvodem je, že jsem nehledal práci vývojáře. Resp. rád bych si trochu zakódoval (tak z 1/3), ale hlavně mě zajímala práce team leadera (vývojářů). A taky architekta. Takže místo ukázky kódu jsem dal na vrchol svého CV odkaz na svůj blog (kde o těchto věcech píšu) a u pohovoru jsem se snažil tyto témata prezentovat a čerpat z nich. Myslím, že to fungovalo :-)

Takže jaká je odpověď na titulní otázku? Je subjektivní a není jednoznačná. Ale já se kloním k názoru, že vývojář by portfolio mít měl. Za každého hovoří jeho práce. A ta není někde v CV nebo mezi slovy na pohovoru. Je v textovém souboru někde na disku. Je tam, nebo ne? ;-)

Související články


Související externí články