Standardy pracy programistów na własnych stacjach roboczych

Właśnie natrafiliśmy na jedną z tych sytuacji, która czasami pojawia się, gdy programista choruje przez kilka dni w połowie projektu.

Było kilka pytań na temat tego, czy popełnił najnowszą wersję swojego kodu, czy też na jego lokalnej maszynie było coś nowszego, na co powinniśmy spojrzeć, i czekaliśmy na dostawę do klienta, więc nie mogliśmy się doczekać go wrócić.

Jeden z innych programistów zalogował się jako on, aby zobaczyć bałagan obszarów roboczych, wiele z pozornie tych samych projektów, ze znacznikami czasu, które sprawiły, że nie było jasne, który z nich jest „aktualny” (prototypował kilka bitów na wersjach projektu innych niż jego „rdzeń”).

Oczywiście jest to ból w karku, jednak alternatywa (która wydaje się być ścisłymi standardami dla tego, jak każdy programista działa na własnej maszynie, aby zapewnić, że każdy inny programista może podnieść rzeczy przy minimalnym wysiłku) może złamać wiele programiści wykonują osobistą pracę i prowadzą do nieefektywności na poziomie indywidualnym.

Nie mówię o standardach dla zameldowanego kodu, ani nawet ogólnych standardach programistycznych, mówię o tym, jak programista działa lokalnie, domena ogólnie uważana (z mojego doświadczenia) za prawie całkowicie pod kontrolą programistów.

Jak radzisz sobie z takimi sytuacjami? Czy to jedna z tych rzeczy, które właśnie się zdarzają, z którymi musisz sobie poradzić, a mianowicie cena, jaką płacisz za programistom pozwolenie na pracę w sposób, który najlepiej im odpowiada?

A może prosi się deweloperów o przestrzeganie standardów w tej dziedzinie - korzystanie z określonych katalogów, standardów nazewnictwa, notatek na wiki lub cokolwiek innego? A jeśli tak, co obejmują twoje standardy, jak surowe są one, jak je nadzorujesz i tak dalej?

A może brakuje mi innego rozwiązania?

[Załóżmy ze względu na argument, że nie można skontaktować się z deweloperem, aby omówić to, co tutaj robił - nawet jeśli mógłby wiedzieć i opisać, który obszar roboczy, który z pamięci nie będzie prosty i bezbłędny, a czasami ludzie naprawdę mogą skontaktujemy się z Tobą i chciałbym znaleźć rozwiązanie, które obejmuje wszystkie ewentualności.]

Edycja: Rozumiem, że przechodzenie przez czyjąś stację roboczą jest złą formą (choć jest to interesujące - i prawdopodobnie nie na temat - pytanie, dlaczego tak jest dokładnie) i na pewno nie patrzę na nieograniczony dostęp. Pomyśl więcej zgodnie ze standardem, w którym ich katalogi kodu są skonfigurowane z udziałem tylko do odczytu - nic nie można zmienić, nic więcej nie można zobaczyć i tak dalej.

„ Jeśli nie ma kontroli źródła, nie istnieje ”.

Jest to jedna z niewielu rzeczy w naszym zawodzie, o których jestem pogranicznym dogmatykiem. Z następujących powodów:

1. Chociaż stacja robocza jest własnością firmy, spójrzmy prawdzie w oczy - istnieje niepisana zasada, że ​​własna stacja robocza programisty jest jego zamkiem. Jestem po prostu niespokojny z kulturą pracy, w której każdy może rutynowo się na nią zalogować i przejść przez to.
2. Każdy ma swój własny przepływ (tak jak powiedziałeś). Próba zmuszenia wszystkich programistów do zorganizowania własnych lokalnych przestrzeni roboczych w określony sposób może być sprzeczna z ich szczególnym sposobem pracy, a także przerwać ich przepływ i zmniejszyć ich wydajność.
3. Rzeczy, które nie są pod kontrolą źródła, to częściowo wypalony kod. Jeśli jest to w pełni upieczony kod, który jest gotowy do wydania, powinien mieć kontrolę źródła. Wracając do sedna ...
4. „Jeśli nie ma kontroli źródła, nie istnieje”.

Jednym z możliwych sposobów złagodzenia problemu chęci spojrzenia na kod na stacjach roboczych ludzi jest promowanie kultury regularnych kontroli. Kiedyś pracowałem w firmie, w której - choć nie było takiego oficjalnego mandatu - było to swego rodzaju dumą z tego, że zawsze sprawdzano wszystko na weekend. W fazach konserwacji i zwolnienia kandydaci elementy CR były celowo bardzo drobnoziarniste, aby umożliwić małe, dobrze widoczne zmiany i regularne kontrole, aby je śledzić.

Ponadto obowiązkowe było sprawdzenie wszystkiego przed wyjazdem na wakacje .

Wersja TL; DR : Przeszukiwanie przez stacje robocze ludzi jest złą formą. Zamiast starać się promować kulturę ułatwiającą przechodzenie przez stacje robocze ludzi, aby znaleźć to, czego chcemy, lepiej jest praktykować kulturę rozsądnego korzystania z kontroli źródła i regularnych kontroli. Być może nawet hiper-regularne meldowanie i drobiazgowe zadania w krytycznych fazach projektów.

Zamiast egzekwować standardy dotyczące sposobu organizowania stacji roboczych przez programistów, należy egzekwować standard, w którym cała praca jest sprawdzana pod koniec każdego dnia . Zameldowanie może odbywać się w oddziałach, jeśli nadal będzie niekompletne.

W ten sposób nikt nigdy nie powinien mieć dostępu do stacji roboczej innego programisty.

Wyobrażam sobie, że ta polityka spotkałaby się z pewnym sprzeciwem, ale nic w porównaniu z tym, czego oczekiwałbym, gdybyś egzekwował zasady dotyczące organizacji własnego stanowiska pracy.

Powiem prawdę, że czuję się nieswojo z powodu samego pomysłu, że ktoś będzie logował się na mojej maszynie i przeglądał moje rzeczy. To prawda, że ​​to sprzęt i własność firmy, ale jest to po prostu zła rzecz do zrobienia.

Ostatnim razem, gdy wyjechałem na weekend, chłopaki ponownie skonfigurowali serwery z bazą danych i kontrolą źródła i z jakiegoś powodu uznali za konieczne zalogowanie się na mojej maszynie i zmianę konfiguracji systemu na nowe ustawienie.

Szkoda, że ​​nie mieli pojęcia, co robią i usunęli prototyp, nad którym pracowałem przez ostatnie dwa miesiące.

Nie zdarzyłoby się to, gdyby istniała odpowiednia komunikacja. Tego też potrzebujesz. Dostań się do tego programisty i sprawdź stan rzeczy. Co więcej, poproś ludzi o zgłoszenie przed wyjazdem na urlop, abyś mógł podjąć świadomą decyzję, czy potrzebujesz czegoś z nich, czy nie.

Ale nie zadzieraj ze stacjami roboczymi ludzi.

PS Mamy konwencję dotyczącą struktury katalogów, ale jej głównym powodem istnienia jest mieszanka historii / konfiguracji - umieść ją gdzie indziej i nie będzie się kompilować.

Kilka miesięcy temu pracowałem nad dość dużym projektem i musiałem nagle odejść z pracy, gdy dowiedziałem się, że jestem przyjmowany do szpitala. Nie miałem czasu na sprawdzenie mojego najnowszego kodu dla projektu.

Na szczęście tutaj jest konwencja (choć nie „konieczna”) do przechowywania kodu w /var/www/ourdomain.comcelu naśladowania produkcji. Dzięki tak logicznej i łatwej do przestrzegania konwencji pracownikowi łatwo było zalogować się na moim komputerze i pobrać najnowsze zmiany.

Myślę, że niektóre konwencje są dobre. Chociaż zgadzam się z Bobby, kiedy mówi

„Jeśli nie ma kontroli źródła, nie istnieje”.

Przydatnym dodatkiem do dowolnego obszaru roboczego programistów może być dysk SATA typu hot-swap z przodu, do przechowywania wszystkich projektów źródłowych i programistycznych. W ten sposób, jeśli wystąpi taki problem, pracownik może łatwo pobrać nowe zmiany źródłowe do projektu bez konieczności logowania się na stacji roboczej programisty.

Pierwsza część pytania wyraźnie identyfikuje problemy komunikacyjne w zespole. Czy próbowałeś codziennych pojedynków ?

Zgadzam się z tobą, gdy mówisz, że standardy prawdopodobnie doprowadzą do nieefektywności, jeśli będą zbyt surowe. Zespół musi określać standardy , angażując wszystkich.

W twoim przypadku odczekam kilka dni po powrocie zainteresowanego programisty do pracy. Następnie zorganizuj spotkanie, aby omówić te standardy.

Aby uniknąć jakichkolwiek blokad psychologicznych i oporu, nie wymieniaj osób ani konkretnych rzeczy, które widziałeś. Mówiąc ogólnie, celem jest uzyskanie wkładu od wszystkich, w tym programisty, który Twoim zdaniem powinien poprawić swój sposób pracy. Facet może również uznać twoją organizację za bałagan.

Podczas spotkania przedstaw problem i wyraźnie zapytaj, w jaki sposób zespół może poprawić sytuację.

(Cały) zespół decyduje, co robić.

Ten użytkownik prawdopodobnie cierpiał na brak odpowiednich narzędzi. W szczególności użycie rozproszonego systemu kontroli wersji wyeliminowałoby dla niego potrzebę posiadania różnych katalogów kodu w różnych stanach. Mógł trzymać to wszystko w gałęziach i był znacznie szczęśliwszy.

Najważniejsze jest jednak to, że nie, nie chcę egzekwować standardów dotyczących organizacji własnego stanowiska pracy. Obecnie odpycham się od mojego działu, który standaryzuje się na IDE (mój szef NAPRAWDĘ chce nas wszystkich w Eclipse, ponieważ to jest to, czego używa i dobrze wie, chociaż IMO nie jest najlepszym narzędziem do mojej pracy).

Pozwól programistom robić wszystko, co czyni je wygodnymi. Wygodny programista jest bardziej produktywny niż niewygodny. A jeśli ktoś NIE jest produktywny, a podejrzewasz, że grzebie lokalnie za pomocą narzędzi, jest to okazja na szkolenie, a nie dobry czas na tworzenie nowych zasad.

W moim starym miejscu pracy mieliśmy system, w którym każde zadanie w śledzeniu błędów miało swoją gałąź kontroli źródła. Zrozumiano, że przez większość czasu jeden deweloper zgniata jeden błąd / zadanie, więc zepsuty kod mógł zostać sprawdzony pod kontrolą źródła.

Gdy kod był już w stanie stabilnym w gałęzi programistycznej, dokonano rebase przeciągając kod z gałęzi, z którą zamierzasz się zintegrować. Po przetestowaniu tego scalenia byłoby to po prostu przekazanie kodu do oddziału integracji - nie wymagałoby to scalania, ponieważ scalanie już przeprowadzono w oddziale.

W ten sposób oszczędzasz problem programistów martwiących się o popełnienie złamanego kodu - i możesz zacząć stosować politykę społeczną polegającą na wprowadzaniu kodu przed wyjściem z biura w nocy - ładnie i bezpiecznie.

W tej konkretnej sytuacji zadzwoń do osoby w domu, wyjaśnij, że nie masz wątpliwości, że jest chory, ale musisz poprosić kogoś o kontynuowanie pracy i zapytać, gdzie są najnowsze rzeczy iw jakim stanie.

Następnie musisz zastanowić się, co zrobić z tego miejsca. Jeśli problem polega na tym, że ludzie odprawiają się zbyt rzadko, rozważ użycie rozproszonego systemu kontroli źródła, który pozwala ludziom pracować w oddziałach, nie przeszkadzając sobie nawzajem.

Jeśli problem polega na tym, że nie lubisz programistów posiadających wiele obszarów roboczych na swoim komputerze, przełam to. Styl pracy jest indywidualny i powinieneś zasadniczo trzymać się z dala od ich systemów, o ile działają one dobrze z regułami dla repozytorium źródłowego. Osobiście bardzo często sprawdzam nową kopię dla różnych projektów i od czasu do czasu sprzątam.

Jeśli problem polega na tym, że nie wiesz, co robi programista, problem ma charakter polityczny, a nie techniczny, i musisz zmienić styl zarządzania. Proszę pamiętać, że programiści to wysoko wykwalifikowani pracownicy, którzy rzadko lubią mikrozarządzanie i trzeba przekazać. W przeciwnym razie odepchniesz najbardziej wykwalifikowanych pracowników.

Dlatego zalecałbym zachęcanie do lepszego sposobu pracy ze wspólnym repozytorium źródłowym - powiedz, że ludzie mogą pracować w oddziałach i pozwól im często angażować się, o ile codziennie synchronizują swoją kopię lokalną z głównym repozytorium (ponieważ zawsze będzie wykonywać prace rozwojowe w branży, co nie wpłynie na innych).

Jak radzisz sobie z takimi sytuacjami?

Możesz rozwiązać ten problem za pomocą systemu kontroli źródła, który obsługuje osobiste niestabilne gałęzie i utrzymując częste zatwierdzenia. Zatwierdzenie nie musi nastąpić po rozwiązaniu całego problemu. Powinien nadejść, gdy skorzystasz z kontroli źródła. Koniec dnia jest jednym z wielu punktów, w których powinno nastąpić zatwierdzenie, abyś mógł zobaczyć, gdzie dokonano zmian, wykonać ich kopię zapasową i wyjaśnić je przyszłej jaźni lub innym osobom.

A może prosi się deweloperów o przestrzeganie standardów w tej dziedzinie - korzystanie z określonych katalogów, standardów nazewnictwa, notatek na wiki lub cokolwiek innego?

Mamy ogromny dokument konfiguracji środowiska, który oznacza konwencje, ale nie jest standardem. Normy dotyczą kodu produkcyjnego i środowisk. Jednak wiele naszych narzędzi programistycznych jest skonfigurowanych do obsługi konwencji, a większość programistów nie poświęca wysiłku, by przełamać ten trend.