neděle 29. ledna 2012

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í.