Společné vlastnictví kódu

... nejvyšší forma týmové spolupráce

Franta je na dovolené, proto si musí zákazník počkat tři týdny na opravu komponenty.
Vím, že je kód této třídy ve špatné kvalitě, ale není to můj problém. Obrať se na autora!
Už teď se mi při pomyšlení na refaktoring Robertova kódu dělá špatně! Tohle po mně vážně nechtěj!
Jsem specialista na UI a nebudu zasahovat Martinovi do kódování middleware.
Ludva se otrávil methylalkoholem a oslepl. Bude trvat týdny, než to někdo převezme.

Pokud se váš vývojový tým dostává do podobných situací, zřejmě by vám pomohlo praktikování společného vlastnictví kódu (Collective Code Ownership). Jedná se o jednu z technik metodiky extrémního programování (XP). Jednoduše by se dalo CCO definovat takto:

"Všichni sdílí zodpovědnost za kvalitu kódu. Každý může udělat změnu v jakékoli části kódu. Od všech se očekává, že odstraní problémy, na které v kódu narazí."

Pojďme se podívat, jakou přidanou hodnotu nám společné vlastnictví přináší.

Vyšší kvalita kódu

V socialismu se kolektivní vlastnictví příliš neosvědčilo. Ve výsledku všechno patřilo všem a nikomu a stav věcí podle toho vypadal. Vývojový tým je však specifická struktura, která při správném vedení a správných charakterových vlastnostech jejich členů, dosahuje spoluprácí vyšší výkonnosti. Skupinová zodpovědnost vede k tomu, že vývojáři usilují společně o vysokou kvalitu kódu. Špatný kód napsaný kolegou je i můj špatný kód. Kolega by měl pod závazkem společného kódu cítit větší zodpovědnost a snažit se o potřebnou kvalitu. Já bych naopak měl na nekvalitní kód upozornit a nebo jej přímo zlepšit. Třeba refaktoringem nebo vylepšením návrhu.

Pokud je váš kód zveřejňován a běžně posuzován jinými lidmi, zvyšuje se vaše motivace ke kvalitnější práci. Profesionální vývoj software je o osvojení správných návyků. Nad návyky nepřemýšlíte, děláte je automaticky. Pokud jste junior vývojář, bude pro vás práce v týmu s CCO obrovskou školou. Na druhou stranu někteří senior vývojáři mohou mít problém s tím, že někdo jiný jim vidí do kódu a navíc si ho dovoluje měnit! Považují svůj kód za natolik intimní záležitost, že si ji brání jako poklad. Někdy je to také z důvodu, že jejich kód je nečitelný, tedy špatný a sami to vědí.

Poznámka: Mezi atributy externí kvality kódu patří bezchybnost, použitelnost, efektivita, spolehlivost, integrita, přizpůsobivost, přesnost a robustnost. Mezi atributy interní kvality kódu patří udržovatelnost, flexibilita, přenositelnost, znovupoužitelnost, čitelnost, testovatelnost, srozumitelnost.

Vzájemná zastupitelnost

Tradičním problémem vývojových týmů je koncentrace znalostí pouze u konkrétních lidí. Autor komponenty je jediný, kdo zná její kód a pro ostatní se jedná o černou skříňku. Někomu pocit nepostradatelnosti může dělat dobře, ale pro flexibilitu vývoje je to špatně. Dovolená, nemoc nebo jiná absence zablokuje práce na komponentě na dlouhou dobu. Úplná ztráta člena týmu pak může způsobit katastrofu.

Společné vlastnictví kódu tyto problémy řeší poměrně efektivně. Dobrá znalost codebase je dovedností každého člena týmu. Oprava chyby, doplnění funkcionality nebo jiný zásah do kódu někým jiným než autorem? Není problém. Ty máš čas, tak to prosím udělej.

Co vlastně potřebujeme?

Společné vlastnictví kódu nelze efektivně aplikovat bez dalších podpůrných technik XP. Jinak se výsledek může významně lišit od našeho očekávání.

Vývojáři si musejí rozumět. Jejich kód musí být vzájemně snadno pochopitelný. Je nutné zavést jednotný kódovací styl (Coding style). Měly by se ctít zásady čistého kódu (Clean Code) a jednoduchého návrhu (Simple Design). Vysoká čitelnost kódu je zásadní požadavek na práci profesionálního vývojáře. V případě CCO je jeho důležitost ještě umocněna.

Kvalita existujícího kódu je přírůstkově vylepšována postupným refaktoringem (Refactoring). Refaktoring úzce souvisí s pokrytím kódu pomocí testů. XP aplikuje metodiku testy řízeného vývoje (Test-Driven Development). Bez správného pokrytí kódu jednotkovými testy se nedá CCO použít. Vycházíme-li z definice CCO, kdy každý má právo a povinnost kód vylepšit (refaktorovat) a rozšířit, je regresní funkce jednotkových testů nenahraditelná. Pokud by testy nad kódem nebyly, každý by se bál do stávajícího kódu zasáhnout.

Další úrovní zajištění je technika postupné integrace (Continuous Integration). Po každém promítnutí změny v kódu do společného prostoru je proveden kontrolní serverový integritní build, jehož součástí by mělo být i spuštění jednotkových testů. V případě zanesení problémů je autor změny ihned vyzván k opravě. Touto technikou je zajištěna integrační validita kódu na týmovém serveru.

Tým by měl používat verzovací systém (Version Control) pro správu zdrojového kódu s podporou vícenásobného checkoutu. Při CCO dochází častěji k situaci, kdy více uživatelů v jednom období edituje lokálně stejný objekt. Systém by měl mít kvalitní nástroj pro následné slučování změn. Doporučuje se u existujícího kódu dělat úpravy menšího rozsahu a tím pádem častěji vracet změny na server.

Efektivní podpůrnou technikou je párové programování (Pair Programming). Programování ve dvojicích zlepšuje komunikaci, urychluje šíření znalostí v týmu, díky online revizím návrhu a kódu zvyšuje výslednou kvalitu. Většina kombinací [nováček|pokročilý|expert]{2} je ve výsledku efektivní, kromě nováček + nováček - mentor. Páry by se měly měnit a je nutné vytvořit unifikované programové prostředí u všech párovačů. Není nutno párovat po celou dobu práce.

Rizika

Nedostatečná znalost problematiky jednoho z členů týmu může způsobit problematický zásah do existujícího kódu. Jako pojistky máme jednotkové testy, které by zároveň měly dokumentovat návrh příslušné části systému. V případě, že znalosti člena týmu jsou špatné, mohlo by zabrat nasazení párového programování.

Nikdo se nehlásí k zodpovědnosti za daný kód (No Code Ownership). Takového rizika se mohou obávat především projektoví manažeři. Všem zúčastněným musí být zřejmé, že zodpovědnost za každou část leží na celém týmu. Postoje typu "Já mám svůj kód v pořádku a tento mě nezajímá" je potřeba eliminovat.

Nedodržení souvisejících agilních technik oslabí výhody CCO a možná jej úplně zabije. Je na zodpovědnosti vedoucího týmu, aby zajistil vytvoření a provoz správně nastaveného agilního prostředí.

Alternativy

Pokud se codebase striktně rozdělí podle členů týmu a vzájemně si do kódu nezasahují, mluvíme o silném vlastnictví (Strong Code Ownership). Méně striktní je slabé vlastnictví (Weak Code Ownership). Kód je stále rozdělen podle správců jednotlivých komponent, ale jiný člen týmu může po svolení od správce kód změnit.

Závěrem

Pro malé a agilně řízené týmy se jeví CCO jako přirozené řešení požadavků na kvalitu a zastupitelnost. U korporátních neagilně řízených týmů by se na propagátora CCO mohli dívat jako na Marťana, můžete to zkusit. :) Pokud pro vás není agilita sprosté slovo, určitě stojí za to se nad dopady CCO zamyslet.

Rád bych článek doplnil o nějaké praktické postřehy, ale ve firmě se nám zatím nepodařilo vytvořit dostatečné prostředí pro provozování společného vlastnictví kódu. Výhody jsou zřejmé a rádi bychom stávající slabé vlastnictví přetransformovali na společné. Pokud máte vlastní zkušenost, prosím o připojení komentáře. Děkuji.

Zdroje

The Art of Agile Development: Collective Code Ownership - můžete si přečíst odpovědi na otázky, které zřejmě vznese každý, kdo o přechodu na CCO uvažuje.

Jednoho produktivního vývojáře prosím!

Jak velký je rozdíl mezi slabým, průměrným a vynikajícím vývojářem? Kolik průměrných vývojářů zastoupí jednoho excelentního? O kolik člověkodnů dokončíme projekt rychleji přidáním dalšího vývojáře?

Odpovědi na tyto otázky samozřejmě nelze exaktně vyčíslit. Někdo by dokonce mohl říci, že v IT se nedá nic pořádně odhadovat a tak se o to ani nebude pokoušet. Můžeme se ale na problém výkonnosti vývojářů podívat přes jejich produktivitu a posoudit efekt jednotlivých manažerských zásahů na rychlost práce vývojového týmu.

Produktivita vývojáře

Strohá definice říká, že produktivita vývojáře je (ekonomický) ukazatel mezi výsledkem (softwarový produkt) a časem potřebným k jeho dosažení. Podle této definice bychom se měli snažit produkovat software za co nejkratší dobu. Samozřejmě s dodržením akceptačních kritérií na funkční a nefunkční požadavky. Měli bychom také zajistit dostatečnou vniřní kvalitu systému, která nám u dlouhodobých projektů zjednoduší jejich údržbu a následný rozvoj.

Výslednou produktivitu vývojáře ovlivňuje velké množství faktorů. Patří mezi ně odborné znalosti, zkušenosti z jiných projektů, dovednosti v používání nástrojů, intuice v rozhodování, schopnost správného výběru z mnoha alternativ, soft skills, pracovní prostředí, vhodné nástroje a mnoho dalších.

Opravdu kvalitní vývojáři jsou mnohem produktivnější než ti průměrní

Někteří zkušení projektoví manažeři tvrdí, že vynikající vývojář je až o řády produktivnější než průměrný vývojář. Vzhledem k tomu, že vývoj software je vysoce komplexní záležitost, dá se tomuto tvrzení věřit. Co se naprogramuje dnes, stane se základem pro zítra. Pokud tedy pokládá základy určité části systému méně disponovaný vývojář, může být jeho práce nedostatečně kvalitní a ve výsledku neproduktivní. Stavět na takto chatrných základech je pak pro ostatní velice neefektivní. Situace si někdy vynutí velký zásah nebo dokonce kompletní předělání, samozřejmě s výrazným navýšením pracnosti.

Vývoj software prochází několika fázemi (specifikace požadavků, analýza, návrh, implementace, testování, nasazení do provozu, údržba). Chyby a nerespektování požadavků v jednotlivých fázích mohou mít velké časové a ekonomické dopady. Výborný vývojář používá efektivně postupy a nástroje, které chyby eliminují. Tím tráví méně času řešením následných defektů zanesených do systému v předchozích fázích.

Přidám lidi, zrychlím projekt

Tento mýtus IT managmentu je dost rozšířený. Pokud zapojíte další skladníky do nakládky kamionu, jistě se celá akce urychlí (pokud se nepoperou o ještěrku :)). Ale vývoj software není pásová výroba. Tam takové pravidlo neplatí.

Přidáním vývojáře dojde z krátkodobého hlediska spíše ke zpomalení týmu. Stávající členové totiž musí věnovat určitý čas na zaškolení nováčků a jejich uvedení do problematiky. Pokud navíc přidáte slabého vývojáře, jeho nekvalitní a pomalá práce může snížit efektivitu ostatních. S navýšením počtu členů týmu také roste zátěž manažera v koordinací lidí. Množství komunikačních kanálů roste exponenciálně podle počtu lidí. Podle vzorce n(n-1)/2 určíme, že např. pro tým 12 lidí, bude muset manažer udržovat 66 komunikačních vztahů.

Někdy je vhodnější slabého člena z týmu odebrat než se snažit přidat dalšího průměrného vývojáře. Výborným vývojářům se uvolní ruce od zátěže s neproduktivním vývojářem a sami pak odvádějí lepší práci. V tomto případě tedy platí, že méně je více.

Jak tedy urychlit vývoj?

• Určitě se soustřeďte na personální kvalitu Vašeho týmu. Věnujte více peněz na výběr excelentních členů.
• Investujte do školení a dalších forem zvyšování produktivity.
• Nespoléhejte jenom na průměrné vývojáře. Nemůžete na nich stavět projekt, který má být úspěšný. V IT neplatí, že průměrný tým odvede ve výsledku průměrnou práci. Výsledek může být mnohem problémovější.
• Poskytněte vývojářům kvalitní nástroje, které zefektivní jejich práci.
• Nezmatkujte a neurychlujte krátkodobě vývoj přidáváním dalších vývojářů. Hledejte důvody, proč je projekt v prodlení a odstraňujte překážky.
• Zbavte se slabých vývojářů a nebudete je muset hlídat.

Zdroje

K napsání příspěvku mě inspirovala úvaha Neala Forda Developer Productivity Mean vs. Median.

Tell, Don't Ask

... aneb snižujte závislosti mezi třídami

Jedna z možných definic návrhového principu Tell, Don't Ask (TDA) zní takto:

"Každé rozhodování zcela závislé na vnitřním stavu objektu by mělo být prováděno uvnitř tohoto objektu."

Princip hovoří o tom, že bychom měli navrhovat třídy tak, aby se volající strana nemusela dotazovat na záležitosti týkající se vnitřního stavu volané třídy.

Ukázka porušení TDA

Mějme zjednodušený autobusový rezervační systém:

class Bus
{
    private int numberOfSeats;
    private IList<Passenger> passengers = new List<Passenger>();
 
    public Bus(int numberOfSeats)
    {
        this.numberOfSeats = numberOfSeats;
    }
 
    public bool HasFreeSeat
    {
        get
        {
            return numberOfSeats > passengers.Count;
        }
    }
 
    public void AddPassenger(Passenger passenger)
    {
        passengers.Add(passenger);
    }
}
 
class BusReservation
{
    public void AddPassengerToBus(Bus bus, Passenger passenger)
    {
        if (bus.HasFreeSeat)
        {
            bus.AddPassenger(passenger);
        }
    }
}

Proč je uvedené řešení problematické:

• Základním principem OOP je zapouzdřenost interních dat objektu a jeho chování. Třída Bus však zbytečně zveřejňuje informaci o volných sedadlech a nutí volající stranu, aby s touto informací pracovala a zohledňovala ji před voláním metody AddPassenger.
• Třída BusReservation je závislá na třídě Bus na dvou místech. Dotazováním na vlastnost HasFreeSeat a voláním metody AddPassenger. Každá nadbytečná závislost mezi třídami zvyšuje komplexitu návrhu a zhoršuje vlastnosti systému.
• Třída Bus nutí volající stranu, aby měla znalost o tom, že před zavoláním AddPassenger si musí nejprve sama ověřit splnění kontraktů přidání cestujícího. S tím souvisí i závislost na správném pořadí volání. Samostatné volání HasFreeSeat nedává smysl.
• Co když se v budoucnu změní podmínky, za kterých je možné přidat cestujícího? Nyní je přidání závislé pouze na volném sedadle, ale nově může přibýt podmínka typu "je autobus pojízdný". Pak bude nutné doplnit test na vlastnost IsMobile na všechna místa volání AddPassenger.
• Každá nadbytečná závislost zvyšuje komplexitu jednotkových testů. Pokud chceme testovat třídu BusReservation v izolaci, musíme mockovat třídu Bus (nebo lépe rozhraní). V našem problematickém případě musíte přidat chování mocku pro vlastnost HasFreeSeats a metodu AddPassenger.

Vhodnější řešení

Odstraníme závislost volající třídy na dotazování se na volné sedadlo. Veškeré testy na proveditelnost akce přidání cestujícího jsou zapouzdřeny uvnitř metody AddPassenger. Pokud některá z podmínek není splněna, je vrácena výjimka, kterou zpracuje volající strana. Volající straně se situace zjednoduší.

class Bus
{
    private int numberOfSeats;
    private IList<Passenger> passengers = new List<Passenger>();
 
    public Bus(int numberOfSeats)
    {
        this.numberOfSeats = numberOfSeats;
    }
 
    private bool HasFreeSeat
    {
        get
        {
            return numberOfSeats > passengers.Count;
        }
    }
 
    public void AddPassenger(Passenger passenger)
    {
        bool isFull = !HasFreeSeat;
 
        if (isFull)
        {
            throw new Exception("Bus is full.");
        }
 
        passengers.Add(passenger);
    }
}
 
class BusReservation
{
    public void AddPassengerToBus(Bus bus, Passenger passenger)
    {
        bus.AddPassenger(passenger);
    }
}

Vezměte si na pomoc Adapter

Pokud využíváte rozhraní, které nemůžete měnit (komponenta třetí strany) a které porušuje TDA, můžete si pomoci návrhovým vzorem Adapter (Wrapper). Např. v jazyce C# je za příkazem foreach schován adaptér, který zjednodušuje práci se vším, co zveřejňuje metodu IEnumerator GetEnumerator(). Z IEnumerator pak postupně volá metodu bool MoveNext() a dotazuje se na vlastnost object Current { get; }. Více na stackoverflow.com.

Závěrem

Tak jako většina principů a doporučení objektového návrhu, tak i TDA není možné bez rozmyslu aplikovat dogmaticky ve všech situacích. Záleží na zodpovědnosti navrhované třídy, zda-li poskytuje příkazy (commands) k vykonání nějaké akce nebo dotazy (queries) vracející vnitřní stavy objektu. V případě příkazů byste však měli o dodržování principu TDA usilovat.

Peníze až na čtvrtém místě

Richard Florida ve své knize The Rise of the Creative Class zveřejnil zajímavé výsledky výzkumu o motivování lidí. Více jak 20 000 pracovníků z IT mělo z celkem 38 různých faktorů vybrat ty, které je nejvíce ovlivňují a motivují v jejich práci. Top 10 vypadá takto:

1. Náročnost úkolů a zodpovědnost
2. Flexibilita
3. Stabilní pracovní prostředí
4. Peníze
5. Profesní rozvoj
6. Uznání kolegů
7. Motivující spolupracovníci a nadřízení
8. Vzušující náplň práce
9. Firemní kultura
10. Umístění a komunita

Pokud na výsledky pohlížíte z perspektivy zaměstnance, snáze pochopíte, v jakém prostředí může vyniknout Váš kreativní potenciál. Máte-li na výběr, hledejte firmu, která nabízí zajištění co nejvíce motivátorů ze seznamu. Pokud ve Vaší stávající firmě není splněna většina věcí ze začátku seznamu, měli byste se vážně zamyslet, zda-li v takové firmě chcete nadále ztrácet svůj čas.

Průzkum by měl být přínosný také pro zaměstnavatele a vedoucí týmů. Pokud chtějí z lidí dostat maximum a zajistit jejich spokojený pracovní život, měli by realizovat opatření, která napomáhají motivovat. Nerespektování těchto faktů obvykle zabíjí inovaci, zvyšuje fluktaci lidí a v konečném důsledku snižuje úspěšnost firmy.

Florida nám předkládá potvrzení faktu, že peníze nejsou dostatečným dlouhodobým motivátorem u kreativních lidí. V určité fázi pracovního vývoje totiž můžete zjistit, že přestože vyděláváte slušný balík, nejste spokojeni. Dostali jste se zřejmě na úroveň, kdy základní potřeby včetně finančních jsou uspokojeny, ale potřebujete navíc uspokojit Vaše seberealizační potřeby nejvyšší úrovně (viz. 4. a 5. patro Maslowovy pyramidy potřeb).

Pokud Vás zajímá problematika podpory kreativity v současné éře inovativní ekonomiky, můžete si přečíst knížku Nepostradatelní od Jan Melvil publishing. Seth Godin na mně působil zpočátku trochu jako otravný provokatér, ale s postupem času jsem na jeho hru přistoupil a začalo se mi to líbit. Doporučuji.

Produktivní rychlokodér

... aneb ovládněte základy Vašeho řemesla

Je součástí Vaší profese vytváření programového kódu? Píšete kód produktivním způsobem? Znáte a používáte nástroje, které Vám pomáhají produktivitu zvyšovat? Saháte často při psaní kódu na myš?

Stává se téměř denně, že objevím nějakou novou fintu, kterou se snažím využít pro zlepšení své produktivity. Může se jednat o novou klávesovou zkratku, nový nástroj, novou techniku, zrychlení často se opakujícího postupu, apod. Pokud chceme svoji práci dělat co nejlépe, je potřeba systematicky pracovat na zvyšování naší kodérské produktivity.

Tento příspěvek se týká aspektů rychlosti vytváření programového kódu. Rád bych shrnul elementární dovednosti, které jsou nutným základem pro práci kodéra. Příklady v textu se týkají platformy Visual Studia, kterou používám. Předpokládám však, že pro jiná IDE existují ekvivalentní nástroje.

Hbité kodérovy prsty

Kolika prsty píšete a jak rychle? Díváte se při psaní na klávesnici? Děláte často chyby a musíte se při psaní vracet o odmazávat?

Někdo nepovažuje rychlost psaní u kodéra za příliš důležitou. Sami však tušíte, že je rozdíl mezi datlováním dvěma prsty a symfonií všech deseti. Rychlost se uvádí v úhozech (keystrokes) za minutu nebo v počtu napsaných slov za minutu (WPM). Změřte si svou rychlost např. na http://10fastfingers.com. Průměr je mezi 50 a 70 wpm. Pokud se dostanete nad 100 wpm, patříte mezi 20% nejrychlejších psavců. Raději nebudu uvádět kolik jsem naměřil sobě. :)

A jak tuto dovednost zlepšovat? Zkuste se naučit hmatovou metodu, která využívá všech deseti prstů. Pořiďte si ergonomickou klávesnici, která Vám bude vyhovovat.

Můžete si také přečíst, co si o dovednostech pro psaní textu myslí respektovaný Jeff Atwood v příspěvku We Are Typists First, Programmers Second.

Učte se klávesové zkratky a nesahejte na myš

Důležitost konkrétní klávesové zkratky pochopíte v momentě, kdy se ji naučíte. Od tohoto okamžiku se bez ní neobejdete. Zkratka většinou supluje akci, kterou můžete udělat myší nebo posloupností více klávesových akcí. Obě metody jsou obvykle pomalejší než zkratka (od toho je to zkratka :). Základní sadu klávesových zkratek má vaše IDE, další dodají dodatečná rozšíření. Pro Visual Studio platí, že základ je sice ok, ale teprve s rozšířením typu CodeRush nebo ReSharper povýšíte z akumulační vrtačky na pořádnou příklepovku! Investice do kvalitních rozšíření se určitě vyplatí.

Doporučuji vytisknout cheat sheety s přehledem klávesových zkratek Vašeho IDE a rozšíření. Zdroje pro Visual Studio (Microsoft, DoFactory), CodeRush a ReSharper. Postup učení pak může být takový, že si nejprve přečtete referenční přehled zkratek, abyste dostali do podvědomí, co všechno se dá "zkracovat". Pak se snažíte před každou požadovanou akcí vzpomenout si na příslušnou zkratku. Několikrát požádáte papír o nápovědu a podle konkurenceschopnosti vaší střednědobé paměti si zkratku zapamatujete. Zkratek bývá velké množství a jsou strukturovány do menších oblastí. Zřejmě i zde platí Paretovo pravidlo, že 20% zkratek budete využívat v 80% případů. Naučte se tedy alespoň těch 20%.

Automatické doplňování a kontextový našeptávač

Ve VS je k dispozici nástroj IntelliSense. Podle aktuálního kontextu, části zadaného jména a s využitím reflexe, Vám například nabídne rychlé vložení příslušného jména identifikátoru. Předpokládám, že není nikdo, kdo by nabízenou pomoc od IntelliSense odmítal. Ne každý však umí IntelliSense vyvolat explicitně (Ctrl + J), zobrazit si informace o metodě a jejích parametrech (Ctrl + Shift + Spacebar), apod.

Vkládání bloků kódu

Psaní kódu není psaní beletrie, ale má charakter kompozice jednoduchých opakujících se bloků kódu do složitějších celků. Nabízí se tedy s těmito bloky pracovat efektivněji. Ve většině IDE je k dispozici podpora code snippetů. Jedná se o předpřipravené kusy kódu s možností definice parametrických částí. Vložení těchto kusů kódu provedete zadáním zkratky snippetu a odesláním řídícího znaku (ve VS tabulátoru). Napište např. foreach a stiskněte tabulátor. Editor v IDE Vám doplní celý blok příkazu foreach s možností změnit názvy parametrizovatelných částí.

V základu vašeho IDE je k dispozici množina předdefinovaných snippetů. Zajímavé jsou však i snippety, které si vytvoříte sami. Pokud používáte nějakou typickou sekvenci nebo blok kódu, určitě si pro něj vytvořte snippet. VS nemá ideální podporu pro vytváření vlastních snippetů a proto musíte vzít zavděk některými externími editory. Např. Snippy nebo Snippet Editor. Doporučuji vytvořit snippety pro Váš projekt a spravovat je centrálně v repository. Budou je mít k dispozici všichni členové týmu.

Rozšíření CodeRush nabízí aparát šablon. V daném kontextu je k dispozici zkratka, která odpovídá klíčovému slovu, názvu datového typu nebo nějaké složitější sekvenci. Stačí pak zadat např. t a po stisku mezerníku bude doplněno true. Šablony jsou inteligentní a jajich použití je variabilní a uživatelsky rozšiřitelné.

Dogenerování chybějícího kódu

Poměrně často používám klávesovou zkratku Ctrl + ., která podle aktuálního kontextu doplňuje chybějící kód. Umí doplnit using pro relativně odkazovanou třídu, vygenerovat pole nebo vlastnost třídy, vytvořit kostru neexistující metody (při použití metody shora-dolů), provést implementaci rozhraní, apod. Bez této funkce (klávesové zkratky) bych se už neobešel.

Vylepšování kódu pomocí refaktorizace

Znalost refaktorizačních technik by měla být v repertoáru každého kodéra. Mezi základní techniky patří přejmenování, vyčlenění kódu do samostatné metody, práce s argumenty metody, apod. Další typy refaktorizací mohou přidat rozšíření. Refaktorizaci použijete v situaci, kdy chcete stávající kód vylepšit (zlepšit čitelnost a udržovatelnost). Pěkné příklady jsou například na sourcemaking.com.

Generování kódu

Ke generování větších a složitějších bloků kódu můžete využít podporu T4 šablony. Generovat se dá z logických DSL modelů, z databázových dotazů a dalších kolekcí. Jedná se o efektivní a dobře použitelný nástroj. Můžete mrknout na ukázku.

Navigace v kódu

Umět se rychle dostat na určité místo kódu je neméně důležité jako umět kód vytvářet. Čím je projekt rozsáhlejší, tím jsou nároky na navigaci v kódu vyšší. Pokud však ovládáte klávesové zkratky pro přechod k deklaraci, na předchozí místo v kódu, do konkrétní třídy, apod. nebude pro Vás tato činnost problém. Některé techniky, jako například Test Driven Development, vyžadují cyklické provádění stejné posloupnosti akcí. V těchto případech mohou být rozdíly v produktivitě markantní.

Důležitá je i navigace mezi částmi IDE. Např. přechod do okna s chybami kompilace, do okna s testy, do Solution Exploreru, apod. Na většinu akcí by opět měly být k dispozici klávesové zkratky. Jen se je naučit.

Jak se dále zlepšovat?

• Vyzkoušejte párové programování a pečlivě sledujte Vašeho spolukodéra. Snažte se pochytit jeho dobré návyky.
• Sledujte blogy, které píší o používání Vašich nástrojů a zvyšování produktivity.
• Pokud máte problém, snažte se jej vyřešit automatizací i za cenu (přiměřeně) vyšších startovních nákladů na naučení.
• Účastněte se programátorských cvičení typu CodeRetreat.
• Trénujte. ;)