[s.....a]

wiesz że pracujesz w dużej firmie jeżeli ten kawałek basha ma sens ( ͡° ͜ʖ ͡°)

while true; do git pull --rebase && git push && break; done;

#programowanie

[GlenPL]

@sakfa: #nieprogramowanie

[s.....a]

@GlenPL: możesz rozwinąć czemu nieprogramowanie?

albo inaczej - są gdzieś spisane zasady którego tagu kiedy używać czy wszystko leci na czuja?

[Vetinari]

@sakfa: Ten kawałek basha ma sens jak pracujesz nad tak prostym kodem, że nie będziesz miał żadnego konfliku.

[krecikBMC]

@sakfa: Force push ;)

[s.....a]

@Vetinari: jak się robi małe commity i projekt jest podzielony na moduły to konflikty są rzadkością (no chyba że to Java i 1 rename potrafi przeorać pół projektu). W każdym razie 'prosty' to ostatnie słowo trafnie opisujące mój projekt a konfliktów praktycznie nie mam

@krecikBMC: koledzy mogliby się obrazić ;)

[Vetinari]

@sakfa: A ile osób pracuje nad tym projektem jednocześnie?

[michalfranc]

@sakfa: Nie widze zwiazku miedzy Java a 1 renamem zmieniajacym pol projektu :) To raczej efekt spaghetti kodu ktory mozna poczyc w kazdej technologi.

[GlenPL]

@sakfa: na czuja, ale napisalem że to #nieprogramowanie bo to raczej #humorinformatykow

[Vetinari]

@GlenPL: To taki z Ciebie informatyka jak...

[s.....a]

@Vetinari: nie wiem, kilkaset, raczej nie więcej niż 500 - ale to wielkie repo w którym jest większość kodu deployowanego na wszystkie możliwe maszyny w organizacji, więc mała szansa że frontendowiec skonfliktuje się z kimś kto dłubnął jakiś raport na backendzie. Raczej nie zdarza się żeby 2 osoby pracowały nad tym samym fragmentem i o tym nie wiedziały, a jeżeli tak się stanie to wskazuje to na spory fuckup w komunikacji

[s.....a]

@GlenPL: to nie humor, to życie ;)

[s.....a]

@Vetinari: a w sumie zainspirowałeś mnie do sprawdzenia dokładnie - w czerwcu 300 unikalnych autorów, ale dziennie ok 60 a więc większość ludzi się #!$%@? i comituje raz na tydzień ;)

[n.....i]

@sakfa: #!$%@? workflow milordzie ;)

[dagon_666]

@sakfa: raczej, "wiesz, ze pracujesz w #!$%@? firmie"

[s.....a]

@dagon_666: to że firma jest duża nie znaczy że jest #!$%@? :) jak na skalę w której operujemy i ilość legacy code jaki jest do utrzymania i tak radzimy sobie całkiem nieźle (IMHO, no i wg giełdy). W każdym razie wydaje mi się że umiejętnie spłacamy technical debt tam gdzie trzeba i kiedy trzeba

@nnogi: zarzucisz jakiegoś linka do workflow które działa dobrze dla dużego repo? / duże - powiedzmy

[n.....i]

@sakfa: Poza tym, każdy workflow będzie #!$%@?, jeśli jest jeden śmietnik na wszystko :P

IMO pull requesty dobrze się sprawdzają. Co prawda wymaga to jednej osoby, która generalnie ogarnia cały temat (i wymusza trzymanie jakiegoś porządku, bo czyta te commity), ale u mnie jest to po prostu kierownik zespołu (15 osób).

[s.....a]

@nnogi: to się nie skaluje do kilkuset osób no i spowalnia pracę. A jeden śmietnik to świetna rzecz jak coś padnie, nie wiesz co ani dlaczego i szukasz winowajcy - git bisect i ognia

*winowajcy w sensie komita który coś rozwalił, nie osoby ;)

[n.....i]

@sakfa: No nie wiem, czy spowalnia. U mnie generalnie paru ludzi miało ból dupy, gdy ten workflow wchodził, ale potem nagle zaczęło się okazywać, że wymuszanie na ludziach pewnych standardów opłaciło się. Okazuje się, że nagle kod daje się w ogóle testować i jest czytelny, bisect stał się użyteczny i możesz przelecieć kod automatem bez zastanawiania się gdzie to się #!$%@?, bo commity nie są #!$%@?, a nawet napisaliśmy sobie narzędzie,

[s.....a]

@nnogi: siłą rzeczy jeżeli do workflow dodamy dodatkowy krok to się spowolni

Wymuszanie standardów kodowania raczej nie jest zgodne z naszą kulturą pracy, każdy pisze zgodnie z własnym zdrowym rozsądkiem ( i zasadą follow the style of file), to samo dotyczy testów które raczej są tylko tam gdzie są absolutnie niezbędne (np. ios gdzie zepsuty release to katastrofa którą ciężko odwrócić).

Dokumentacji i tak nikt by nie czytał no i byłaby

[n.....i]

siłą rzeczy jeżeli do workflow dodamy dodatkowy krok to się spowolni

@sakfa: Zgadza się, ale ustandaryzowany workflow umożliwił automatyzację pewnych rzeczy, które wcześniej robiliśmy ręcznie i niekiedy na partyzanta np. budowanie i testy. W efekcie możesz zrobić więcej w tym samym czasie, bo nie zajmujemy się kwestiami czysto technicznymi typu: trzeba postawić bazę do testów, kto ma to zrobić i gdzie? To już jest ustalone, oprogramowane i robi się samo.
Co