Cestou do práce jsem tuhle poslouchal díl Hanselminutes, který se věnuje provařeným “anti-patternům” jako Copy Paste Programming, Iceberg Class, Copy Folder Versioning atd. – v podstatě je celý díl komentářem k tomuto motivačnímu kalendáři.

Jedním z probíraných antipatternů je i Reinventing the Wheel, který úzce souvisí se syndromem NIH, Not Invented Here. Ten je zhruba o tom, že některé týmy a priori odmítají cizí software s tím, že “nebyl vynalezen zde” a přinesl by víc potíží než užitku. Takové uvažování je zvlášť v agilní komunitě považováno za špatné, za “anti-pattern” a nálepka NIH má náležitě pejorativní nádech. Ale víte co? Čím jsem starší, tím víc NIH chápu.

Software se totiž dělí do dvou skupin – ten z první skupiny funguje dobře a ten z druhé ne. Hranice mezi těmito skupinami je bohužel tenká a často subjektivní a problémem cizího software je, že málokdy lze dopředu odhadnout, do které vlastně patří. Už se mi tak mnohokrát stalo, že jsem si řekl “nebudu programovat nic vlastního, prostě použiju nějaké stávající řešení”, a pak následovalo zhruba tohle:

• Vygooglil jsem si několik řešení pro můj problém
• Zkontroloval licence
• Strávil čas hledáním ohlasů na jednotlivá řešení, abych vyloučil outsidery nebo naopak objevil “hvězdy”
• Zkontroloval další metriky, které mě obvykle zajímají, např. jaká je komunita okolo projektu, jestli je aktivně vyvíjen, jestli se fixují bugy apod.

Nakonec jsem nějaké řešení vybral, nasadil a… a byl zklamán, protože software aplikován na můj konkrétní případ s mými konkrétními požadavky měl nějaký problém. Takže znovu – zkusit dalšího kandidáta, strávit s ním další čas, zjistit, jestli vyhovuje atd. Někdy navíc ani není možné během krátké zkušební doby zjistit, jestli software 100% vyhovuje, což pak může vést ke scénáři, který bych nikomu nepřál, ale který jste patrně všichni někdy zažili. Ke scénáři zvanému noční můra.

Noční můra je, když se ze začátku cizí software tváří schopně, a až časem, velmi postupně, zjišťujete, že řešení vlastně moc nevyhovuje. Ne, nevyhovuje je slabé slovo, po čase zjistíte, že původní řešení z duše nenávidíte. Stalo se mi to u několika zásadních věcí, jako je třeba zvolené CMS pro web, zvolený mikro-framework pro zákaznickou aplikaci, jeden interní systém apod. Ve všech těchto případech nastalo řekněme po roce používání nepříjemné dilema – trpět dál s cizím systémem, zkoušet ho upravit, pokud to vůbec jde, nebo s relativně vysokými náklady migrovat někam jinam? Ale kam? Na “NIH” nebo “IH” řešení?

Čím víc podobných zkušeností jsem udělal, tím víc NIH chápu. Ano, jsou věci, kde NIH považuji za jasný syndrom, např. bych v .NETu rozhodně nezvažoval psát vlastní unit testing framework, ale ani u těchto věcí nikdy neříkej nikdy – třeba Jakub Vrána teď napsal “yet another” minifikátor JavaScriptu, a přesto k tomu měl dobré důvody:

• JSMin měl problematickou licenci
• Dal si tu práci, vyzkoušel několik stávajících řešení, a řada z nich kupodivu obsahovala chyby (viz článek a komentáře)

Ostatně, zkušenost s cizím SW popisuje Jakub takto:

Přiznám se, že cizí knihovny nepoužívám moc ochotně. Nejdřív strávím spoustu času hledáním té, která by mi vyhovovala. Pak často zjistím, že mi stejně něčím nevyhovuje. Když to opravím, pošlu změnu autorovi a on ji přijme, tak čekám na vydání nové verze. Když vyjde, tak musím otestovat, jestli se neporouchalo něco jiného. Cizí knihovny taky často mají závislosti (např. na Javě), které já vyžadovat nechci.

Takže asi tak. Osobně se stále snažím hledat existující software, který by můj problém řešil, a často je to pragmatické – přeci jen třeba naprogramovat celé CMS je tak velká práce, že je výhodnější se občas zavztekat nad WordPressem. Přesto jsem během posledních let svůj vztah k NIH přehodnotil – docela tento syndrom chápu. Software is hard.

Ve svém okolí už naštěstí nevím o nikom, kdo by psal kód v češtině, a to je jedině dobře. Při vývoji se ale člověk nesetkává jen s kódem a “bohužel” toho čte nebo píše daleko víc, například:

• Commit message do VCS
• Komentáře na GitHubu, BitBucketu nebo jiném code review toolu
• Tickety v bug tracking systému
• User stories / lístečky na tabuli
• Doc commenty, generovaná dokumentace
• Specifikace
• Wiki atd.

Každá z těchto věcí jde potenciálně psát v češtině nebo v angličtině, a pokud jste čistě lokální tým bez větších šancí na brzkou mezinárodní expanzi, má čeština své výhody a je potřeba se rozhodnout, kde udělat ten nepříjemný přechod.

Zatím na všech místních projektech, co jsem byl, se zhruba dodržovalo následující:

• Kód v angličtině
• Komentáře a případná dokumentace v angličtině
• Commit message v angličtině
• Všechno ostatní v češtině

Ono to má svou logiku – vše, co je blízko kódu, je anglicky, a “nedůležité” věci okolo se kvůli snadnější srozumitelnosti a řadě dalších důvodů píší česky. Trochu nepříjemné ale je, že se tyto věci prolínají – např. bug tracking systém v češtině zobrazuje commit message v angličtině, diskuze pod anglicky psaný commitem probíhá v češtině apod.

Protože jsou častým účastníkem oněch “třecích ploch” právě commity, přemýšlel jsem, jestli nezačít psát commit zprávy česky a anglicky nechat jen kód. Opravdu, jaký má smysl psát popisy commitů v angličtině, když veškerá další komunikace okolo projektu probíhá v češtině? Není naopak vynucovaná angličtina určitým klackem pod nohy vývojářům? Přeci jen, dávat dohromady anglické věty už je něco jiného než psát v angličtině kód.

Zatím jsem se k psaní commit zpráv česky neodhodlal, stále mi to připadá svým způsobem divné, ale trochu to ve mně hlodá pokaždé, když někde vidím mix češtiny a angličtiny.

Kde děláte čáru mezi češtinou a angličtinou vy?