Jaké je to pracovat na volné noze?

Často se mě kamarádi a kolegové ptají, jaké to vlastně je být na volné noze, jaké výhody či nevýhody mi to přináší. Tímto článkem bych rád zrekapituloval moje zkušenosti, které jsem za dobu jednoho a půl roku získal.

• Vždy jsem se hodně snažil učit nové věci, četl články, zkoušel nové knihovny. Ale bylo to takové "umělé". Nyní jsem za relativně krátkou dobu získal spoustu praktických zkušeností, které bych normálně získával mnohem déle. Nemyslím teď jen technické znalosti (různé projekty, různé přístupy k řešení problémů, nové knihovny, atd.), ale zejména jsem měl možnost nahlédnout do mnoha různorodých firem, vidět různé styly komunikace a řízení, různé přístupy k vývoji, přemýšlet o tom, co kde funguje a nefunguje atd. Připadám si jak houba, která se v každé nové firmě pořádně nasákne.
  
  
• Práce na volné noze mě drží v neustálé pohotovosti. Musel jsem si zvyknout na to, že nic není jisté, a že jediný důvod, proč si mě někdo bude chtít najmout bude ten, že budu "dobrý", že budu nabízet něco více než ostatní - znalosti, zkušenosti, profesionální přístup. To mě pořád nutí přemýšlet o sobě, o mých znalostech a to mě tedy žene dopředu. Samozřejmě to je zároveň i nevýhoda, protože vždy není jednoduché se prosadit a není vždy jednoduché přijít do nové firmy a začínat od začátku.
  
  
• Vždy jsem byl placen od hodiny a je to tedy jen o vzájemné důvěře, že opravdu odpracuji uvedený počet hodin, který na konci měsíce vykážu, a který chci zaplatit. Jako zaměstnanec jsem takový tlak nikdy necítil, ale teď si prostě nemohu dovolit číst hodinu články na internetu a pak to vykázat jako nějakou práci. Samozřejmě člověk není robot a někdy se mi pracovat nechce nebo to prostě ani moc nejde - pak to ale musím zohlednit ve výkazu, bohužel.
  
  
• Jsem sám a nikam vlastně nepatřím. Musím tedy zapomenout na jakékoliv zaměstnanecké výhody - tím nemyslím jen stravenky, připojištění, služební auto, atd., ale i to, že se mě netýkají školení, výuka angličtiny, společné výjezdní zasedání apod. To cítím asi jako největší nevýhodu, někdy jsem prostě sám. Na druhou stranu jsem oproštěn od interních dohadování a problémů, což je zase mnohdy výhoda.
  
  
• Jsem sám svým pánem, ale stejně vždy šéfa mám. Spíše se tedy cítím volněji, ale i tak musím plnit termíny, pořád mi někdo zadává práci a pak ji kontroluje, takže v tomto změna není. Mohu si ale vybrat počítač, mobil, auto jaký chci aniž bych porušoval firemní předpisy a jsem větším pánem svého času. Také se dívám na věci více z nadhledu, protože vím, že nikde nebudu napořád.
  
  
• Člověk pozná spoustu nových kolegů, známých, což je určitě také příjemná výhoda.

Svého rozhodnutí přejít na volnou nohu jsem nikdy nelitoval a jsem za něj moc rád. Pokud to jen půjde, tak v nejbližších letech bych rád neměnil.

A jaké jsou vaše zkušenosti? Zkoušeli jste pracovat na volné noze? Myslíte, že pro firmy i do budoucna bude zajímavé si najímat lidi na kontrakt?

Definice rozhraní dohromady se třídami

Nedávno jsem procházel cizí kód a narazil jsem na definici rozhraní dohromady s definicí použitých tříd, viz následující příklad (příklad je uměle vytvořen):

public interface Connector {

    Status getStatus();
    
    
    /**
     * Connection status.
     */
    public static class Status {
        private int code;


        /**
         * Constructor
         * 
         * @param code Connection status code
         */
        public Status(int code) {
            this.code = code;
        }


        public int getCode() {
            return this.code;
        }
    }
}

Mě by tato konstrukce nikdy nenapadla, proto mě to hned praštilo. Čím více jsem ale o tom přemýšlel a rozebíral s autorem, tak jsem vlastně zjišťoval, že moc argumentů, proč by to tak nemělo být, vlastně nemám.

Zde jsou mé dva argumenty, proč se mi to "nezdá":

• První argument asi moc neobstojí, ale pro mě je celkem důležitý - rozhraní se definují pomocí rozhraní, třídy pomocí tříd. Proč to tedy míchat dohromady? Autor mi na to řekl, že chtěl zdůraznit spojitost mezi rozhraním a použitými třídami. Tomu moc nerozumím, protože všechny třídy použité v rozhraní jsou automaticky součástí API. Možná měl na mysli to, že kdykoliv budu pracovat se třídou Status, tak budu muset používat prefix rozhraní, tedy Connector.Status a tím tedy vždy bude zřejmá příslušnost třídy k danému rozhraní.
  
  
• Všechny mé další výtky směřují na možné úpravy, rozšíření v budoucnu - to je jeden z důležitých aspektů kvalitního API, aby bylo možné zachovat zpětnou kompatibilitu a přitom mít možnost dané API rozšiřovat. Co když budu chtít třídu Status použít v budoucnu i v jiném rozhraní? Co když budu chtít vytvořit třídu StatusExt jako rozšíření třídy Status?

Přijde mi tedy, že kvůli minimální "výhodě" mohu mít v budoucnu problémy.

Spousta lidí má představu, co to asi tak API je, ale už jen pár lidí si dokáže představit, jak je těžké vytvořit kvalitní API. Já sám se v této oblasti hodně učím a to zejména z knížky "Practical API Design" od Jaroslava Tulacha. Ale je hlavně potřeba praxe a mít vůbec možnost taková API navrhovat a rozvíjet, což se ve standardních webových aplikacích moc často neděje.

Proto by mě moc zajímal názor ostatních - máte nějaký další argument na mojí podporu? Nebo se vám zdá, že to ani nemá cenu řešit, a že je vše v pořádku?

Testování s Mockitem

Pokud to někdo myslí s testováním vážně, tak se asi bez mockování neobejde. Já jsem dříve používal jMock a musím říct, že mě to celkem na nějaký čas od mockování odradilo - samotný zápis mi přišel velice upovídaný, měl jsem problémy s refactoringem a hlavně to bylo celé hodně náročné na údržbu. Zhodnotil jsem to tehdy, že je to moc práce bez velkého přínosu. Ještě bych měl možná podotknout, že jsem psal testy vždy až po produkčním kódu.

Na nedávném setkání s vývojáři v Ostravě mi byla doporučena knihovna Mockito. Sice jsem s ní ještě nic nedělal, ale už mě chytla - kód je hezky čitelný (stylem mi to připomíná hamcrest), bezproblémový refactoring, není nutné psát metody pomocí řetězců a celé mi to prostě přijde takové intuitivní. Jinak o důvodech vzniku Mockita je možné si přečíst na stránkach autorova blogu.

Pokud se vám Mockito líbit nebude, tak zkuste něco z následujících knihoven (na které mám uloženy odkazy): jMockit, EasyMock, jMock a nebo rMock (pokud máte s těmito knihovnami nějaké zkušenosti, tak se rád přiučím).

Nakonec ještě posílám odkaz na zajímavý článek "Mocks Aren't Stubs" od Martina Fowlera.

Jaký build nástroj používáte? - výsledky

V poslední anketě mě zajímalo, jaký build nástroj se nejčastěji používá. Celkem hlasovalo 86 lidí s tímto výsledkem:

1. Maven (59%)
   
2. ANT (55%)
   
3. Něco jiného (9%)
   
4. GANT (1%)
   

Dnes bez komentáře, protože k tomu není potřeba nic dodávat :).

Programátoři vs. kodeři

Při své práci na volné noze jsem již pár firem navštívil a všude mi to přijde stejné - část vývojářů jsou programátoři a část kodeři.

Programátor

Schopnost myslet - asi to zní úsměvně, ale toto je největší schopnost (a tedy rozdíl oproti koderovi) programátora. O své práci přemýšlí, přemýšlí, zda to co dělá dává smysl, zda zadání, které dostal neobsahuje nějaké nesmysly, nesrovnalosti. Programátorovi jde také často o "dobrý pocit" z práce - nejde vždy jen o to udělat nějaký úkol co nejrychleji, něco narychlo zbastlit, ale dělat věci tak, aby s nimi byl člověk sám spokojený.
Programátor bude obecně asi také více nespokojený člověk, protože mu záleží na tom, aby dělal v "prostředí", které dává smysl, které ho někam posouvá dále.

Kodér

Kodéra ze všeho nejvíce zajímá zdrojový kód - rád kód vytváří, ale nebaví ho si vymýšlet zadání, přemýšlet nad ním, diskutovat o něm. Ideálně dostane zadání, které obsahuje úplně vše - od informace, jaké metody má udělat a kam je umístit, přes informaci, že je nutné přidat tlačítko "Odeslat" k formuláři (toto je realita, jeden kolega udělal webový formulář bez tlačítek na odeslání). Díky velké orientaci na samotný kód dokáží psát velice efektivně a kvalitně.


To, zda je vývojář programátorem nebo kodérem nesouvisí ani tak s tím, jak kdo je dobrý v Javě, jak moc zná různé knihovny, frameworky, ale asi spíše s tím, jaký má přístup k práci, co ho baví více. Někdo je od přírody přemýšlivý, zkoumavý, zodpovědný, pečlivý, ...

Z pohledu sestavení vývojového týmu je zřejmé, že každý tým potřebuje oba dva typy vývojářů - někoho, kdo bude udávat směr a přemýšlet o aplikaci a někdo, kdo bude dělat (kvalitní) kód. Jen je otázka v jakém poměru to namíchat - má zkušenost je zatím taková, že poměr programátorů vs. koderů je přibližně 1:2.