Administrace komentářů

My tady ale píšeme obecně i o větších projektech, kde vám rozhodně půl den nestačí na napsání, odladění a otestování nějaké nové funkce.

Asi jsem se nevyjádřil přesně. 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ší.

Další věc je, že práci lze řídit ne přes feature ale přes čas. Místo "až to bude hotový tak to commitnu" můžu jet stylem "commitnu to, co budu mít za den práce" - samozřejmě s tím, že to je technicky v pořádku.

Ano. Jenže spolupráce je také to, že nerozbíjím program ostatním pod rukama. Takže commituju pravidelně, ale do společné repository dám až funkční výsledek.

Přesně tak, a tenhle cyklus netrvá déle než jeden den. To je taková empiricky stanovená doba, za kterou se dá udělat kus práce, který má aspoň nějaký význam.

Pro ilustraci například když mám udělat GUI kde bude "Save" a "Save As", tak můžu za jeden den stihnout udělat to "Save" a commitnout, druhý den udělat "Save As" a commitnout. Třetí den můžu do obou dialogů dodělat tlačítko "Make new directory" atd. Nemusím dělat 3 dny v koutě a pak najednou commitnout všechny 3 změny.

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

To může fungovat tak ve skupině do 5 vývojářů. Větší projekt už je potřeba modularizovat a není možné, aby si každý měnil rozhraní, jak se mu zachce.

No, běžně a bezproblémově to lze natáhnout na 10-15 lidí. Což pokrývá spoustu týmů. Pokud uděláte tu "modularizaci", tak efektivně dělíte projekt na víc podprojektů se vším co k tomu patří.

To máte nějaký divný postup práce, kdy se vám pořád mění většina kódu. Podle mne je normální, že se změny v rozhraních mezi moduly dělají nárazově a po dohodě autora i uživatele rozhraní. Takže se nemůže stát, že bych něco musel složitě a zdlouhavě přepisovat.

V praxi to není většina kódu a zdlouhavé přepisování. Počet konfliktů není velký, právě protože ten půlden.

Pojem "autor kódu" je dost přeceňovaný. Pokud potřebuju autora kódu, tak buď to znamená, že kódu nerozumím, tudíž to autor v první řadě neudělal dost čitelně, nebo to znamená, že se bojím do toho hrabat, tudíž tam autor kódu neudělal dost testů.

Komunikaci od autora k uživatelům je nejlépe dělat přes ten kód, tak, aby každý kdo k tomu přijde, už pak autora nepotřeboval.

Nevím, proč bych si měl průběžně integrovat všechny postupné změny – než refaktorovat nějaký kód čtyřikrát podle toho, jak se mění rozhraní nějaké funkce, raději ho zrefaktoruji jen jednou, až je to rozhraní hotové.

Ten čtyřnásobný příklad mi nějak nesedí. Dejme tomu, že v 8:00 ráno je rozhraní ve stavu A, franta si ho stáhne, a převede ho do stavu B a ve 12:00 pushne. Mezitím v 9:00 přijde pepa, stáhne si verzi s rozhraním A, udělá nad ním funkcionalitu X, a ve 13:00 bude chtít pushovat. Nejprv udělá pull, kterej mu vytvoří lokální konflikt, kterej vyřeší a ve 13:30 pushne. Mezitím franta převede rozhraní do stavu C a v 15:00 bude chtít pushnout, takže udělá pull, zjistí že přibyl jeden uživatel rozhraní B (pepa), kterého převede na rozhraní C, ale to už pepu nezajímá. Franta si pak může klidně dělat verze D, E, F, ... a akorát pokaždé změní všechny uživatele vč. pepy. Když k tomu druhej den pepa přijde, udělá si pull, tak zjistí, že jeho kód používá rozhraní F, a svůj další den začne prostě s tímhle stavem.

Navíc ten váš postup míchá do jednoho commitu nesouvisející změny. Když se pak ukáže, že moje úprava byla špatně a musím ji vrátit, vrátím i změny vyvolané mergem s jinou větví. Takže ty změny musím provést znova.

Tak na to jsou ty DVCS, že si můžu oddělit commity svojí práce s commitem integračním (a nebo dělat rebase, jako kdyby ty změny z upstreamu tam už byly když jsem k tomu přišel).

Podívejte se na vývoj linuxového jádra. Kolikrát se tam mění kód, který znamená jednu novou funkcionalitu. A vy byste po vývojářích chtěl, aby to, co se tam probírá několik dní nebo i týdnů či měsíců, napsali rovnou na čisto za půl dne.

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