Coders at Work: rozhovory s velikány v oboru

Pořídil jsem si knihu Coders at Work: Reflection on the Craft of Programming. Což jsou rozhovory s velikány z oboru. Chtěl jsem se tedy dozvědět nějaké jejich názory. Takový výtažek, který jsem si z toho vzal, někde i sám přidal, tu sdílím.

Začneme školou: není potřeba. Pro to, abych mohl programovat. Programátorský svět se tak rychle vyvíjí, že se musí učit neustále. Kdyby na škole záleželo, pak by se škola nikdy nemohla opustit.

V rozhovorech se řešilo i jaké má programování postavení mezi obyčejnými lidmi. Zda by se mělo zařadit mezi základní předměty jako jazyk a matematiku. Nemělo. Základní věci lze naklikat a pokročilé věci stejně nepochopí, jako programátoři si nezvládnou ušít oblek.

Taky si pamatujete, jak pracovat ve skupině bylo bráno jako podvod? Tak přesně taková je nejlepší praxe: párovat. Pomůže udržet focus na úkol. Aneb kolikrát začnete lelkovat, když se dostanete do slepé uličky a potřebujete odstup? Ten druhý má ten potřebný odstup. Jiný pohled. A tak.

Párování je dobré taky pro zaučování. Stejně jako jinde se nováček učí pozorováním mistra, aby se jím jednou taky stal, je dobré toto aplikovat i v programátorském světě. Nemusí to být nutně nováček. Spoustu lidí se naučí algoritmy atp., ale nikde se neučí jak debugovat. Což je skill, který trvá dlouho osvojit si. Párováním ho lze získat mnohem rychleji.

Pokud není dostupný nikdo do dvojice, stačí mluvit s něčím. Třeba na PyCON UK 2014 rozdávali debug kachničky. Často jen říct si, jaký mám problém, co je jeho vstupem a výstupem, stačí k jeho vyřešení.

Aby ale nebylo potřeba debugovat, Tony Hoare má skvělou frázi, že lepší mít kód, kde samozřejmě není žádný bug, než kde není žádný zřejmý bug. Nebo lépe v originále: „your code should obiosly have no bugs rather than having no obvious bugs“. Pro to je potřeba držet čitelný kód. Základem je formátovat kód, stejně jako formátujeme běžný text. Což Dijkstra podtrhává větou: „if you can’t write in your native language, give it up“. Hned druhým důležitým bodem je správné pojmenování. Jsou i programátoři, kteří mají vždy po ruce slovník.

Čitelnost se pojí i s optimalizováním. Pravidlo je, zůstat u čitelnosti a neoptimalizovat. Protože často, ne-li vždy, programátoři řeší optimalizaci toho, co je cool, zajímavé, náročné. Ale tyhle části nemají žádný zásadní vliv na optimalizaci a co je skutečně potřeba, na to se nesáhne. Proto lepší zůstat u čitelnosti a až když je opravdu potřeba, teprve pak jít optimalizovat. Což má druhou výhodu – čitelnou verzi už mám a tu nesmažu. Nechám ji vedle té optimalizované. Tak bude kód čitelný a pokud se najde chyba, můžeme přepnout na pomalejší správnou. Mimochodem jednodušší je optimalizovat správný kód, než opravovat optimalizovaný kód.

Postupným vývojem ale kód tak jako tak degraduje. Když se problém zapisuje do kódu, musí se najít způsob, jak to zapsat. Jenže postupem času se problém může trochu změnit. Nebo naopak problému začneme lépe rozumět. Tím nám původní kód přestává vyhovovat a musí se upravit. Protože když se ponechá ve starém znění, kód začne být nečitelný.

Otázka je, kdy refaktorovat? Někdo říká neustále, někdo po Xtém sprintu, … Udělejte to tak, jak je potřeba. Často stačí držet se skautského „ponechám kód v lepším stavu, než jsem k němu přišel“. Někdy ale je potřeba změnit celou architekturu. To se dá poznat podle pomalosti vývoje, aplikace, bugovosti atp. Vývojáři nejsou ze dne na den horší. To jen kód degraduje a je horší ho udržovat.

Jak ale tohle vysvětlit produkťákům/klientovi? Nijak. Refaktor je potřeba si plánovat mezi běžné věci. Něco odhadnu na tři dny, tak tam šoupnu čtyři na potřebný refaktor. Pokud potřebuji velkou změnu, třeba frameworku, o čem se nerado slyší, zabalím to do jiného názvu. Třeba údržba pro zrychlení vývoje, aplikace a menší chybovost.

Není nic horšího, než když se někdo bojí sáhnout na něčí, či dokonce svůj, kód. Na to je lék testování. Testy dodávají jistotu. Čím lépe otestovaná aplikace, tím větší jistota a klid na duši.

Aby testy měly smysl, je potřeba testovat inkrementálně, stejně jako se píše kód. Nejlépe formou TDD. Často se naráží na problém, že nelze napsat test, pokud nevím, jak kód bude vypadat. To je chyba. Je dobré nejprve vědět, jak chci kód využívat, a poté napsat implementaci. Když udělám opak a zjistím, že chci nakonec používat jinak, musím celé předělat. Pokud z nějakého důvodu takto nelze, aspoň napsat kód nejvíc jednoduše, poté testy, a nakonec udělat refaktor a případné optimalizace.

Testy poslouží i jako taková dokumentace, pokud jinou nemáte. Což teda je potřeba nějakou dokumentaci mít a hlavně ji nepsat až po napsání kódu, ale už s ním. Protože jen tak zdokumentujete, co je potřeba. Za dva dny si těžko vzpomenete na všechny konstrukce, které jste napsali a hlavně proč přesně.

Někdy programátoři dokumentují pouze pokud se jedná o znovupoužitelný kód. Na něco takového zapomeňte, znovupoužitelnost neexistuje. Resp. pouze u stejných problému a často ty stejné problémy jsou již vyřešeny. Vaše aplikace bude jednodušší, pokud ji napíšete jednodušeji bez zbytečných vrstev. Líbila se mi hláška, proč OOP a použitelnost moc nejdou k sobě: „you want banana and they carry around implicit environment with gorilla holding banana within jungle“.

Je to trochu tím, že vývojáři píší kód. A když píšou knihovnu (nebo klidně i celý jazyk, podívejme se třeba na Ruby), chtějí přidat něco svého. Jenže je více věcí, které lze přidat, než věcí, které by se pouze měli přidat. Na to je potřeba cit, který má málokdo. Softwarový vývoj je hodně jiný oproti cokoliv porovnatelnému a stále se učíme jak ho nejlépe vést. I hardware se vytváří jako například stavba domu – cihlu položit na cihlu, sem dám dveře, okno.

Například na otázku „jak bude dlouho trvat tahle změna?“ máme několik možných odpovědí. Pokud je to změna na jeden řádek, víme, že máme rychle hotovo. Jenže pokud je taková změna nesystémová, víc takových hacků by znepřehlednilo kód a pozdější maintenance. Takže druhá možnost je zahrnout nějaké lepší pojmenování a refaktor okolního kódu. Tím ale pouze oddálíme čas, kdy se dostaneme do situace, jako v prvním případě. Pak je třetí možnost, že to uděláme pořádně. Což znamená úpravu zanést řádně do celé aplikace. A to musí programátoři vidět a dát odhad přibližující se poslední možnosti. Pak by nemělo dojít k nutnosti začít na zelené louce.

Nejchytřejší programátoři by neměli automaticky o všem rozhodovat. K dobrému rozhodnutí je právě potřeba ten cit. Bez empatie či emoční inteligence půjde těžko navrhnou dobrý jazyk, API, GUI apod.

Na závěr zmíním, že produkty se netočí kolem technologie, ale kolem výsledku produktu samotného. Technologie je jen prostředek. Takže je jedno, který framework nebo jazyk se použije a není třeba se kolem toho hádat. Já mám rád třeba čokoládový Häagen Dazs, vy zase jinou zmrzlinu. A taky se u toho nehádáme. :-)