Czy programista powinien naprawić nieudaną kompilację? [Zamknięte]

45

Jeden programista zlecił trochę pracy repozytorium SVN, a następnie poszedł do domu. Po jego odejściu automatyczna kompilacja Hudsona nie powiodła się. Inny programista to zauważył i po przejrzeniu zmian w kodzie wykrył, że problemem był brak jednej biblioteki. Dodał tę bibliotekę do SVN i następna kompilacja zakończyła się powodzeniem.

Czy drugi programista postąpił właściwie, czy powinien po prostu poczekać, aż pierwszy programista naprawi problem?

nahab
źródło
31
Pytanie: Jeden członek programisty zadał pytanie. Inny członek przeczytał pytanie i zobaczył kilka błędów składniowych i gramatycznych, więc postanowił edytować pytanie i poprawić je, aby pytanie było nieco łatwiejsze do odczytania. Czy redaktor postąpił właściwie, czy powinien tylko poczekać, aż plakat naprawi błędy?
yannis,
2
Jakie są zasady twojego zespołu w tej sytuacji?
4
@ anhab Och, nie martw się, nie mówię, że to problem :). Tylko w społeczności, podobnie jak w zespole, członkowie powinni pomagać sobie nawzajem. Nie sądzę też, aby deweloper łamający kompilację był nieprofesjonalny, nawet jeśli w przypadku drobnego błędu, takie rzeczy przytrafiają się nam najlepiej.
yannis,
11
Cała idea posiadania Hudsona polega przede wszystkim na tym, że ludzie są ludźmi i od czasu do czasu psują kompilację. Po prostu chcesz to wcześnie złapać. Można argumentować, że programista powinien był sprawdzić, czy kompilacja została zbudowana przed powrotem do domu.
14
Jest to o wiele łatwiejsze do zrozumienia, jeśli weźmiesz pod uwagę odwrotność - jeśli kompilacja jest zepsuta, spowalnia cały zespół (nawet w domu, po godzinach) i możesz to naprawić, ale dokonaj świadomego wyboru, aby nie z powodu pewnego punktu procedury , czy powinieneś mieć pozwolenie na utrzymanie pracy?
Bill K

Odpowiedzi:

87

Zależy to w pewnym stopniu od tego, jak zwykle pracuje twój zespół, ale powiedziałbym, że było dobrze. Utrzymanie działania kompilacji oszczędza czas wszystkim innym.

Drugi programista upuszcza pierwszy e-mail z wyjaśnieniem, co zrobił, na wypadek, gdyby potrzebna była konkretna wersja biblioteki lub inna komplikacja. Jest to również nieco bardziej subtelny sposób na wskazanie, że złamali kompilację.

Luke Graham
źródło
101
grzeczne jest również to, że pierwszy programista kupił pączki, aby nadrobić zaległości w kompilacji
jk.
17
Wolałbym piwo niż pączki.
Martin York,
2
Pączki mogą być obraźliwe dla nietolerancji glutenu. Z drugiej strony karty upominkowe o wartości 5 USD do Best Buy ...
Christopher Mahan
1
@ChristopherMahan albo doprowadziłby do walki między wszystkimi członkami zespołu o to, kto ją otrzyma; lub jeśli dany jeden członek zespołu, jak niejawna dystrybucja z pudełka z pączkami w pokoju przerw, jest znacznie droższą propozycją. W każdym razie karta podarunkowa Best Buy może być obraźliwa dla każdego, kto pracował dla Circuit City lub CompUSA. :)
Dan Neely,
1
Co można uzyskać w Best Buy za mniej niż 5 USD?
kevin cline
12

To zależy.

  • Czy błąd jest tak oczywisty, że dodanie biblioteki jest sposobem na jego naprawienie? Czasami poprawka polega na znalezieniu obejścia, które nie wymaga tej biblioteki.

  • Czy projekt jest w fazie, w której wszystkie zmiany muszą być powiązane z istniejącym biletem? Jeśli tak, czy złożyłeś bilet? Czy ten bilet został Ci przypisany?

W każdym razie skup się na naprawie błędu, a nie na obwinianiu odpowiedzialnego.

mouviciel
źródło
9
„... nie obwinianie odpowiedzialnych.” Chyba że jest to normalne zjawisko.
Shawn D.,
11

Tak, w porządku. Jednak nieprofesjonalne jest, aby oryginalny programista poszedł do domu przed przetestowaniem, czy kompilacja się skompiluje.

Twoja reputacja jest w 100% pod twoją kontrolą. Takie rzeczy szkodzą twojej reputacji, a próba polerowania zniszczonej reputacji jest bardzo trudna.

Michael Riley - AKA Gunny
źródło
2
+1 za umieszczenie ciężaru na pierwszym deweloperze, który przetestuje wersję. Drugi akapit naprawdę nie jest prawdziwy ani istotny. Inne osoby mogą zaszkodzić Twojej reputacji, umyślnie lub nie, nawet jeśli twoje zachowanie jest całkowicie nie do zniesienia.
Caleb,
6
Jest całkiem możliwe, że oryginalny programista miał bibliotekę na swoim komputerze, ale maszyna wykonująca automatyczną kompilację nie. Tak, biblioteka powinna znajdować się w SVN, ale może to być bardzo subtelny problem, którego nawet nie zauważam.
mpdonadio
7

Komunikować się

W tym scenariuszu nie ma ścisłych zasad (oprócz reguł własnego zespołu).

Dev2 powinien być w stanie powiedzieć dev1, że może naprawić swój błąd, żaden z nich nie powinien obawiać się czegoś wynikającego z tej wymiany, są częścią zespołu.

xsace
źródło
5

Dlaczego nie? Jeśli twój produkt jest ważniejszy niż naprawianie winy, z pewnością jest w porządku. Chociaż kompilacja kończy się niepowodzeniem z powodu zmiany biblioteki, jest dość kiepska i musisz upomnieć programistę, aby go nie testował.

DPD
źródło
3

Zdarzają się awarie kompilacji. Jeśli ważne jest, aby codzienna kompilacja się zdarzyła, naprawiłbym to, a następnie poprosiłem programistę, który sprawdził uszkodzony kod, aby przejrzał poprawkę następnego dnia i upewnił się, że kod jest teraz taki, jak powinien.

Jak już powiedziano, facet, który go naprawił, powinien prawdopodobnie wysłać e-maila do faceta, który go złamał, i opisać, co to za poprawka.

AndyC
źródło
2

Moje motto brzmi: nie zatwierdzaj SVN po godzinie 15, w ten sposób zawsze możesz naprawić własne błędy kompilacji.

Jeśli nie naprawisz niepowodzenia kompilacji, kompilacja wszystkich innych również się nie powiedzie. Naprawiłbym to, aby zaoszczędzić czas na dłuższą metę, ale upewnij się, że są świadomi, że musiałeś to naprawić.

Posiadanie jakiegoś skryptu „wskaż winę” to dobry sposób, aby to zrobić, lub spraw, aby osoba, która łamie kompilację, kupowała pączki !!

luketorjussen
źródło
2
Nasze narzędzie CI ma opcję wysyłania wiadomości e-mail do programisty, który złamał kompilację (oprócz reszty zespołu).
TMN
2

Ktoś musi to naprawić, a pierwszy programista nie powinien był wracać do domu bez upewnienia się, że nie złamał kompilacji. Jednak w przypadku tak łatwego do rozwiązania problemu wezwanie go z powrotem do samodzielnego rozwiązania byłoby ekstremalne.

Zgadzam się z sugestią Luke'a Grahama dotyczącą wysłania e-maila wyjaśniającego, chociaż powiedziałbym, że to więcej niż grzeczność - to podstawowa komunikacja.

Alex Dalziel
źródło
W przypadku kompilacji integracyjnych czasami trwających godzinę lub dłużej, w zależności od złożoności systemu, należy codziennie wprowadzać „cut cutoff”, aby mieć pewność, że ostatnia kompilacja dnia nastąpi, gdy wszyscy będą w pobliżu. Nawet wtedy ludzie są umówieni na wizytę u lekarza, na trening piłki nożnej dla dzieci itp. I muszą natychmiast się wycofać, niezależnie od statusu budowy. Agile twierdzi, że praca powinna przebiegać w zrównoważonym tempie i nie powinna obciążać pracowników. Trzymanie ich tam do godziny 8:00, aby zobaczyć sukces kompilacji, jest sprzeczne z tym.
KeithS,
@KeithS: True. Ale odkryłem, że bez względu na to, kiedy wychodzę, najbardziej prawdopodobny czas na przerwanie kompilacji to pośpiech: tuż przed lunchem, tuż przed spotkaniem, tuż przed końcem dnia. Dlatego uważam, że „osobistą najlepszą praktyką” jest niepodawanie niczego, gdy nie ma wystarczająco dużo czasu, aby obejrzeć i naprawić kompilację później.
Daniel Pryden,
2

Tak tak tak! Sprzyja to zbiorowemu posiadaniu kodu i stanowi rodzaj zdrowej presji ze strony zespołu, aby utrzymać wysoki standard i nie pozwolić na rozwój scenariusza rozbicia okna. Trochę komunikacji, aby poinformować drugiego programistę, to dobry pomysł.

Peter Kelly
źródło
2

Myślę, że poprawianie oczywistych rzeczy jest OK - tzn. Jeśli masz 100% pewności, że facet, którego kod naprawisz, zrobiłby to samo - lub zasadniczo takie samo - naprawienie. Jeśli poprawka jest bardziej złożona, zwykle uprzejmie jest porozmawiać z osobą, której kod się naprawia - być może źle zrozumiałeś zamiar lub przyczyną złamania nie jest to, co myślałeś, lub może zamierzał inną poprawkę ale z jakiegoś powodu nie mogłem tego jeszcze zrobić (życie się dzieje, wiesz :).

Ogólnie rzecz biorąc, reguła zwykle brzmi: przerywasz kompilację - naprawiasz kompilację, ale są wyjątki, szczególnie jeśli poprawka jest oczywista i / lub osoba odpowiedzialna jest nieosiągalna.

Oczywiście, jeśli masz przypadek seryjnego przerywacza kompilacji - szczególnie ze wzorem „zalogowany, poszedł do domu, kompilacja zepsuta przez kilka dni” - osoba odpowiedzialna musi porozmawiać o tym, dlaczego istnieją systemy i testy CI oraz jak należy sprawdź przed odprawą :)

StasM
źródło
1

Rzeczy się zdarzają. Brak dodania nowego pliku kodu (źródłowego lub skompilowanego) do Subversion jest prawdopodobnie najczęstszą przyczyną uszkodzonych kompilacji, zakładając, że działał on na komputerze programisty. W mojej ostatniej pracy w środowisku CI nawet najbardziej starsi faceci czasami zapominali.

Myślę, że jeśli inna osoba była w stanie naprawić kompilację i dzięki temu ekipa szeptała dalej, to w porządku. Myślę, że programista, który poszedł do domu, potrzebuje przynajmniej przyjaznego e-maila z informacją o tym, co się stało, i przypomnienia mu, aby upewnić się, że nowy kod zostanie dodany przed zatwierdzeniem. Jeśli zdarza się to często, może sprawić, że drobne przestępstwo zostanie ukarane „tańcem wstydu”, aby zmniejszyć liczbę wystąpień (i złagodzić nastrój).

KeithS
źródło
1

Zależy to od dynamiki zespołu, ale w idealnym świecie każdy w zespole „posiadałby” cały projekt, cały kod, aw konsekwencji wszystkie błędy łącznie. Więc jeśli znajdziesz problem, napraw go i komunikuj się z twórcą błędu tylko wtedy, gdy kod ma jakąś konkretną wartość dodaną.

Dave
źródło
0

Można to naprawić, chyba że jest to normalne zjawisko, w którym to przypadku kazałbym szefowi zadzwonić do niego i sprawić, by wrócił i naprawił to sam.

HLGEM
źródło
0

To zależy, zależy ...

Jako programiści naszą pracą jest sprawianie, aby rzeczy działały, a nie ocenianie ludzi. Powiedziałbym więc, że najlepszą rzeczą, jaką możesz zrobić, to naprawić, a jeśli nie jest to oczywiste, po prostu wycofaj zmiany i daj pierwszemu programistowi znać, aby mógł to naprawić później.

W każdym razie wystarczy mieć najnowszego faceta, który złamał kompilację i założył dziwny kapelusz, aby następnym razem zwrócić większą uwagę ^ _ ^

fortran
źródło
0

W niektórych środowiskach jest to bardzo niegrzeczne i nie bez powodu. W innych środowiskach jest to oczekiwane i nie bez powodu.

W jeszcze innych środowiskach jest to bardzo niegrzeczne lub oczekiwane z bardzo złych powodów.

W dużej mierze zależy to od tego, jak krytyczna jest zepsuta kompilacja, od tego, jak krytyczna jest zweryfikowana poprawna kompilacja. I do pewnego stopnia zależy to od tego, jak oczywiste było, że poprawka była poprawna i jedyna potrzebna.

David Schwartz
źródło
0

Po pierwsze, „poszedł do domu” to anachronizm. Programiści nie wracają już do domu - są po prostu online lub offline. Możesz pingować i czekać.

Co ważniejsze, pytanie składa się z dwóch części. „przeglądanie zmian w kodzie” jest w porządku; reszta może być niewłaściwa. Co jeśli jego ocena zaginionej biblioteki była błędna?

Kris
źródło