Rozsah knihovny je špatná otázka
Debata o standardních knihovnách se vede jako spor o velikost. Jedna strana chce baterie v balení, druhá chce minimum a zbytek z registru. Obě strany mluví o rozsahu a obě míjejí to, co skutečně rozhoduje.
Lepší otázka zní: jaké společenské uspořádání vyrábí kvalitní knihovnu. Kvalita není vlastnost rozsahu, je to výstup organizace.
Tři knihovny, tři jiné příčiny
Python má velkou knihovnu a v ní nesourodá zákoutí. Modul unittest se drží jiných konvencí pojmenování než okolí. To ale není daň za velikost — je to stopa po raných rozhodnutích, která nikdo nedělal s výhledem na desetiletí. A stojí za to dodat druhou půlku: právě ochota vystavit funkčnost brzy a nedokonale udělala z Pythonu základ, na kterém vyrostla datová věda. Čekání na dokonalé API má taky svoji cenu, jen ji nikdo nefakturuje.
Go ukazuje, že velká knihovna a vysoká kvalita si neodporují. Tým na to má institucionální kapacitu — lidi, kteří API navrhují jako svou práci, ne po večerech. K tomu má přetlakový ventil v podobě golang.org/x, kam jde všechno, co se ještě nechce zavázat stabilitou.
Rust je nejzajímavější případ. To, co v knihovně je, patří ke špičce: kolekce, iterátory, návrh z verze 1.0. A přesto v ní roky chybí věc tak základní, jako je čtení náhodných bajtů od operačního systému. Ne proto, že by to bylo technicky těžké. Proto, že to vyžaduje shodu a vytrvalou pozornost, kterou dobrovolnická struktura neumí dodat. rust-lang-nursery se změnil ve hřbitov nedotažených záměrů.
Proč jednoduché věci zůstanou nehotové
Z Rustu plyne pravidlo, které se dá přenést jinam. Nedodělané zůstávají úlohy, jejichž náročnost není v obtížnosti, ale v délce závazku. Napsat generátor náhodných bajtů je práce na odpoledne. Navrhnout jeho API tak, aby se za deset let nemuselo měnit, protýkat ho třemi platformami a zavázat se ho udržovat napořád, je něco úplně jiného.
Rozhodovací pravidlo, které z toho plyne, je nepříjemně střízlivé: nedívej se na to, jestli tvůj tým tu funkčnost umí napsat. Dívej se na to, jestli má kdo ji vlastnit za pět let.
Totéž platí o tvé sdílené knihovně
Přesně stejný mechanismus běží uvnitř firem. Sdílená komponentová knihovna, design systém, interní balíček s utilitami — všechny mají tutéž otázku, jen se o ní nikdy nemluví nahlas. Ne kolik toho pokrýt, ale kdo je bude držet, až autoři přejdou na jiný projekt.
Rozpad sdílené knihovny proto nevypadá jako pokles kvality kódu. Vypadá jako přibývání skoro stejných variant, protože upravit sdílenou verzi znamená čekat na někoho, kdo na to nemá čas. Rozsah se nezměnil. Zmizela kapacita.
Co si z toho odnést
Když se příště povede spor o to, jestli má být knihovna velká nebo malá, přeformuluj ho. Zeptej se, kdo API navrhuje, kdo za ně nese odpovědnost a co se stane, až ten člověk odejde. Odpověď na tohle předpoví kvalitu líp než jakýkoli argument o rozsahu.
Užitečný je i ten přetlakový ventil, který má Go. Oddělit prostor, kde smí věci žít bez záruky stability, od jádra, kde se stabilita slibuje, sníží cenu chyby v návrhu na skoro nulu. Bez něj se každé přidání stává nevratným rozhodnutím a tým začne raději nepřidávat vůbec.
A u vlastního kódu ber „napsat to" a „vlastnit to" jako dvě různé položky rozpočtu. Ta druhá je skoro vždycky větší a skoro nikdy se neplánuje.