Stala se nám takový nemilý, nepěkná věc. Do kódu se nám dostaly závislosti na knihovnách, které mají buď nestabilní nebo zastaralé API.

První je Apache HttpClient ve verzi 3. Prostě takhle jednoho dne přijdeme do práce a zjistíme, že máme v kódu spoustu závislostí na třídách jako je HttpMethod. Máme je samozřejmě pěkně izolované v jedné vrstvě aplikace, ale i tak je to na neuvěřitelném množství míst. Nevím jestli jste si všimli, ale je to opravdu HttpClient ve verzi 3. Dnes, v době, kdy je nová verze 4 už asi pět let na světě!

Druhá podobná věc se nám přihodila s Akkou. Do relativně důležitého API se nám dostala scala.concurrent.Future. A ano, opět čtete správně, není to Javovská java.util.concurrent.Future, je to cosi ze Scaly. Proč jsme něco takového dopustili? Asi z mladické nerozvážnosti. Prostě nám tenkrát nedošlo, že děláme blbost. Nemám nic proti Scale nebo Acce. Jde jen o to, že komunita kolem obou mírně řečeno kašle na zpětnou kompatibilitu. Takže jedeme na obstarožní verzi Akky, protože zkrátka nemáme dost času a odvahy na aktualizaci. Nejen že mají v nových verzích jiné API, ono se to celé i dost jinak chová.

Proč to tu vlastně píšu? Chci si pro příště vtlouci do hlavy toto:

Do důležitých API podezřelé třídy nepatří!

Otázka je, co jsou podezřelé třídy a jak se bez nich obejít? Podezřelá třída obvykle pochází z neustálené knihovny. Z takové, v které se často mění API nebo chování zpětně nekompatibilním způsobem. Je samozřejmě těžké předvídat budoucnost na základě minulosti, ale většinou to člověk pozná z release notes, uživatelského fóra nebo dokumentace. V obou našich případech to bylo evidentní. To, že už existuje nová, úplně jiná verze HttpClienta jsme věděli. To, že autoři Scaly ještě nepochopili, k čemu je dobrá zpětná kompatibilita, také není žádné tajemství.

Takže jak správně postupovat? Příště bych se nejdřív podíval, jestli neexistuje ekvivalent buď přímo v Javě nebo v nějaké prověřené knihovně jako je Spring. V našem případě jsme mohli použít abstrakci ze Springu. Ta by nás od API HttpClienta odizolovala. Mohli bychom se přepínat mezi implementacemi HTTP knihovny podle libosti. Stejně tak v případě Akky jsme mohli použít standardní Javovskou Future alespoň na úrovni API. Tím bychom si umožnili mnohem snazší update nebo dokonce změnu implementace.

No jo, ale co když neexistuje neexistuje žádná důvěryhodná abstrakce? Pak se musím se rozhodnout. Buď budu autorům knihovny věřit, že budou dodržovat zpětnou kompatibilitu. Také si musím být docela jist, že danou knihovnu nikdy nebudu chtít vyměnit za jinou. Nebo mi nezbyde nic jiného, a budu muset nedůvěryhodné třídy obalit do nějaké své abstrakce. A to tak, aby mi ta závislost nikudy neprosakovala. Vím, že je to na první pohled zbytečná práce. Vyhnete se ale tomu, co dříve nebo později čeká nás – bolestivému a zbytečnému přepisu hromady kódu.

Udělal jsem velikou chybu. Nechal jsem se uvrtat do role podobné projektovému manažeru. Jak byste asi čekali moc mi to nejde ani mě to nebaví. Tak si tu chci napsat co to obnáší, abych už příště podobnou bláhovost neudělal.

Schůze
Kalendář někoho kdo komanduje lidi je úplně jiný než člověka co dělá nějakou užitečnou práci. Pěkně je to popsáno tady. Jako manažer prostě potřebujete komunikovat s mnoha různými lidmi. Z čehož plyne oblíbená manažerská kratochvíle – schůzky. Jako programátor je musíte tiše trpět, jako manažer je svoláváte. A to i několik za den. Snažím se je omezovat na minimum a na co nejkratší čas, ale i tak je jich dost. Navíc mám pořád blbý pocit, že ostatní vytrhávám od práce.

Nuda
Nejhorší ale je, že schůzky jsou na té práci nejzajímavější. Ano, čtete správně. Schůzky jsou zajímavé. Jako manažer totiž nemáte moc jiné práce. Teda pokud nepočítám těch pár mailů. Ono to plyne z definice. Řízení lidí je hlavně o komunikaci. Takže buď mailujete, plánujete schůze nebo na nich sedíte. Pokud ale neřídíte víc projektů na jednou, tak mezi tím máte spoustu volného času. Takže sedíte v práci a nemáte do čeho píchnout.

Programování a řízení nejde dohromady
To že má člověk volný čas se dá brát jako pozitivum. Ve volných chvílích se dá udělat něco užitečného. Třeba programovat. Zkusil jsem to, a zjistil jsem, že to nezvládám. Jedna nebo druhá činnost tím trpí. U mě bohužel trpí obojí. Když programuji, tak nechci být vyrušován. Natož pak sám sebou. Takže manažerské aktivity odkládám nebo jinak zanedbávám. Největší legrace pak je, když v hlavě řešíte programátorský problém a přitom sedíte na schůzi, kterou máte řídit.

Odpovídáte za věci, které nemůžete ovlivnit
Řídící role sebou nese také odpovědnost. A to i bohužel za věci, které nemůžete ovlivnit. Jako programátor můžete s klidem říci, není to hotové, protože Franta nedodal XYZ i když jsem mu to každý den připomínal. Jako manažer za to nesete zodpovědnost, a to i přesto, že nemáte žádnou pravomoc Frantovi říkat co má dělat. Musíte se pokoušet o řešení, i když víte, že žádné neexistuje. Je to prostě vaše práce.

Když to tak po sobě čtu, tak nevidím důvod, proč by člověk, kterého baví programování, chtěl dělat manažera. Já to tenkrát vzal, protože jsem si to chtěl zkusit. Je to zajímavá zkušenost, ale mě osobně to nezaujalo.

Na každou otázku existuje jednoduchá, snadno pochopitelná, nesprávná odpověď.
2. Murphyho zákon

Asi znáte ten pocit, kdy programujete a tušíte jak by ten kód měl správně vypadat. Chvíli třeba i vzdorujete, ale něco vás pořád tlačí do toho správného řešení. Obvykle vyplave na povrch nějaký problém a vy si říkáte: „Jó, kdybych já to tenkrát udělal dobře. To bych tenhle problém neměl.“ Ještě to třeba nějak ošulíte a ono to za nějakou dobu vyhřezne jinde. Nakonec svoji lenost přemůžete a uděláte to tak, jak to mělo být od začátku. Jste odměněni úžasným zážitkem. Máte před sebou jednoduché a elegantní řešení problému. Cítíte že je to dobře, že na tom není moc co zlepšovat. Zase jste jednou něco udělali dobře. Je to úžasný pocit.

Takovému výsledku říkám stabilní řešení. Nejen že je to očividně dobře, ale stejně jako kuličku táhne gravitace na dno důlku, tak i vás k tomuto řešení něco táhne. Stačí jen dávat pozor. Včera jsem to v opilosti někomu vykládal a přišlo mi to úplně mystické. Takhle za střízliva to není ono, ale moc daleko to k tomu nemá. Je to asi něco podobného, jako když fyzici hledají elegantní matematické vyjádření fyzikálních zákonů. Když je zákon ošklivý, tak mu nevěří. Příroda ale přeci nemá důvod generovat hezké rovnice. Stejně tak nemají problémy v programování důvod generovat hezký kód. Ale přesto to tak často je.

No jo, jenže pak tu máme další množinu problémů, která je naprosto opačná. U ní vybíráte jen ze špatných řešení. Ať děláte co děláte víte, že to bude tak či tak špatně. Volíte mezi jednoduchým a rychlým, mezi testovatelným a kompaktním, mezi robustním a čitelným. Když takový kód někomu ukazujete, tak se trochu stydíte. Víte, že to je špatně, ale alternativy jsou ještě horší. Je to takové vratké. Stačí malá změna požadavků a musíte to celé předělat. Stačí další zádrhel a předěláváte to znovu. Prostě ne a ne najít to správné východisko.

Zajímalo by mě čím to je. Je to tím, že to správné řešení někde je a já ho jen nevidím? Nebo pro daný problém hezké řešení neexistuje? Nebo je špatně navrženo všechno kolem, takže mi tam to případné elegantní řešení nepasuje? Nebo je to nevyzrálostí nástrojů? Třeba je špatně programovací jazyk, v kterém se to snažím vyřešit. Jako kdybych se snažil popsat fyzikální zákony a neuměl bych násobit. Pak by také některé rovnice vypadaly neelegantně a hloupě. Nevím. Asi jsem jako ti fyzici, myslím si, že by ke každému problému mělo být elegantní řešení. Tak proč se mi ho sakra tak často nedaří najít?