+1, koszi
Tenyleg erdekel, hogy milyen toolsettel lehet trunk based developmentet kenyelmesse es biztonsagossa tenni; aztan meg a vegen meg is gyozodhetek az ervek sulya alatt.
Szerk: na jo, csak hogy beinduljon a szal konstruktiv resze is :)
Trunk based development ellen szoktak felhozni (koztuk en is), hogy nehezze / lehetetlenne teszi a code review-t. Ugye ha nincs branch/fork akkor nincs merge/pull request, nincs code diff, stb, stb.
Erre a megoldas a TBD fele hajlok szerint a pair programming/mobbing, ami teljesen jogos is, es mukodik. Egyszerre ket ember dolgozik ugyanazon a gepen ugyanazon a kodon, periodikusan cserelgetve, hogy ki gepel es ki vezet, minketten kontextusban vannak, stb, stb. En ezt el is fogadom, hogy ilyen helyeken a TBD mukodhet, es jol mukodhet. A problemam ket dologgal van:
- azert egy feature elesitese elott jo atnezni meg egyszer a modositasokat, megvan-e minden, tesztek megvannak-e, config is frissitve lett-e stb. Illetve a pair programming ugyan baromi jo, de azert igy se art, ha egy harmadik fel is vegig megy a kodon. Kevesebb dolga lesz, de azert neha akad.
- nem mindenki szeret pairelni / mobolni. En azt vettem eszre magamon, hogy ha pair-elni kell, akkor altalaban hagyom a business logic kitalalasat a paromra, es inkabb csak kijavitgatom / segitek neki. Ez abbol fakad, hogy ha nem tudok a sajat tempomban, a sajat logikam alapjan, a sajat megszakitasaimmal gondolkozni egy adott dolgon, akkor az nyilvan nehezebb; es ha van ott valaki mas, aki szinten gondolkodik, akkor minek duplikaljunk effortot :) Oke, nem ennyire veszes a helyzet, de pairing eseten vagy fel kell keszulni elore (es akkor meg mar egyedul is megoldhattam volna), vagy pedig potencialisan diszkomfortot okoz.
Persze nem muszaj folyamatosan pair-elni, lehet napi 2-3 orat is, esetleg ad-hoc ("gyere, segitsel mar legyszi...!"), na de akkor meg ott van a context switch.
Nyilvan, a pairingnek szamos elonye van, knowledge sharing / manyeyeballs / folyamatosan jelenlevo gumikacsa, de eszre kell venni a hatranyokat is. Ha a csapattagok szeretnek egyedul (is) dolgozni, akkor a pair programming nem tudja helyettesiteni a code review-t, szoval mindenkepp kell egy ideiglenes tarolo a felkesz kodnak, ha a nap vegen mindenki commitolni akar.