rarouš.weblog

Volně přeloženo z knihy The Clean Coder

1. Nenapíšeš řádky produkčního kódu, aniž bys měl padající test.
2. Nenapíšeš řádky testovacího kódu, pokud již nejsou aktuální řádky schopné projít (nezkompilovatelný kód také neprojde).
3. Nenapíšeš řádky produkčního kódu, které nejsou nezbytně nutné, aby prošel aktuálně padající test.

Už je tomu nějakej ten pátek, co jsem Marianovi slíbil, že napíšu článek s videama, o kterých si myslím, že jsou velmi dobrá na procvičování funkcionálního programování a abstraktního myšlení vůbec. Tak tady jsou:

MinLINQ

První z nich ukazuje implementaci LINQ operátorů pomocí funkcionální kompozice tří základních operátorů Ana, Bind a Cata:

Rx pod kapotou

Další se zabývá velice zajímavými koncepty asynchroního a konkurenčního přístupu v reaktivních extenzích:

Design programovacích jazyků

Poněkud starší video o tom, jak se vaří programovací jazyky, s lidmi, kteří je opravdu navrhují. Erik Meijer je jedním z mistrů Haskellu a mimo jiné i mozkem za LINQ a Rx ve světě dotnetu. Gilad Bracha je toho času součástí týmu tvořícího Dart. A Mads je v teamu tvořící C#. Takže samí zajímaví lidé se zajímavými pohledy na jazyky.

Fukcionální programování

Další video s Erikem „you know“ Meijerem. :) Také staršího data, ale to na kvalitě neubírá, představuje koncepty funkcionálního programování v dotnetu.

A komu to přijde málo a má chuť (a čas) se do funkcionálního programování opravdu obout, tak doporučuju celou 13 dílnou serii Erikových lekcí. Často jsou ukázky v Haskellu, ale tady jde o koncepty a nakonec není od věci podívat se i na jiný programovací jazyk, že.

Na proběhnuvším CodeRetreatu jsme se a pány Kolmanem a Augustýnem balivi o tom k čemu vlastně je TDD, jaký má přínos?

Michal argumentoval tím, že dělá testable design a testy píše potom a že je s tím cajk, že nevidí důvod, proč dělat TDD. S Danem jsme nahazovali okřídleané pravdy o výhodách TDD, které Michal zašlapal. A tak jsme nenašli správnou argumentaci. A já o tom musel přemýšlet. Přece tam musí být nějakej zásadní rozdíl!

A on je. Ta největší devíza TDD je iterativní přístup k vývoji. Pakliže se držíte nějaké agilní metodiky a jednou za iteraci máte funkční produkt, který může jít potenciálně do produkce. S TDD jste v takovém stavu takřka každou chvíli (po dokončení kolečka Red-Green-Refactor). Kdykoli za vámi někdo přijde, že chce vidět jak na tom jste, tak nemusíte říkat „těd to nejde, zrovna mám něco rozdělanýho a nefunguje to.“ S TDD vám aplikace funguje takřka pořád. Sice nemá všechny požadované vlastnosti, ale je funkční.

Již za týden se koná akce, do které jsem tak trochu namočený, Global Day of Code Retreat. My se snažíme připravit jedno místečko v Praze.

Ačkoli má akce za cíl vás vytrénovat v lepší vývojáře, je dobré abyste na něj přišli trochu připravení. :) Určitě si přečtěte pravidla problému, který se bude celý den znova a znova implementovat. Ale nezůstaňte pouze u čtení, zamyslete se nad tím, jak danou úlohu naimplementovat. Nebojte se a jděte ještě dál a vážně tu vaši ideu i zhmotněte!

Dalším krokem jak se na akci připravit, je zacvičit si nějakou tu katu v kódování. Zkuste třeba oblíbenou bowling game nebo string calculator. Procvičíte si tak TDD i nástroje, které budete používat.

V pátek jsem si utvítl, že „Psát virtuální distribuovanej file systém je challenge.“ a hned jsem dostal reakce, že jsem další v řadě a že znova vymýšlím kolo a další parafráze mých výroků.

Jak to tedy je? :)

Challenge pro vás

Ukažte mi implementaci VirtualPathProvideru, který má správně vyřešené cachování a škáluje přes více než jeden webový front-end.

Když se vám to povede, veřejně mě můžete prohlásit za hlupáka, který neumí hledat a znovu vynalézá kolo. Když se vám to nepovede, můžete se mě snažit uplatit, abych vám prozradil pikantní podrobnosti.

Poslední dobou se mi velmi často stává, že narážím na hlášky typu “od devíti refaktoruju a furt to nemá konce,” “refaktoring mi zabere asi tři dny, udělej mi na to task do backlogu” nebo „refaktoroval jsem to a nějak to přestalo fungovat.“ Tohle všechno jsou lži, ať už plynoucí z neznalosti, co to je refaktoring nebo trendy nadužívání tohoto slova v nepatřičných situacích.

Co je to refaktoring?

Refaktoring je pojem, který je definován poměrně přesně. Je to krátká atomická operace nad kódem, která nemění jeho funkci, pouze strukturu. Z definice jasně vyplývá, že věty z úvodu jsou lži.

Refaktoring patří k základní hygieně čistého kódu. Měli byste ho používat neustále. Není to věc, kterou byste měli zahrnovat do plánů jako něco extra, podobně jako testy, jsou jejich nedílnou součástí. A sluší se je zahrnout do časových odhadů jednotlivých úkolů. Ne však jako samostatné úkoly!

Říkám refaktoring, myslím redesign

Refaktoring se stal trendy pojmem. Manažeři mu nerozumí a programátoři se sním furt ohánějí. „Proč ti to trvalo tak dlouho?“ „Ještě jsem musel udělat refaktoring tohodle a tamtoho.“ Jenže jak jsme si řekli v definici, refaktoring je krátká operace! Velmi krátká, pokud máte dobré nástroje, netrvá více než pár stisků kláves. Řádově trvá jednotky sekund.

Refaktoring má navíc tu vlastnost, že i když děláte velkou sérii – provádíte redesign – můžete kdykoli přestat a aplikace stále funguje. Ano, je to tak. Opět to vyplívá jasně z definice. Pokud ne, děláte jenom redesign.

Redesign

„Musíme to přepsat.“ Ta slova nemají manažeři rádi. Znamená to spoustu promarněných (z jejich pohledu – my přece víme, že se to musí udělat a že se to vrátí) hodin/dní (někdy i měsíců a let) práce. A tak se místo redesignování začalo „refaktrovat.“ Přestaňme si lhát. I když třeba během redesignu použijeme nějaký ten refaktoring, pořád je to redesign. Redesignovat můžeme přinejmenším dvěma způsoby:

1. Hurá redesign, kdy se původní kód zahodí a napíše se to znova a občas se něco z toho původního copy&pastene. Tohle se často dnes nazývá refactoring. A většinou z toho vypadne podobná sračka, jako byla před tím, jen bude mít jiný tvar.
2. Můžeme postupně refaktorovat a časem se dostat k lepšímu designu. Ale nezapomínejte, vždycky tenhle proces můžete přerušit a aplikace funguje. Stačí, že změny jsou good enough. Váš kód nikdy nebude dokonalý.

Je třeba si to přiznat. Nedokážu vše. Např. nedokážu odpřednášet nebo napsat článek o Continuous Integration. Je to škoda, protože si myslím, že toho o tom víc celkem dost, dlouho to praktikuju a tak, ale prostě je nad moje síly dát tomu lepší formu než konzultaci či workshop.

Každopádně jsem nad tím článkem strávil spoustu času a byla by škoda, kdyby se nikdy nedostal k očím dychtivých čtenářů. Proto jsem se rozhodl, že článek uvolním pod licencí Creative Commons, nabídnu ho ke stažení, těm co jim nevadí špatná forma. A pokud se najde dobrá duše, která se rozhodne článek dopsat/zeditovat a publikovat na zdrojáku, nechť tak učiní. Jen musí zachovat licenci a uvést mé jméno jako spoluautora. :) Toť pro dnešek vše.

Jo a tady je ten zázrak.

Správa několika verzí aplikace vždy přináší komplexitu, která zvyšuje náklady na vývoj i na údržbu. Běžnou praktikou je, že se zdrojové kódy v repositoři větví (branching) v určitých Milestonech, které se potom stabilizují a po releasu udržují, zatím co v hlavní větvi (trunk, main) se pokračuje ve vývoji. S příchodem DVCS se rozmohlo lokální větvení po featurách, čímž se různorodost verzí aplikace ještě víc rozrostla.

Naproti tomu tu máme agilní praktiky jako je Continuous Integration a Continuous Delivery, které nám říkají, že všichni commitují často do hlavní větve, čímž se předchází integračním problémům. Continuous Delivery navíc říká, že „aplikace má pouze jedinou verzi – tu aktuální.“ Jak to ale udělat, když rozsah některých featur přesahuje rámec sprintu? Ano, můžeme udělat feature branch, ale tím porušujeme pravidlo, že všechno je v hlavní větvi! Poslední verze TeamCity sice podporuje workflow s personal buildy vůči feature branchi, ale to je integrační smell.

Branch by abstraction

Existuje lepší řešení! Proč nevyužít technik OOP jako je polymorfismus a IoC? Je to krapet složitější, než branchování v repositoři, ale zároveň nás to donutí zamyslet se nad architekturou aplikace a ve výsledku bude IMO lepší. V aplikaci můžeme mít nekolik implementací požadované funkcionality, které jsou následně injektovány na základě konfigurace. Některé mohou být stabilní a používat se v produkčním prostředí, zatímco u vývojáře poběží aktuální edge implementace, na které se pracuje.

Takže implementaci kódu máme vyřešenou, ale jak na to v uživatelském rozhraní?

Feature toggles

Pokud naše UI není přímo generováno aplikačním kódem, kde by se dala využít předchozí technika, musíme sáhnout po nečem trochu jiném – přepínačích featur. Začneme tím, že každá feature má svůj jedinečný identifikátor. Každá featura je zařazena do uživatelského rozhraní s tímto identifikátorem a na základě konfigurace je opět rozhodnuto, zda dojde k jejímu zobrazení uživateli nebo ne. Takto se dají nejen snadno odříznout nestabilní featury z produkčního prostředí, ale dá se to využít i k takovým věcem, jako je A/B testování, čí postupné spouštění featury do produkce, jak to znáte z oblíbených služeb jako je Facebook nebo Twitter. ;)

Požadujeme:

• Znalost tvorby webových aplikací ASP.NET v jazyce C# – min. 2 roky praxe, zkušenosti s vývojem aplikací bez vestavěných ASP.NET controls
• Základní znalost MS SQL
• SŠ/VŠ vzdělání (technického zaměření)
• Znalost anglického jazyka na úrovni čtení technické dokumentace
• Ochotu učit se MS technologie
• Zkušenosti s vývojem CMS řešení výhodou

Nabízíme:

• Spolupráci a podíl při návrhu a vývoji produktů
• Perspektivní a zajímavou práci v dynamickém, neformálním přátelském prostředí
• Flexibilní pracovní dobu
• Práci v menším týmu

V případě zájmu mě kontaktujte na e-mail: veronika@trixam.cz

Související

• Odpojte se k nám!

Vrámci zdokonalování tohoto blogu jsem do nového roku přidal několik usnadnění jak sdílet a agregovat moje články.

Agregace

Box s možností přidat si tyhle stránky do své oblíbené čtečky najdete na konci stránky. Nejprve jsem přidal (vrátil) pár odkazů na přidání RSSka do Googlu, Windows Live a na Seznam.cz, což jsou nejpoužívanější portály mých návštěvníků. Pak jsem přidal možnost zaregistravat si můj FriendFeed, kde můžete sledovat nejen moje blogové příspěvky, ale i štěbetání a další aktivity v rámci sociální sítě. A když už jsem byl v tom, tak jsem ještě prolezl logy a podíval se z jakých agregátorů sem ještě lidi chodí a vyšlo mi z toho, že ještě musím přidat Bloglines, Netvibes a Newsgator, abych svým čtenářům registraci do jejich čtečky usnadnil. Tak jsou tam…

Sdílení

U každého článku jsem měl v zápatí odkaz na sdílení v Delicious a v českém Linkuj! a když už jsem byl u toho FriendFeedu tak jsem přidal možnost na něm sdílet i samotné články. Jenže hodně lidí používá hlavně Facebook, tak proč nejít „stádu“ naproti? :) Pak je tu ještě Digg a českej Jagg. Tak doufám, že teď budete mít, drazí čtenáři, snažší sdílet mé bombastické články se svými přáteli.

Jaké služby používáte k agregaci a sdílení vy?