Pisałem już wcześniej o tym, o co warto zatroszczyć się przy zmianie pracy, aby do kiepskiego projektu nie trafić:
7 pytań, które powinieneś zadać pracodawcy, żeby nie wtopić przy zmianie pracy
Dziś o tym, co zrobić o ile już się wtopiliśmy.
Praca z zastanym kodem to nie tragedia, a wręcz może okazać się szansą! Powiedzmy sobie szczerze – programistów znających zasady pisania SOLIDnego kodu jest jak na lekarstwo. A tych, których oprócz znajomości teorii stosują ją w praktyce… Ja znam zaledwie kilku. A o ile zdecydowanie więcej jest kiepskich programistów niż dobrych to prędzej czy później staniemy w obliczu takiego problemu:
Mam złą wiadomość. Słaby kod jest praktycznie w każdej firmie. Jedyną różnicą jest to jak firma sobie z tym radzi i to według mnie decyduje kiedy mówimy o słabej i dobrej firmie w kontekście programisty. Co jednak zrobić kiedy firma zdecydowanie nie radzi sobie z projektem, a dodanie każdej nowej funkcjonalności jest drogą przez mękę? Najprościej – zwolnić się. Ale zaraz, zaraz…przecież na początku napisałem, iż tego typu sytuacja może być szansą. Bynajmniej! Nie zamierzam się z tego teraz wycofywać rakiem. Mam za to kilka sprawdzonych sposobów jak na pracy w kiepskim projekcie zyskać. Być może uznasz, iż sposoby te są banalne, bo w istocie takie są. Wszystkie z nich odkryłem jednak przez przypadek i liczę, iż pomogą one tym osobom, które tego szczęścia nie miały.
1. Automatyzuj.
Z automatyzacją jest jak ze zdrowym odżywaniem. Każdy wie, iż trzeba to robić, ale większość znajduje całkiem (pozornie) rozsądne wymówki, żeby tego nie robić. Oszczędzamy minuty, a tracimy godziny robiąc te same czynności kilkaset razy. Przy wprowadzaniu automatyzacji największym wrogiem jest ludzka natura. Ludzie po prostu lubią robić te same rzeczy w sposób, który już znają nawet, o ile nie ma to najmniejszego sensu. No cóż, można podjąć próby przekonanie kogoś do swoich racji – to dopiero strata czasu! Czasem lepiej sobie odpuścić i zautomatyzować jego głupotę. o ile instalacja systemu w firmie jest robiona w sposób manualny to postaraj się zautomatyzować chociaż kilka jej kroków. o ile automatyzacja całego procesu wydaje się Ciebie przerastać to “dziel i zwyciężaj”. Automatyzacja choćby najprostszej czynności daje masę satysfakcji. Zacznij od małych rzeczy, a zanim się obejrzysz zautomatyzujesz całe swoje życie :).
Nie poddawaj się, o ile nie masz wpływu na procesy w firmie. Zacznij od siebie. Chociażby od tego, aby przeglądarka internetowa otwierała się automatycznie po zbudowaniu projektu. Być może jest to oszczędność kilku sekund, ale to dobry pierwszy krok!
2. Zacznij pisać testy.
O tym jak bardzo ważne są testy powiedziano już wszystko. Co jednak zrobić, kiedy jesteś jedyną osobą w projekcie, która o tym wie? Niestety, Twoje wysiłki nie poprawią w znacznym stopniu jakości kodu, o ile dla wszystkich innych testy będą tylko balastem. Nie przejmowałbym się tym. Możesz próbować przekonywać innych do tego, jak bardzo ważne są testy, a możesz po prostu…zacząć je pisać. Co najwyżej tylko Ty będziesz je uruchamiał. Kto wie, być może ktoś przyłączy się do Ciebie i uzna za wartościowe tworzenie kodu w ten sposób. A o ile choćby nie, Ty każdego dnia będziesz stawał się lepszym programistą. A umiejętność pisania testów do kiepskiego kodu zaprocentuje w przyszłości.
Jeżeli chcesz przejść szybki kurs TDD, czyli techniki pisania testów przed napisaniem kodu produkcyjnego to polecam zaopatrzyć się w książkę Kenta Becka – TDD. Sztuka tworzenia dobrego kodu.
3. Na bieżąco śledź zmiany w kodzie innych osób.
Bolączką wielu firm, szczególności dużych zespołów, jest mikrozarządzanie. Członkowie zespołów mają minimalną wiedzę o celu i znaczeniu projektu – brakuje im tak zwanego “big picture”, ponieważ skupiają się tylko na swoim zadaniu oderwanym od kontekstu całego projektu. Aby tego uniknąć w projektach programistycznych stosuje się zwykle spotkania (mała skuteczność), pair programming lub code review (lepsza skuteczność).
Jeżeli jednak jesteś w projekcie, gdzie mówiąc kolokwialnie: “każdy sobie rzepkę skrobie”, o pair programmingu nikt nie słyszał, a spotkania to jedna wielka strata czasu to…po prostu poświęć 10-15 minut dziennie na zapoznanie się ze zmianami, które zrobili Twoi koledzy. Kiedy synchronizujesz swój kod z repozytorium przeczytaj commity, które pobrałeś. Dzięki temu będziesz wiedział, co dzieje się w projekcie, a często wyłapiesz kilka ciekawych smaczków.
4. Każdego dnia notuj czego się nauczyłeś.
Niesamowicie prosty i skuteczny sposób na podniesie własnej motywacji. Wiele osób narzeka, iż nie rozwija się w swojej pracy. Wydaje mi się, iż jednak zdecydowanie częściej te osoby nie widzą, iż się rozwijają, ponieważ nie mają jak tego sprawdzić. o ile mówisz, iż już się nie rozwijasz to sprawdź czy tak naprawdę jest. Załóż sobie notatnik, w którym codziennie w kilku zdaniach zapiszesz, czego dziś się nauczyłeś. Kiedy zauważysz jak wiele wpisujesz Twoja motywacja będzie samo nakręcającą się maszyną. Zeszyt działa o tyle świetnie, iż wiedząc o tym, iż codziennie musisz tam coś zapisać, starasz się nauczyć czegoś nowego, choćby tylko dlatego, aby mieć co zapisać. W najgorszym wypadku, o ile po tygodniu zeszyt będzie pusty to będziesz miał niezbity dowód na to, iż rzeczywiście niczego już się nie uczysz i warto się zastanowić nad przyczyną takiego stanu rzeczy.
5. Stosuj możliwie najlepsze narzędzia.
Wiele firm unika inwestowania w narzędzia. Jest to o tyle zadziwiające, iż często są to duże firmy, które dobrze opłacają swoich pracowników, a jednocześnie skąpią na lepszy sprzęt, czy licencję IDE. Być może pokutuje tu stereotyp: “hej, przecież mamy darmowy OpenSource”. Po co płacić za coś, czego zamiennik jest darmowy i działa prawie tak samo? Otóż, okazuje się, iż warto.
Genialnie opowiadał kiedyś o tym pracownik firmy DocPlanner, na którego prezentacji miałem przyjemność być. Ów prelegent pokazywał przykłady, w których jego firma dochodziła latami do rozwiązania problemu. Kiedy wymyślili koło na nowo i wydali na to setki tysięcy złotych okazywało się, iż już ktoś na świecie to zrobił i jest gotowy podzielić się swoim rozwiązanie za drobną opłatą kilkuset dolarów. Człowiek ten podsumował swoją prezentację zdaniem, które wyryłem sobie dość mocno w głowie: “zawsze kupujcie od ludzi, dla których to, co kupujecie jest najważniejszą rzeczą w życiu”.
Nawet o ile Twoja firma nie chce zainwestować w Twoje środowisko pracy to zrób to sam. Naprawdę warto wydać te kilkaset złotych na lepsze IDE, bądź inne narzędzie, które przyśpieszy Twoją pracę. Rachunek jest niesamowicie prosty. Produktywniej pracujesz → szybciej zdobywasz kompetencje → jesteś co raz lepszy → jesteś coraz droższy. W związku z tym to przede wszystkim w Twoim interesie jest znaleźć sposób na produktywniejszą pracę, a lepsze narzędzie na pewno w tym pomogą.
Podsumowując, praca z zastanym kodem nie należy do marzeń nikogo, ale jestem zdania, iż zdecydowanie można ją polubić. Powiedziałbym nawet, iż nie mamy wyboru. Trzeba ją polubić, bo prędzej czy później spotkamy się z kodem, którego widok przyprawiał będzie o myśli o złożeniu wypowiedzenia. Nie warto tego jednak robić pochopnie, a jestem choćby zdania, iż o ile w firmie jest chęć do zmiany na lepsze to może być ona najlepszym miejscem dla Ciebie. Zdecydowanie lepszym niż start-up stosujący super-sexi technologie, o których jutro nikt nie będzie pamiętał. Umiejętność radzenia sobie w trudnych warunkach procentuje. Bądź Bearem Gryllsem programowania!
