[rolling_stone_with_no_hope]

#programista15k

Mam pytanie dotyczące zmian w tym samym module, funkcjonalności czy jakiejkolwiek wspólnej "jednostce" kodu.
Jestem w projekcie z innym kolegą i wyszło, że mamy tickety na zrobienie funkcjonalności, które będą pisane w jednym pakiecie coś w stylu: on ma wysyłkę paczki do krajów UE, a ja poza UE i wymagania są inne. Jest to porozbijane, ale wrzucamy kod i #!$%@? mać #!$%@? merge conflicty rozwiązuję potem pół dnia. A potem on coś zrefaktoryzuje i znowu w koło Macieju.

Powoduje to paraliż i pytanie jak to można rozwiązać, czy jest jakieś wyjście wynikające z warsztatu programistycznego czy trzeba powiedzieć managementowi, że się nie da tego robić równolegle i #!$%@??

[JanPawelDrugiLechWalesaPierwszy]

@rolling_stone_with_no_hope: wrzucajcie częściej zmiany. A przede wszystkim rozmawiajcie o zmianach jakie robicie.

[relationbrewingarea]

@rolling_stone_with_no_hope na jednym branchu działacie?

[zibizz1]

@rolling_stone_with_no_hope:

1. Staracie sie robic zadania w innym czasie
2. Minimalizujecie konflikty np dodając kod w nowej klasie i potem tylko integrujecie z resztą. Najpierw jeden potem drugi

[BeginEnd]

@rolling_stone_with_no_hope: Siadacie, zmużdżacie się co trzeba zrobić i jak to ogarnąć: jakie API, jakie zmiany będą potrzebne itp itd. Oczywiście z grubsza bo pewnie i tak czegoś nie przewidzicie. Potem dzielicie to na jak najmniejsze taski, które jak najmniej kolidują ze sobą. Potem tworzycie branch z głównej gałęzi nazwijmy go ficzer/AiB. Z tego brancha robicie kolejne brancze ficzer/A oraz ficzer/B. Zaczynacie robotę w ten sposób, że jedna osoba wrzuca

[rolling_stone_with_no_hope]

@BeginEnd: konkretnie i wyczerpująco. Chyba wniosek jest prosty, robić mniejsze subtaski i merge. W moim kołchozie problemem jest wymóg testów manualnych przez co to nadal może być paraliżujące