Otrávené API

Otrávené API představuje situaci, která je důvěrně známá každému programátorovi. Během vývoje uděláte nějaké rozhodnutí, které se promítne do návrhu, struktury, výkonnosti či vhodnosti použití. Postupem času se ovšem ukáže, že to nebylo rozhodnutí úplně šťastné. Najednou máme v aplikačním kódu nebo hůře v infrastrukturním kódu něco o čem jsme přesvědčeni, že je špatně. Vždycky mi drásá srdce někomu vysvětlovat, že má použít ztrouchnivělé API, o kterém vím, že by tam nemělo být a nebo by mělo vypadat jinak. Chtěl bych se zmínit jaké možnosti máme, pokud tento problém nastane.

Metoda vyhnívání

Jedná se trochu o alibistický přístup ve stylu něco tam je, funguje to, sice je to špatně navržené, ale dá se s tím žít. Je to následování pravidla Pokud něco funguje, nesahejte do toho. Osobně tuhle metodu volím jenom když není jiného zbytí. Pokud jste nespokojeni s relativně izolovanou částí nejlépe aplikačního kódu, která se nepoužívá nijak často, prostě to nechte být. V případě, že se jedná o exponovanou část vaší infrastruktury, rovnou na vyhnívání zapomeňte a řiďte se dalšími radami.

Obalující rozhraní

Obalíte novým API to původní otrávené. Bohužel tahle metoda není úplně vždy proveditelná, protože málokdy se vám podaří úplně odizolovat implementační detaily. Jinými slovy, jestliže máte otrávené API, budete mít s velkou pravděpodobností i otrávenou implementaci, a kolem té se bude špatně stavit nové čisté API. Tato metoda vám nezabere tolik času na implementaci a testování jako metoda Paralelního API, která je popsána dále.

Paralelní API

kud řešíte zpětnou kompatibilitu. Ne vždy znáte nebo můžete změnit všechny místa použití. Proto vytvoříte paralelní implementaci s rozhraním. Nové a Otrávené API žijí v míru vedle sebe. Otrávené API můžete označit jako deprecated. Bohužel použití Otráveného API vám tam stále straší. V určitou chvíli proto zavřete oči a použijete metodu vykostění.

Vykostění

Pokud se rozhodnete pro nejradikálnější řešení problémů s Otráveným API. Jedná se o úplného odstranění Otráveného API a jeho nahrazení novou verzí. Preferujte tuhle metodu vždy pokud máte vaší code base plně pod kontrolou a zpětná kompatibilita pro vás nepředstavuje závažný problém. Všechny tři předešlé metody totiž hřeší na to, že prohlubují technologický dluh. Rizikem tohoto přístupu je, že po nějakém čase nemusíte byt s výsledkem spokojeni, a budete opět stát ve výchozím bodě.

Závěrečné doporučení

Refaktor kódu a jeho čištění by mělo patřit k základům práce každého vývojáře. Je to mravenčí práce, kterou málokdo ocení a nebo vám na ní poskytne čas. Nicméně s ní musíte počítat pokud nechcete mít problémy s udržováním a dalším rozvojem vašeho kódu. Já osobně preferuji Vykostění Otrávéného API. Takřka vždy se mi totiž ukázalo, že problémy které způsobilo jeho prorůstání do zbytku code base, byly nesrovnatelné s tím, co by stálo jeho včasné odstranění.

CZ Podcast 60 - User Experience Design

V tomto díle jsme se věnovali User Experience Designu, tedy tomu jak navrhovat produkt/službu tak, aby z ní uživatel měl co nejlepší prožitek.

Nepoužívejte Mapu ani String v rozhraní vašich tříd

Když se zpětně dívám, za APIs které jsem vytvořil, dochází mi, že jednou z největších chyb bylo použití tříd ze standardního SDK v jejich rozhraní. Použití tříd, jako java.lang.String java.util.Map apod., bylo samozřejmě dané mojí leností zavádět si speciální typy vyjadřující danou entitu. V budoucnu jsme platil za tuhle lenost velkou cenu.

Použití Mapy

Použití Mapy se mi hodilo pro reprezentaci jednoho řádku, který vracelou jedno vzdáleného API.

    public void processRow(java.util.Map row) {
        ...
    } 

Na první pohled jednoduché použití, ale... Za několik týdnu broušení objektů nad touhle reprezentací řádku jsem potřeboval rozšířit informace, které by o sobě řádek mohl prozradit. Potřeboval jsem metadata k jednotlivým sloupcům, ba co hůře, potřeboval jsem kontrolovat jestli je to řádek originální a nebo synteticky vytvořený. Problém byl na světě. Do Mapy totiž žádnou metodu nepřidáte. Musel jsem pracně předávat metadata jinou cestou. Pokud šlo o typ řádků testoval jsem typ na speciální implementaci Mapy, kterou jsem musel vytvořit. Poučení pro příště, mate-li v API java.util.Map pravděpodobně je něco špatně. Čest výjimkám potvrzujícím pravidlo.

Použití Stringu

Měl jsem třídu, která vyjadřovala kontext aktuálně přihlášeného uživatele. Identifikátor uživatele byla prostý java.lang.String přestože se jednalo o číselný identifikátor. Opět chyba, za kterou bych si dal rákoskou přes prsty.

    public String getUserId() {
        ...
    }

Co čert nechtěl, původní reprezentace se změnila z čísla opravdu na řetězec. Ve všech navázaných API byl String a na místech, kde bylo potřeba rozeznat původní číslo a nově řetězec, se muselo provést rozpársování. Správné řešení bylo použití hned od počátku objekt reprezentující uživatelův identifikátor.

    public UserIdentifier getUserId() {
        ...
    }

Další typické zneužití java.lang.String občas přichází v podobě konstant, které by bylo možné vyjádřit výčtovým typem. Mimochodem doporučuji přečíst poměrně kontroverzní, ale poučný článek Stefana Schmidta Never, never, never use String in Java (or at least less often :-).

Stejný problém představují tyto typy na místě návratových hodnot. Občas si dokonce pomůžeme například polem a nebo zavedeme nějaký tuple. Opět se toho vyvarujte. Sváže vám to do budoucna ruce, API nebude přehledné a těžko se vám bude rozšiřovat s ohledem na zpětnou kompatibilitu.

MongoDB pár tipů na zajímavé prezentace

Čím víc proníkám do MongoDB tím vice se mi zamlouvá. Líbí se mi jak na ní inženýři s 10gen makají a neustále jí vylepšují a jak otevřená je komunita kolem této dokumentové NoSQL databáze. Tenhle týden mě zaujaly tři prezentace, na které vám dám tipy.

• Optimizing MongoDB: Lessons Learned at Localytics
• Hybrid MongoDB and RDBMS Applications
• Lessons Learned from Migrating 2+ Billion Documents at Craigslist

Utvrzené názory za rok 2011

Začnete-li psát článek v první den nového roku máte jenom dvě možnosti. Rekapitulovat rok předcházející a nebo věštit budoucnost pro rok nový. Protože protože mé předchozí předpovědi byly spolehlivé asi jako odhad míry zadlužení Řeckého statistického úřadu nebude se do nich letos pouštět. Nechci zároveň ani psát o roce 2011 ve formě jakési rekapitulace. Rozhodl jsem se proto, že se s vámi zkusím podělit o názory, ve kterých mě rok 2011 utvrdil.

Život v IT

Většina problémů v IT je jenom z malé části ovlivněna metodologií, technologií a kvalitou lidí, které máte k dispozici. Nejzásadnější příčinou je špatná komunikace tedy spíše nekomunikace a nejasná zodpovědnost. S tím souvisí i alibismus, který bych si troufal označit za typickou českou vlastnost (nejen v IT).

Dobrá zpráva. Zlaté české ručičky není mýtus. Špatná zpráva je, že to platilo pro generaci našich otců, které tady tvrdě vycepoval socialismus, kde většina zboží bylo nedostatková. V kontextu IT to ovšem znamená, že naše budoucnost je limitovaná naší cenou, po kterou budeme brání jako levná pracovní síla z východu. Pokud to chceme změnit musíme udělat tři věci: tvrdě pracovat, snažit se inovovat a neustále si rozvíjet naše vědomosti a znalosti.

Koncept renesančního člověka není jenom oblíbená Filemonova průpovídka, ale věc, kterou vám potvrdí kdokoliv kdo překročil vlastní stín. Pokud se budete úzce profilovat pouze v jedné oblasti, nedej bože jenom IT, nikdy nezískáte potřebný nadhled a inspiraci, která vás posune o úroveň výše. Ve všech knihách a oborech lze najít plno paralel, které můžete s úspěchem v IT uplatnit. Bylo by velkou chybou před nimi zavírat oči.

Jedno přísloví říká: "Lepší být jeden den orlem než celý život ovcí". Steve Jobs tuším prohlásil: "Je lepší být pirátem než se dát k námořnictvu". Tím chci říci, pokud něčemu věříte, bez ohledu jestli je to technologie či přístup, řiďte se tím bez ohledu na to, že jdete hlavou proti zdi.

Nejlepší konfrontace vlastních myšlenek a názorů je jejich veřejná prezentace. Můžete se plést, můžete mít pravdu, nejhorší přístup je mlčet. Chyba není mít opačný názor, chyba je nemít žádný názor. Nejlepší konfrontace bývá s lidmi absolutně opačného názoru.

Programování

Programování je řemeslo jako každé jiné. Pokud v něm chcete být opravdu dobří počítejte s tím, že vám to zabere minimálně deset let intenzivní práce. Počítejte s tím, že se mnohokrát spletete a budete muset korigovat svoje předchozí způsoby, o kterých jste si mysleli, že jsou to správnou cestou.

Složitý kód není dobře jednotkově testovatelný. Jednotkově netestovaný kód není dobře objektově navržený. Nedobře objektově navržený kód je kýbl hnoje. Do kýblu hnoje je lepší kopnout a začít znovu a lépe. Objektový návrh a tvorba API se nepovede nikdy na první pokus. Refaktorujte do té doby než jste absolutně spokojeni s každým detailem kódu. Každý dluh, i ten technologický, který uděláte vás později dožene.

Není nic jako kolektivní vlastnictví kódu. Každý jeden řádek kódu, každá třída, každý modul má jednoho jediného vlastníka, který je za něj zodpovědný. Nikdy neakceptujte kód v formě kontribuce pod který byste se sami nepodepsali.

Ďábel leží v detailech. Buďte perfekcionisté nejenom co se týká kódu samotného, ale i jeho dalších detailů. Struktuře, dokumentaci interní i veřejné, konzistenci.

Výkonnost ovlivňujte na úrovni návrhu nikoliv na úrovni kódu. Změnami v kódu jste schopni ovlivnit výkon v řádu procent, změnami v návrhu ovlivňujete výkonnost v řádu desítek procent.