Aktywne Wpisy
CalibraTeam +109
Ceny mieszkań (czy innych nieruchomości) kosmiczne, ceny samochodów nowych kosmiczne (a ceny używanych chore). Czy też macie wrażenie, że wszyscy dookoła zarabiają po 15, 20k na rękę a tylko Wy jesteście robieni w bambuko?
Jako kawaler 7.5k zł na rękę czuję się jak śmieć i żul, biedak, którego na nic nie stać.
#gorzkiezale #zarobki #pytanie #pracbaza #praca
Jako kawaler 7.5k zł na rękę czuję się jak śmieć i żul, biedak, którego na nic nie stać.
#gorzkiezale #zarobki #pytanie #pracbaza #praca
#zdrowie #pytaniedoeksperta zanim pójdę do lekarza warto zapytać na wykopie 😉, wie ktoś czym są te czerwone plamy, suche i delikatnie swędzi, robi się tez małe pęcherzyki. Moze ktoś polecić jakiąś maść? Druga ręka Ok
Jak macie dużego taska do zrobienia, to jak to robicie?
Przykładowo task: "Dodawanie wpisów na mikroblogu".
Na pewno nie zrobicie jednego ogromnego commita, tylko podzielicie to na mniejsze części np.:
- "proste dodawanie wpisów",
- "dodanie możliwości formatowania wpisów",
- "załączanie zdjęć do wpisów (z pliku)",
- "załączanie zdjęć do wpisów z adresu URL".
Na #gerrit ( #java znają) było tak, że robiło się powiązane commity i po kolei robiło się code review (autor robił poprawki poszczególnych commitów przez amend) i wchodziły po kolei poszczególne commity.
Ale teraz robi się pull/merge requesty. Jak teraz do tego się podchodzi?
Wrzucić wszystko w jednego merge requesta?
To bardzo duża zmiana do zrobienia code review naraz i będzie długo trwało zanim wejdzie. A może ktoś by chciał już z części skorzystać. Są inne taki, które inne osoby mogłyby robić np.:
- "Powiadomienia po dodaniu komentarzy" (potrzebny przynajmniej commit: "proste dodawanie wpisów"),
- "Edytor zdjęć przy ich dodawaniu" (potrzebne 3 commity aż do "załączanie zdjęć do wpisów (z pliku)").
Poprzednie commity mogłyby wcześniej wejść, ale np. ten ostatni utknie w code review (bo będzie z nim dużo błędów) i cały merge request nie będzie zmergowany, więc przez ten cały czas nikt nie może wziąć kolejnego taska.
A może powinno się każdego takiego commita wrzucić w osobne merge requesty?
Tylko jak zrobię pierwszego commita i tylko z niego zrobię merge requesta, to jak mam dalej pracować? (Zanim wejdzie ten merge request, bo trwa code review.)
Kolejny merge request to musi być kolejny branch (muszę wyjść z tego mojego brancha, który jest jeszcze w code review). Jak powiązać tego pull requesta z poprzednim? Bo przecież jak założę nowego pull requesta z tego drugiego brancha, to będę miał tam dwa commity (bo poprzedni jeszcze nie wszedł). Jak zablokować, żeby ktoś przypadkiem nie zmergował tego przed tamtym?
I co z poprawkami do tego poprzedniego? Jak zrobię na tym pierwszym to jak zaktualizować na kolejne branche? Przy takim jednym tasku będę miał 4 branche, co mocno komplikuje.
Traktuj pull request jako jedną zmianę, która coś konkretnego wprowadza. A jaka jest strategia przy merge, to jest do wybrania (możesz zrobić squash i skutek będzie podobny jak w gerricie).
Zadania nie powinny miec wagi wiekszej niz 3 co oznacza ze jest sie w stanie zrobic to ponizej pol dnia roboczego. Wszystko powyzej 3 powinno byc zdekomponowane na mniejsze taski i
@globalbus: nie no task jest na tyle mały, że robi się go np. 2 dni (w sprincie masz np. 3 takie taski). Na mniejsze już ciężko podzielić (bo wtedy koszty planowania byłyby większe niż developmentu - developerzy sami ogarniają co z danego taska da się wyciągnąć, żeby innym ułatwić pracę).
Tylko jak np. 6h piszesz kod, to chciałbyś zrobić z tego osobnego commita. Żeby potem ktoś
Wolę większe PR, ale spójne, bez robienia 20 mikropierdnięć. Tutaj zachodzi jeszcze patologia w niektórych zespołach, czyli biznes zatwierdzający
Chyba że mogę cię pomęczyć ;)
Kto wtedy robi dekompozycję? Sami developerzy? Wraca do PM-a? Architekt?
Super, bo długo nie wisi na code review i ludzie mają czas
@globalbus: no a przykładowo model danych? Albo jakieś wspólne części (np. uprawnienia, utile np. do zapisu gdzieś np. dysk/API)?
Ktoś zaczyna swojego taska i musi pod to coś przygotować. I wiele osób potrzebuje tego (lub części). Dwa wyjścia:
- osobny task z zadaniem "technicznym"/szkieletem,
- każdy w swoim tasku robi to samo na początek i potem
@digupherbones: a jak ktoś ma zrobić poprawki w swoim commicie na CR to jak to robi?
- poprawki do commita i zrobienie amenda?
- w danym MR nowy commit z poprawkami?
Jak potem nakładasz te zmiany na swoje? Robisz pulla na czyimś branchu i potem zwykły merge na swojego? Nie ma problemów z
jak sie tego nauczyć? Wypracowaliśmy to z zespołem bo nam tak wygodnie. PO jest byłym technicznym. na ogol on dekomponuje taski.
Czasem jest cały rys biznesowy zadania to w tedy team leader robi dekompozycje i ustala wagi. a czasem zwykli devowie jezeli maja odpowiednia wiedze w danym obszarze biznesu.
Tak.mamy jedno zbiorcze issue. Gitlab ma flagi. za pomocą flag oprocz obszarow biznesowych mozna ustalic priorytety. my
Z mojej strony mogę polecić praktykę "steruj wszystkim konfiguracją", czyli feature-switcher. To pozwala trzymać się środowiskom niedaleko od mastera. Jak już ma finalnie zmiana wejść na środowisko, przestawiasz flagę, a potem usuwasz stary niepotrzebny kod. To upraszcza życie, zwłaszcza z niestabilnym emocjonalnie biznesem "wchodzimy/nie wchodzimy/dziś/jutro/zaraz"
@Hipodups: @globalbus: tak, też to mamy. Albo w konfiguracji albo nawet admin po REST lub JMX może w działającej aplikacji przestawić. Przydaje się jak coś się wdroży na produkcję i okazuje się, że nie działa jak powinno. Można szybko wyłączyć i nawet nikt nie zauważy ;) Testy na produkcji najlepsze :D
kiedyś były wdrożenia o jakiś dzikich porach, to wyłączało się połowę serwerów, wgrywało im nową wersję, a o wyznaczonej porze tylko przestawiało loadbalancing.
na froncie mozemy sobie wyklikać okresy w których feature jest dostępny, oraz role lub uzytkowny ktorzy mają dostęp.
Awaryjnie wyłączyć mozna poprzez flage w db.
No nigdy sie nie wytestuje na 100% wiec mozna wylaczyc awaryjnie, a glowna zaleta ze kod jest wydawany a nie trzymany w repo na akceptację.
Tak jak piszesz, albo na bieżąco domergowanie poprawek z bazowego brancha, albo później całego developu, jeśli tamten już został wpuszczony. Ogółem nie mamy jakiegoś dużego zespołu i też raczej wszyscy ze
Komentarz usunięty przez autora