Administrace komentářů

Vývoj funkce může trvat déle, ale doba, po kterou je kód technicky nefunkční (nejde přeložit, nefungují testy), může být podstatně kratší.

Může být kratší, ale také nemusí, někdy může oprava trvat opravdu několik dní. Ale nejde jen o technickou nefunkčnost. Představte si třeba e-shop – někdo upraví funkcionalitu přidávání do košíku. Kód jde přeložit a nepadají testy, ale nejde věci přidávat do košíku (protože se celá funkcionalita mění a znamená to několik dní či týdnů práce). Ostatní členové týmu, kteří dělají na zobrazení obsahu košíku, sestavení objednávky, fakturaci, expedici apod. mohou během té doby sice psát kód a testy, kompilovat s zkoušet testy, ale nemohou si to naživo vyzkoušet, protože s prázdným košíkem nemohou pokračovat – neuvidí, jak se s tím asi bude pracovat uživateli, jestli se to dobře ovládá, jestli se to chová logicky, jestli uživatel nemůže zadat nějaký neočekávaný vstup. S tím vším musí čekat, až tým, který mění košík, dodělá svou práci. Ale proč, je ty změny vůbec nezajímají.

Takhle se to dá naplánovat vždycky.

Je vidět, že jste nikdy nepracoval na větším projektu.

Počet konfliktů není velký, právě protože ten půlden.

Jeden konflikt za půlden mi dává 40 konfliktů za měsíc. Jeden konflikt za čtrnáct dní mi dává 2 konflikty za měsíc. Co je míň?

Ten čtyřnásobný příklad mi nějak nesedí.

Co vám na něm nesedí? Mám nějaké rozhraní, třeba metodu. Vyvíjím novou funkci, předpokládám, že tam budu potřebovat dva další parametry navíc. Přidám je do rozhraní, všichni refaktorují. Za pár dní zjistím, že se jeden parametr vůbec nepoužívá, tak ho vyhodím. Všichni refaktorují. Po nějaké době zjistím, že mi nestačí předat id objektu (ten nový parametr), ale že je kvůli optimalizaci lepší předávat celý objekt. Opět všichni refaktorují. Pak zjistím, že se ta funkce většinou volá s nulovým novým parametrem, takže do rozhraní přidám zpátky i tu původní funkci, která bude volat interně tu novou. Všichni se vrací zpátky ke kódu, který měli na začátku. Kdybych je průběžným tlačením nehotového kódu do společné repository nenutil reagovat na každou moji změnu, nemuseli dělat vůbec nic (nebo jeden refaktoring, pokud bych neudělal poslední krok). Místo toho jsem je nutil k průběžným úpravám, které je odvádějí od jejich práce. Navíc je mi k ničemu historie práce v VCS, protože jsou tam zmatlané dohromady změny funkcionalit a merge.

Kernel je trochu jiná dimenze, ale i tam lze nalézt analogie. Mají jasně stanovený časový plán, kterým se vývoj řídí (merge window, atd.), mají integrační větev next, mají systém "první příspěvek projde bez konfliktů a ostatní mergujou", atd. Na druhou stranu taky mají milion regresí (i bezpečnostních), protože testy žádné a kontrola očima nestačí.

Ale ten časový plán nepočítá s tím, že se ucelené změny v kódu zvládnou během půl dne. Naopak, vývoj jádra je postaven na tom, že se pracuje paralelně ve spoustě větví, a do master větve se kód dává až po funkčních celcích. A že by Linus musel neustále řešit nějaké hrozné konflikty při mergování, to se mi nezdá.