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

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?

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ę.

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.

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.

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.

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ł.

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.

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 !!

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.

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ł.

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ą :)

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).

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ą.

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.

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ę ^ _ ^

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.

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?