Administrace komentářů

Když potřebuješ něco zásadnějšího, tak to za den ani náhodou nedostaneš do funkčního stavu, abys mohl komitovat do masteru.

Ne, ne, ne a ne. Je to jen o pořadí činností, navrhnout to tak, aby v každém kroku projekt stál oběma nohama na zemi. Vidět znamená věřit, takže příklad. Zásadní změna - přechod na jinou db. Dělali jsme to měsíc (výzkum) a dva týdny (realizace). Ani jeden den nebyl na konci dne kód ve stavu, kdy by technicky nefungoval. Dělali jsme to v branchi, to přiznávám, ale ne proto, že by to byť jeden den nefungovalo.

Požadavek vznikl jako reakce na problém kde jsme optimalizovali rychlost dotazů. To byl ten měsíc. Měli jsme kopii db, udělali jsme si nový DAO objekt a nový modul který jen pustil tu query a vypsal čas dotazu na sysout. Žádná změna, kvůli které by master nefungoval (DAO objekt šel vždy aspoň přeložit). Měsíc jsme jen laborovali s tou query. Na konci snažení jsme to DAO vyčistili a ze sysout programu udělali normální test s assertama. Ani jedno z toho neovlivnilo funkci ostatního kódu v master branch.

Když už jsme měli tu query vypiplanou, tak jsme museli přejít na jinou db. Nejprv jsem v build skriptech udělal to, aby se nová db do instalačního procesu balila současně se starou. Žádná regrese. Pak jsem nechal novou db spouštět se starou. Žádná regrese. Pak jsem kód částečně nasměroval na nové DAO a ve starém jsem změnil adresu databáze. Žádná regrese. Pak jsem napsal dokument a pár malých skriptů pro migraci dat. (Automatická migrace nebyla v plánu, ale dala by se udělat stejným způsobem.) Žádná regrese. Pak jsem odstranil z build skriptů starou db. Konec. V každém kroku byl systém funkční, byť třeba neoptimálně (např. že v systému byly spuštěny najednou dvě db).

Ale nemyslete, ještě před rokem bych tuhle změnu dělal stylem: den 1, nevratná výměna staré db za novou. Další dva týdny - rozcházení nefunkčního kódu proti nové db. To by samozřejmě potřebovalo branch, a navíc bych byl pod tlakem udělat to co nejdříve, protože na tu změnu by jistě čekalo spousta jiných změn.

Navíc jak řešíš situace, kdy máš něco většího rozdělaného a přijde požadavek na urychlené vyřešení něčeho jiného, třeba do hodiny. To bez větví vůbec nejde.

Obvykle to nehoří natolik aby se to nedalo naplánovat až na zítra, kde začíná nové kolečko - ostatní tasky se tím odsunou, ale žádný nezůstane nedodělaný.

Pokud je to fakt potřeba udělat teď hned tak holt nezbejvá než činnost přerušit - lokálně si změny schovat do stashe, resetnout se na poslední bod v upstreamu a začít pracovat na té opravě. Druhý den se k tomu stashi vrátit. Může se dokonce i stát, že pak už nezbyde čas dodělat tu původní věc, pak je nejlepší ten stash vyhodit, protože s přibývajícím časem přestane být aktuální.