Podejrzewam, że skupiam się na niewłaściwym problemie, więc najpierw opiszę, o czym myślę, zanim przedstawię możliwe nieoptymalne rozwiązanie, które przewiduję.
Obecna sytuacja:
Obecnie moi współpracownicy dokonują zmian w kodzie dopiero po długim czasie w ogromnych porcjach, przy czym zmiany rozprzestrzeniają się w całym projekcie (ach). Sądzę, że to postęp, ponieważ jeszcze niedawno umieścili archiwa .zip w jakimś udziale sieciowym. Łączenie się to jednak koszmar - i szczerze mówiąc, mam tego dość. Mam też dość mówienia, wyjaśniania i błagania. To tylko musi się skończyć - beze mnie ciągle „złym facetem”.
Moje rozwiązanie:
Ponieważ wydaje się, że nie ma świadomości i / lub zainteresowania problemami i nie mogę się spodziewać, że jakieś wysiłki będą trwać dłużej niż kilka dni ... uderz w to, godzinami, chciałbym, aby serwer subversion wykonał dokuczliwy.
Moje pytanie:
czy jestem tutaj poza bazą, czy szukam niewłaściwego problemu? Wygląda na to, że coś mi umknęło i myślę, że pytam o coś niewłaściwego, szukając narzędzi do rozwiązania mojego problemu.
Czy powinienem szukać narzędzia do rozwiązania tego problemu lub co powinienem zrobić, aby to naprawić?
źródło
Odpowiedzi:
Szukasz technicznego rozwiązania ludzkiego problemu. To rzadko działa.
Powodem tego jest to, że jeśli członkowie zespołu czegoś nie zaakceptują (ani nie zrozumieją konsekwencji), zamiast przestrzegać zasad, spróbują je obejść. Właśnie dlatego, na przykład, programiści powinni zaakceptować i zrozumieć reguły stylu zamiast po prostu zmuszeni do przestrzegania przez kontrolera.
Oto kilka podejść, które albo stosowałem w przeszłości, albo miałem na myśli, nie mając okazji do nich w praktyce. Niektóre mogą nie mieć zastosowania do Twojej sprawy, w zależności od zajmowanego stanowiska w zespole (jeśli jesteś liderem zespołu o doskonałej reputacji, istnieje szansa, że będziesz mieć lepszą okazję do wyegzekwowania swojego stanowiska niż jeśli jesteś studentem, który właśnie dołączyłeś do zespołu na czas trwania stażu).
Omów ten problem ze współpracownikami i wyjaśnij konsekwencje dużych zobowiązań. Może po prostu nie rozumieją, że skomplikowane połączenia są bezpośrednią konsekwencją rzadkich zatwierdzeń, a następnie małe, częste zatwierdzenia ułatwią (względnie) łatwe połączenia.
Znałem wielu programistów, którzy byli po prostu przekonani, że fuzje są zawsze skomplikowane. Dokonali co najwyżej jednego zatwierdzenia dziennie, unikali używania potężnych narzędzi, takich jak diff i auto-scalanie Visual Studio, i mieli słabą praktykę ręcznego łączenia (chyba że „Zabierz moje” bez dalszej kontroli różnic jest w rzeczywistości dobrą praktyką). Dla nich nie miało to z nimi nic wspólnego i była nieodłączną cechą połączenia.
Podaj konkretne przykłady tego, co dzieje się w innych firmach (szczególnie tych, dla których twoi współpracownicy mają głęboki szacunek). Mogą po prostu nie zdawać sobie sprawy, że jest to problem i być przekonanym, że maksymalnie jeden zatwierdzenie dziennie jest tym, co robi każdy zespół.
Niektóre osoby nie zdają sobie sprawy z tego, że istnieją zespoły 5-10 członków, które wykonują do 50 wypychań do produkcji, co przekłada się na średnio 5-10 zatwierdzeń dziennie na osobę. Mogą nie rozumieć ani, jak to jest możliwe, ani dlaczego ktoś miałby to zrobić.
Dawaj dobry przykład. Zrób wystarczająco dużo małych zobowiązań. Jeśli to możliwe, wykonaj krótką prezentację pokazującą ich i twoje połączenia obok siebie w ciągu tygodnia (nie jestem pewien, czy wyodrębnienie tego rodzaju informacji jest łatwe z kontroli wersji). Podkreśl ewentualne błędy popełnione podczas ich łączenia i porównaj je z liczbą błędów, które popełniłeś (które powinny być bliskie zeru).
Użyj „ja mówiłem” techniki, w stosownych przypadkach . Kiedy zobaczysz, że twoi koledzy cierpią z powodu bolesnego scalenia, głośno komentuj, że małe, częste zatwierdzenia mogą sprawić, że scalenia (względnie) będą bezbolesne.
Wyjaśnij, że nie ma minimalnego czasu trwania do zatwierdzenia. Zatwierdzenie może nawet odpowiadać drobnej zmianie dokonanej w ciągu kilku sekund. Zmiana nazwy pliku, usuwanie przestarzałego komentarza, poprawianie literówki to wszystkie zadania, które można wykonać natychmiast.
Programiści nie powinni obawiać się wykonania małego zatwierdzenia, a raczej agregacji wielu zmian w jednym wielkim zatwierdzeniu.
W razie potrzeby pracuj z osobami zamiast z zespołem. Jeśli jest osoba, która szczególnie odmawia częstych, drobnych zobowiązań, porozmawiaj z tą osobą indywidualnie, aby zobaczyć, dlaczego odmawia.
Mogą podać całkowicie uzasadnione powody, które mogą dać ci wskazówkę o tym, co dzieje się z zespołem. Niektóre powody, dla których słyszałem:
„Mój nauczyciel / mentor powiedział mi, że najlepszą praktyką jest wykonywanie jednego zobowiązania dziennie”. Nie dziwi mnie to, biorąc pod uwagę to , co musiałem usłyszeć od moich nauczycieli na studiach .
„Moi koledzy powiedzieli mi, że powinienem robić mniej zobowiązań”. Powiedziano mi to również w niektórych zespołach i rozumiem ich punkt widzenia. Mieliśmy dziennik, który był praktycznie wypełniony moimi zobowiązaniami (nie jest to trudne, gdy czterech członków drużyny nawet nie robi jednego dnia dziennie), co frustrowało moich współpracowników.
„Myślałem, że małe zatwierdzenia utrudniają znalezienie poprawki”. W pewnym sensie słuszny punkt, nawet gdy zespół wkłada wysiłek w pisanie opisowych komunikatów dziennika.
„Nie chcę marnować zbyt wiele miejsca na naszym serwerze kontroli wersji”. Osoba oczywiście nie rozumie, w jaki sposób zapisywane są zatwierdzenia (ani jak tanie jest miejsce do przechowywania).
„Myślę, że zatwierdzenie powinno odpowiadać konkretnemu zadaniu.” Biorąc pod uwagę, że często zadanie odpowiada pewnej pracy do wykonania w ciągu jednego dnia (np. Na tablicach zadań zarządzania wizualnego), nie jest to przypadek. Osoba powinna następnie nauczyć się różnicować zadanie w zaległości (od 2 do 8 godzin pracy) od logicznie izolowanej zmiany, którą należy wprowadzić (od kilku sekund do kilku godzin pracy). Jest to również związane z pkt 5.
Wyszukaj powód, dla którego zespół nie częściej popełnia zatwierdzeń. Możesz być zaskoczony wynikami.
Niedawno wspomniałem w innej odpowiedzi, że szybkość zatwierdzenia ma znaczenie, a nawet setki milisekund mogą skłaniać programistów do dokonywania rzadziej.
Inne powody mogą obejmować:
Zbyt skomplikowane reguły pisania komunikatu zatwierdzenia.
Reguła, która zmusza programistę do połączenia zatwierdzenia z zadaniem z systemu śledzenia błędów.
Strach przed zerwaniem kompilacji.
Niechęć do poradzenia sobie z ryzykiem złamania kompilacji już teraz: jeśli wykonasz zatwierdzenie w piątek wieczorem tuż przed odejściem, możesz odłożyć postępowanie z uszkodzoną kompilacją do poniedziałku.
Strach przed połączeniem.
Sprawdź, czy programiści rozumieją, że często występują inne korzyści . Na przykład platforma Continuous Integration stanowi ogromną zachętę do częstych zatwierdzeń , ponieważ pozwala dokładnie wskazać, gdzie regresja została wprowadzona .
Wolałbym, żeby platforma CI mówiła mi, że zepsułem kompilację w wersji 5023, która polega na zmianie dwóch metod w jednym pliku, co zrobiłem piętnaście minut temu, niż w wersji 5023, składającej się ze zmian obejmujących cztery tuziny plików i reprezentujących 13 godzin pracy.
źródło
Organizacja, z którą współpracowałem w przeszłości, chciała rozwiązać ten sam problem i opracowała dość dobre rozwiązanie społecznościowe: programiści nie mają własnych komputerów. ZESPÓŁ ds. Rozwoju ma komputery, ale każdy może zostać poproszony o pracę na dowolnym komputerze programistycznym w danym dniu. Odprawa jest więc jedynym sposobem, aby upewnić się, że możesz kontynuować pracę nad tym, co robiłeś wczoraj!
Następnie kierownictwo obejrzało się i potajemnie cofnęło zmiany na komputerach po godzinach, aby wszystko, co nie zostało zarejestrowane, zostało utracone. Te „symulowane awarie komputera” musiały wystąpić kilka razy, zanim deweloperzy weszli na pokład.
Oczywiście ważne jest, aby wyjaśnić „dlaczego” zasad, a także „co”. O ile nie wyjaśniono „dlaczego”, mogliby po prostu zapisać swoje źródło na dyskach USB lub coś w tym rodzaju.
źródło