Standardy pracy programistów na własnych stacjach roboczych

18

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.

development-process coding-standards

— Jon Hopkins
źródło

8

-1 za przejście do gestapo w centrum dowodzenia programisty.

— systemovich

17

Zaraz, skąd drugi programista znał hasło pierwszego programisty?

— TheLQ

12

+1 za doskonałe pytanie. „Going gestapo” nie jest moim zdaniem istotne w środowisku korporacyjnym, ponieważ programiści pracują dla korporacji i dlatego zrzekają się praw dostępu do swoich lokalnych maszyn. Chcesz prywatności, używaj własnego sprzętu.

— Gary Rowe,

4

Jeśli można się skontaktować z programistą w sprawie hasła, dlaczego po prostu nie zapytasz go, która wersja jest aktualna?

— Ben L

2

@Gary: co? nie, to kompletny (i bardzo niebezpieczny) nonsens. To długa szansa (zarówno logiczna, jak i prawna) od pracy dla firmy do rezygnacji z osobistych praw do prywatności. Nie nazwałbym działania Jona „going Gestapo” (zanim jeszcze wyjaśnione bardziej), ale firmy nie iść gestapo czasami i to jest coś, co musi być zabezpieczone i walczył na wszystkich poziomach. Mogę mówić tylko w Niemczech, ale tutaj masz zrobić pewne prawa do prywatności, nawet podczas pracy na sprzęcie własność firmy.

— Konrad Rudolph

64

„ 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:

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.
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ść.
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 ...
„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.

— Stoły Bobby'ego
źródło

10

+1: Ktoś jest chory, awanturowanie się na jego stacji roboczej prawdopodobnie będzie kosztować więcej niż wartość. Jedna osoba już nie ma. Teraz kolejna marnuje czas, próbując dowiedzieć się, co się dzieje. Ogromny koszmar zarządzania bez wartości. Dopóki nie ma kontroli źródła, nigdy nie istniał.

— S.Lott,

1

Jeśli nie ma tego dnia? Tak, przez resztę tygodnia? Może przez miesiąc? Bez szans. Jest to jeden z tych paskudnych „odcieni szarości” problemów… wróciliśmy, aby wcześniej zatwierdzać, często zatwierdzać - więc wzorce niekoniecznie muszą być stacjami roboczymi, ale używają kontroli wersji, ale najwyraźniej jest to coś o czym warto pomyśleć.

— Murph,

Kiedy mówisz o wydaniu, czy masz na myśli wydanie dla kompilacji lub wydanie dla użytkowników?

— JeffO

2

@Murph: Jeśli zmiany są dokonywane gdzieś co X dni, maksymalna ilość pracy, którą można zgubić, jest warta X dni, i to prawda, bez względu na to, jak długo deweloper jest nieunikniony. Właściwe jest, aby zasady dotyczące odprawy były wystarczająco częste, aby ilość utraconej pracy mieściła się w dopuszczalnych granicach.

— David Thornley,

1

@David mój komentarz był odpowiedzią na komentarz @ S.Lott - pod względem argumentu o „zagubieniu”. Cóż, w pewnym sensie. Chcę, aby commity były atomowe w sensie pełnego zestawu zmian (zaczynam rozumieć, dlaczego rebase jest tak atrakcyjnym pojęciem) - więc widzę, że „zobowiązanie się do oszczędzania” jest problematyczne (w ogólnym przypadku i przy braku równoważnika rebase). W każdym razie powinny istnieć codzienne automatyczne kopie zapasowe stacji roboczych, zupełnie odmienne od kontroli wersji.

— Murph,

22

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.

— Kris
źródło

1

Jak często łączysz oddział? Za każdym razem, gdy czułeś, że jest stabilny?

— Jon Hopkins,

2

@Jon Hopkins: „Zwolniony” jest łatwiejszy w zarządzaniu niż „Stabilny”. Wersja zwalniana obejmuje stajnię, a właściciel produktu jest na to gotowy. I wykonasz wiele przetwarzania oddziału do wydania. Od gałęzi do stabilnej ma zbyt duży potencjał podmiotowości i dyskusji „pracował dla mnie”.

— S.Lott,

2

-1 Nie zgadzam się z tym bez ogromnej liczby kwalifikacji, meldowanie powinno odbywać się w logicznym punkcie - a nie arbitralnie pod koniec dnia. (Tak, powinniśmy starać się nie opuszczać, dopóki nie dojdziemy do rozsądnego punktu przerwania, ale życie nie zawsze współpracuje.) Kopie zapasowe powinny być wyraźne. I wszyscy musimy być nieco mniej cenni w dostępie do naszych skrzynek (bez zmian , dostępu do)

— Murph

1

-1, ponieważ nie odnosi się to do scenariuszy takich jak: „Czuję się naprawdę chory, idę teraz do domu. Hmm, lepiej po prostu zrób kolejne 30 minut przygotowań, aby nie popsuć kompilacji podczas zatwierdzania”.

— Gary Rowe,

2

@Murph Checkins do 'trunk' lub mainline (jakkolwiek chcesz to nazwać) powinny występować tylko tak, jak to opisano. Jednak nie ma nic złego w tym, że programiści „zapisują swoją pracę na koniec dnia”, angażując się w osobisty oddział (chociaż jest to o wiele łatwiejsze w przypadku git lub mercurial niż w SVN). W porównaniu z wytycznymi dotyczącymi egzekwowania konfiguracji stacji roboczych dla programistów (co było naszym punktem wyjścia) jest to wręcz rozsądne rozwiązanie.

— Kris,

6

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

3

@Murph: Zachorowanie, któremu towarzyszy pilna potrzeba wyciągnięcia czegoś z jego systemu, jest naprawdę rzadką sytuacją. Może nie być warte wysiłków normalizacyjnych.

1

Rozumiem, dlaczego ktoś powinien czytać twoją pocztę i nie powinien niczego zmieniać na twoim komputerze, ale co powiesz na to, czy udostępnianie katalogów kodu (tylko do odczytu) jest standardem? To by ominęło większość tego, co postrzegam jako twoje obiekcje, ale nadal umożliwiło ludziom dotarcie do pracy w nagłych wypadkach.

— Jon Hopkins,

3

Brak kopii zapasowej na tym prototypie?

— JeffO

2

@ Sztuka dewelopera, dlaczego nie pracowałeś w gałęzi systemu kontroli wersji?

1

@DeveoperArt, co masz na myśli mówiąc „nie korzystasz z tej opcji”? Masz na myśli, że nie było sposobu, aby po prostu utworzyć oddział na własną rękę? Czy w jakiś sposób wyłączyli rozgałęzianie? Nigdy nie słyszałem o takiej możliwości. Mimo to mogłeś stworzyć swoje własne repozytorium „git” (lub nawet „svn”) na własnym komputerze lokalnym (być może kopii zapasowej na Dropboksie lub dysku sieciowym) bez angażowania nikogo innego. Po prostu nie mogę odnosić się osobiście do pracy nad czymś przez 2 miesiące (a nawet 2 godziny , naprawdę), czy to „ważne”, czy nie, i posiadanie tylko 1 kopii tego.

— JoelFan

6

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.

— Craige
źródło

„... to nie istnieje”. To znaczy dla innych.

4

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

2

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.

— Dan Ray
źródło

1

Jak to by pomogło? Pytanie nadal istniałoby, mówimy tylko o tym, która gałąź w jego lokalnym repozytorium DVCS, a nie o jakim obszarze roboczym.

— Jon Hopkins

Nie zakładaj, że są to narzędzia - doceniesz także, jak najlepiej korzystać z narzędzi, których może brakować. To, co oczywiste dla niektórych, musi być pokazane innym. Anty-wzorzec wielu kopii drzewa źródłowego widziałem kilka razy. Tak, DVCS może pomóc - ale w tym kontekście nadal mielibyśmy problem z określeniem właściwej gałęzi i - jeśli chcemy pójść dalej - z udostępnieniem tych gałęzi Work In Progress. @ W lokalnym DVCS powinien automatycznie przesłać „kopię zapasową” repozytorium tego użytkownika. Przynajmniej jeśli usunie problem z pudełka.

— Murph

@Jon - Chyba chodzi o to, że jego różnorodne gałęzie byłyby w czymś, co miałoby wbudowaną funkcję scalania, a nie tylko rozproszone katalogi rozbieżnych plików. Dodatkowo, podniesienie go i rozpoczęcie DVCS byłoby okazją do szkolenia.

— Dan Ray

1

@Dan - Ale niektóre z tych gałęzi są ślepymi zaułkami - dowody koncepcji, rzeczy z różnymi kodami debugowania, w których nie chcesz scalać, starsze wersje. Fakt, że masz funkcję scalania, nie pomaga, gdy nie wiesz, co chcesz scalić.

— Jon Hopkins

@Jon - Myślę, że to prawda. Może po prostu nie ma powrotu do zdrowia po kimś naprawdę zaangażowanym w zrobienie bałaganu.

— Dan Ray

2

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.

— Spedge
źródło

2

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

1

W pytaniu powiedziałem konkretnie, aby założyć, że nie można się z tą osobą skontaktować.

— Jon Hopkins,

@Jon, w takim przypadku uważaj jego niedokończoną pracę za utraconą, przypisz ją do innego programisty, a następnie zacznij zastanawiać się, dlaczego tak się stało.

Jest w tym logiczna niespójność - „nie wiesz, co robi twój programista” kontra „musisz delegować”, co oznacza, że wiesz, co robi, ale prawdopodobnie nie w jaki sposób - co z kolei jest powodem, dla którego musisz dostać się do kodu ... (tak, komunikacja może pomóc w rozwiązaniu tego problemu, ale jeśli ufasz programistom w rozwiązaniu problemu i jest to niewielki problem - dla danego programisty - wtedy „idź naprawić to, pa!” może być tyle samo zarządzania, co jest potrzebne).

— Murph,

@Murph, a następnie egzekwuj zasadę „często zatwierdzaj - w oddziale” i pchaj do centrali co najmniej codziennie.

1

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.

— Thomas Langston
źródło