Wpis z mikrobloga

Jakiś czas temu zapytałem się Was, w tym wpisie, co powinienem zrobić, czy zostać w patologicznej firmie czy jednak zrezygnować?
Właściwie jednostronnie doradzaliście mi odejście. Postanowiłem to zrobić i uważam, że jest to jedna z najlepszych decyzji, jakie ostatnio podjąłem. W ramach podziękowania będę dzielił się z wami rewelacjami z jakimi miałem do czynienia.

W dzisiejszym wpisie postaram się przybliżyć wam jak wyglądała praca bez systemu kontroli wersji oraz braku podziału na development i produkcję przy 4-osobowym zespole.

W zasadzie istniała tylko jedna kopia projektu obecna na serwerze do którego miało się dostęp przez klienta FTP. Nie można było pobrać całego projektu na swój komputer i pracować lokalnie, ponieważ istniało duże prawdopodobieństwo, że ładując pliki z powrotem na serwer, nadpiszemy zmiany wprowadzane przez kolegów. Istniał nawet pewien rytuał, pytania współpracowników przed edycją czy plik jest wolny i ogłaszania wszem i wobec, że skończyło się edycję, zwalniając przy tym plik. Czasami tylko, ten system oparty o wzajemną komunikację i zaufanie zawodził i ktoś musiał nadrabiać 3h pracy.

Zapytacie pewnie, co jeśli właśnie zapisałem plik, zamknąłem edytor i wysłałem na serwer, a trzeb cofnąć bardzo dużo wprowadzonych zmian. Tutaj ćwiczyliśmy swoją korę mózgową, przywracając wersję pliku sprzed np. całego dnia pracy z pamięci. Ja byłem o tyle sprytniejszy, że wprowadziłem własny system wersjonowania oparty o samodyscyplinę. Co 15-30 minut zapisywałem kolejne wersje edytowanych przeze mnie plików, dodając sufiks w postaci aktualnej godziny. Okazało się to być bardzo pomocne, kiedy główny programista powiedział "Robisz jeszcze ten komponent o, który cię prosiłem? Jak tak, to nie rób i control-zetnij do poprzedniej wersji".

Cały ten system działał niesamowicie sprawnie, widać było, że wspólnym wysiłkiem jesteśmy w stanie osiągnąć niemożliwe. Tylko czasami zdarzało się, że w tym samym czasie parę osób robiło "push" na serwer, a projekt się wysypywał i każdy z nas analizował wprowadzone zmiany, by sprawdzić czy to czasem nie przez niego.

#programowanie #januszeit #januszebiznesu #naukaprogramowania już nie #pracbaza

Mam tych historii znacznie więcej, a nie chcę wołać za każdym razem wszystkich obserwujących wymienione tagi, dlatego proszę was o propozycję własnego tagu.
  • 34
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

Nie można było pobrać całego projektu na swój komputer i pracować lokalnie, ponieważ istniało duże prawdopodobieństwo, że ładując pliki z powrotem na serwer, nadpiszemy zmiany wprowadzane przez kolegów.


@Shreder67: nie bardzo rozumiem, mieliście dostęp do FTP, więc jak rozumiem mogliście pobierać pliki, czemu nie ściągnęliście wszystkiego i sami nie założyliście sobie gita, czy svna?
  • Odpowiedz
@Shreder67: to była jakaś mała kilkuosobowa agencja, w której robiliście jakieś projekty, czy stanowiliście dział IT w większej firmie, niekoniecznie informatycznej?
  • Odpowiedz
@MrGreeneye: @matiit: @Eoghan: @Shreder67: Faktycznie, opowieść OPa brzmi komicznie, ale zakładam się o każde pieniądze, że poszedłbym do każdej jednej z waszych obecnych czy poprzednich firm, zrobił audyt procesów wytwórczych, i znalazł co najmniej tak samo żenujące niedociągnięcia, które w 2016 roku nie mają racji bytu, i wywołują śmiech :)
  • Odpowiedz
Ja byłem o tyle sprytniejszy, że wprowadziłem własny system wersjonowania oparty o samodyscyplinę. Co 15-30 minut zapisywałem kolejne wersje edytowanych przeze mnie plików, dodając sufiks w postaci aktualnej godziny.


@Shreder67: Wiesz, że w IDE masz coś takiego jak Local History? ;-) Nie wiem, jakiego IDE używałeś tam, ale PHPStorm i NetBeans to mają. Robisz sobie zdalny projekt (przez FTP u Ciebie) i wtedy automatycznie mozesz przeglądać historię.
  • Odpowiedz