Nemám ambice a hlavně ani potřebnou autoritu na to razit Joel Test 2.0, využívám jeho jména při svém zamyšlení, co je pro mě důležité, čemu bych věnoval v softwa­rové firmě pozor­nost a čeho bych chtěl na svých projek­tech dosáh­nout. Když na blogu Aspec­tworks publi­ko­vali svůj výsledek Joel Testu a když SoftWare Samuraj zpochybňoval aktuál­nost Joel testu, čekal jsem, že téma bude v komunitě rezonovat víc. Po nějaké době se k tomu proto vracím.

Joel Test 1.0

Není obtížné v Joel testu získat skóre 10 bodů z 12. Jenže firmy s 10 a více body dosta­tečně neroz­lišíte a ani nedosta­nete vodítko co zlepšit. Mimocho­dem, ve firmě, která získá 8 a méně, byste pracovat nejspíš vůbec nechtěli. Tedy pokud by vaším úkolem zrovna nebylo dát věci do pořádku.

  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?</li></ol>

Můj pohled

Kdysi jsem si pozna­menal otázky, které kladu u pohovoru, ale doposud jsem to nefor­ma­li­zoval jako test. Násle­duje výčet bodů a pod nimi pak podrob­nější vysvětlení.

  1. Zvládne nově příchozí programátor udělat něco už první den?
  2. Píšete unit testy?
  3. Děláte code review?
  4. Dokážete nasadit jedním kliknutím?
  5. Modelujete?
  6. Měříte a vizualizujete?
  7. Necháte kandidáty na pohovoru programovat?
  8. Děláte usability testy?
  9. Scházíte se denně na stand-up?
  10. Pořádáte pravidelně retrospektivu?
  11. Máte 1:1?
  12. Dodržujete listinu základních programátorských práv?

První den v práci

První dojem je velmi důležitý. To platí i první den v práci. Dojem nedělá jen zaměst­nanec ale i firma na něj. Zvládne za jeden den nainsta­lovat vše potřebné na čistý počítač, rozjet works­pace, deployovat na localhost a ten samý den fixnout byť i drobný bug?

Unit testy

Obecně se ví, že by se měly psát testy, ovšem bohužel i dnes to mnohdy pokulhává. Za pokrytí 20 % u mě máte půl bodu, za 40 % bod.

Code review

Code review pomáhá. Pomáhá vychovat nováčky, udržet pořádek nebo zlepšit povědomí i o kompo­nen­tách, které jsem nepsal. Děláte formální code review a děláte ho ještě před mergem do hlavní větve?

Nasazení na jedno kliknutí

Přijde mi, že build servery (jako například Jenkins) jsou velmi rozšířené, ale jak daleko je dotažené CI (Conti­nuos Integ­ra­tion)? Je potřeba ještě mnoho manuál­ních kroků, než se build dostane na produkci. Nejen že to není úplně zopako­va­telný proces, ale je silně náchylný na chybu. Ano, mluvím o nástrojích jako například Chef nebo Puppet.

Modelování

Předpok­ládám, že píšete dokumen­taci, ale obsahuje i obrázky (jak známo kus za tisíc slov)? Bude se lišit případ od případu, není potřeba kreslit celou sadu UML a ani na všechno, ale na klíčové části určitě napasu­jete nějaký kompo­nen­tový, sekvenční či stavový diagram, případně diagram tříd nebo BPMN. Nesmíme zapome­nout na databázový model a wireframy na UI. Celý bod si zasloužíte v případě, že model rovněž verzujete.

Měření

Měříte? Pokrytí testy, dupli­citu kódu, cyklo­ma­tickou složi­tost, lead time, WIP (work in progress) limit… Vyhod­no­cu­jete, jak se mění v čase? Měření je za půl bodu. Celý bod, když ze samot­ného měření vyvozu­jete příslušné akce.

Necháte kandidáty na pohovoru programovat?


zdrojak.cz

Tohle je možná jeden z nejkon­t­ro­verz­nějších bodů. Sám se vztekám, když na pohovoru zkouší z QuickSortu. Uznávám, že pointe­rová aritme­tika je latinou softwa­rového inženýr­ství a může oddělit zrno od plev, viz Nebez­pečí Java škol, ale pro mnoho programátorů nejsou pointery denním chlebem. Jeff Atwood (Joelův parťák ze Stacko­verf­low) razí jedno­duchý Fizz Buzz test.

Líbila se mi progra­mo­vací session u SoftWare Samuraje, kterou jsem mohl vidět jako kandidát i jako pozoro­va­tel. Úkolem je naimple­men­tovat určitý návrhový vzor (nebo alespoň část, nemusí ho stihnout celý) včetně unit testů. Kandidát dostane UML diagram a vzor je mu vysvětlen (pokud ho nezná). Tímto jedno­duchým cvičením zjistíte hrozně moc. Jak analy­zuje zadání, umí psát testy, jak se orien­tuje v IDE, jak reaguje na připomínky, jaký tvoří design, jak dokáže vysvětlovat…

Usability testy

Jistě jste si jako uživa­telé nejednou zanadávali na ergonomii nějakého software nebo webové stránky. Co ale děláte proto, abyste neházeli lidem klacky pod nohy? Děláte usabi­lity testy?

Stand-up

Velmi se mi osvědčily denní schůzky na stojáka. Setkávám se se dvěma extrémy, buď se takové mítinky vůbec nekonají a členové týmu tak navzájem nedosta­tečně infor­mují, nebo se to celé zvrhlo v hodinové vykecávání, kde nikdo nechce být. Bod si tedy zasloužíte, když stand-up trvá méně jak 15 minut a začíná včas!

Retrospektiva

Je mnoho věcí, kterými se můžeme inspi­rovat u armády, v případě debrie­fingu i u hasičů. Máte pravi­delné mítinky, kde sbíráte zpětnou vazbu a něco s tím děláte?

1:1

Máte pravi­delné schůzky 1:1 (jeden na jednoho) se svým nadřízeným? Dostává se vám každý týden třicet minut času jen pro vás? Pro inspi­raci doporučuji článek, jak Rands dělá 1:1.

Listina základních programátorských práv

O listině základ­ních programátor­ských práv už jsem dříve psal. Jde o násle­dující výčet, na co má každý programátor v práci právo.

  • dva monitory
  • rychlý počítač
  • klávesnici a myš dle svého výběru
  • pohodlnou židli
  • rychlé internetové připojení
  • tiché pracovní podmínky

Anketa