Administrace komentářů

Reakce na #143 (už mě ten štrůdl nahoře nebaví)

Tak já sem tedy přestěhuji i odpověď na komentář FJ. Ono je to obsahově více méně to samé.

vámi popisované problémy neexistují / nikdo jiný se s nimi nikdy nesetkal

Pokud to neznáte vy, tak je to vaše věc, ale při tvrzení, že nikdo a nikdy a neexistuje si myslím že jste trochu ujel.

Když jste měl na sálovém počítači jasně vymezené svoje okénko, musel jste mít sadu děrných štítků integrovanou a otestovanou před jeho začátkem. Když tam byla chyba, měl jste prostě smůlu a přidělený čas nijak nevyužil. Od té doby cena za chybu během vývoje neustále zlevňuje, tj. jsou stále nižší požadavky na to, aby kód byl bezchybný v libovolném stadiu vývoje. Vy ale vycházíte z toho, že minima ceny už se dosáhlo a směr se obrátil – kdy k tomu podle vás došlo?

Cena za chybu se nezlevňuje. Cena za chybu je funkce silně závislá na čase mezi jejím vyrobením a opravením. A s tím časem lze pracovat. V dobách štítků to bylo dlouho pro ty důvody které popisujete. A ještě dnes je např. rozdíl mezi tím, když si spustíte kompilaci z příkazové řádky a čekáte na zapomenuté středníky, a tím když to IDE automaticky podtrhne červeně. Programátor pracující s IDE opraví syntaktickou chybu rychleji než programátor pracující s editorem a překladačem. Aplikací stejného principu týmy pracující s CI opraví chyby v programu rychleji než týmy pracující s feature větvemi.

Tvůj úžasný přístup (a tvůj proto, že ho tady nikdo jiný nehájí)

Což mě nepřekvapuje a nevadí mi to.

Normální přístup s DVCS: několik lidí něco vyvíjí po dobu T1 (každý svoje, zpřístupní to ostatním, ale nenutí jim to tlačením do master větve.) Pak mají hotovo, tak se to spojí a čas T2 se tráví integrací a testováním.

Rozdělit čas na T1 vývoj a T2 testování znamená že do konce T2 nebudu vědět jestli práce v T1 za něco stojí. Co když na začátku T1 udělám chybný předpoklad a na tom postavím celou další práci? To je extrémní případ, ale ukazuje, jak je důležité odhalit co nejvíc problémů co nejdřív.

vyvíjíš, ejhle, bude polovina pracovní doby, honem začleňovat. Strávíš tedy čas integrací (+ testováním), začleníš, následně kolegové tráví čas reakcí na tvoje změny. Odpoledne přijdeš na to, že je v tom ranním kódu potřeba něco více či méně překopat. Čas trávený intergrací a testováním dopoledne je přinejmenším zčásti ztracený - jak tvůj, tak tvých kolegů, všichni jste pracovali kvůli kódu, který ve výsledném SW vůbec nebude.

Výhoda toho "mého" přístupu je, že eliminuje všechy složky, které vám běžně působí problém. A sice "ejhle", "honem", "trávíš čas" (ve smyslu čekáš/vyčerpáváš se) a "překopat". A to právě proto, že je to nastavené tak, aby se tyhle věci nestihly vyvinout a nabobtnat.

Opravdu si myslíš, že i s takovým vyhazováním času z okna budeš schopen dodat funkční výsledek za dobu menší než T1 + T2? To sotva. O tom, že master větev bude vypadat, jako by na ní pracovala banda prasopsů, ani nemluvím.

Ano čas je kratší, výsledek je funkční (opravdu funkční) a master větev obsahuje až na silné výjimky jen přechody z jednoho zeleného stavu do druhého. A zelený stav znamená, že všechno funguje od začátku až do konce.

Jen tak mimochodem, pochlubíš se nám, která firma se užíví takto úžasným způsobem práce?

Citace z isbn 0596527679:

CHAPTER 1 Why Agile? Agile development is popular. All the cool kids are doing it: Google, Yahoo, Symantec, Microsoft, and the list goes on.