Szukając nowej pracy za każdym razem zadajesz w trakcie rozmowy te same pytania? „Czy projekt jest nowy?”, „ile lat ma projekt?”, „korzystacie z najnowszego .NETa?”. Jeśli tak to prawdopodobnie jesteś osobą, która lubi pracować tylko z najnowszym kodem.

Szok i niedowierzanie

Dowiadujesz się, że projekt, do którego idziesz jest praktycznie nowy. Przychodzisz pierwszego dnia do nowego biura i nagle zostajesz uświadomiony, że to co Ci mówili na rozmowie to kłamstwo! Projekt ma już 2 lata i korzysta z przestarzałego .NETa 4.5 zamiast 4.6, który wprowadza tyle cudownych nowości! W dodatku całość nie jest oparta o modne od całych 7 miesięcy mikroserwisy umieszczone w chmurze. Koszmar.

Brzmi znajomo? Mam nadzieję, że nie. Mam nadzieję, że jesteś rozsądnym deweloperem, który potrafi zrozumieć, że w tym biznesie, który przecież tak dynamicznie się rozwija, nie ma tak naprawdę możliwości, żeby wszystkie projekty były zawsze nowe. Każdy projekt programistyczny kosztuje ogromne pieniądze (spójrz chociażby na swoją wypłatę, pomnóż ją razy ilość miesięcy twojej pracy, a potem raz ilość osób w zespole. Dostaniesz może z 1/3 końcowej ceny). Nie ma szans, żeby co pół roku firma otwierała nowy projekt, który będzie praktycznie taki sam jak poprzedni ale tworzony w najnowszych technologiach. Nawet na duże zmiany w obecnym projekcie bardzo często nie można sobie pozwolić. Dlatego coś co działa jest zawsze utrzymywane, a nie przepisywane.

Zaczynając pierwszą pracę młodzi ludzie wyobrażają sobie, że trafią do projektu, który dopiero powstaje. Będą mogli decydować o użytych bibliotekach, oczywiście zawsze będzie to coś co jest aktualnie modne. Rzeczywistość jednak weryfikuje mocno te marzenia. Nagle okazuje się, że nigdzie nie pisze się w zupełnie nowym języku, który jest numerem jeden na konferencjach w ostatnim półroczu!

Biblioteki! Biblioteki rozdaję!

Kolejna kwestia dotyczy używanych w projekcie bibliotek. Otwierasz projekt i widzisz, że ktoś pisał „ręcznie” jakieś rozwiązanie. Myślisz sobie, że głupi jakiś, przecież pierwsze co przychodzi do głowy to użycie świetnej biblioteki X! A jakby jeszcze użyć do niej tej biblioteki Y, którą ostatnio chwalili na forum to projekt sam by się napisał! Teraz warto spojrzeć na datę utworzenia tego kodu. 5 lat temu? To nie wieczność przecież. Kiedy powstały biblioteki X i Y? Jedna w zeszłym tygodniu, a druga rok temu…

Widzisz już czemu poprzedni programista ich nie użył? Ciężko użyć czegoś co nie istniało. Niestety niektórzy jeszcze o tym zapominają. Jeśli trafiając na taki kod zaczynasz głośno narzekać na to jak beznadziejne osoby wcześniej tu pracowały to raczej nie zaskarbisz sobie sympatii bardziej doświadczonych kolegów. Trafiając na taki fragment kodu jedną z lepszych rzeczy jakie możesz zrobić to powiedzieć, że widzisz miejsce, które można by zastąpić biblioteką X, którą znasz. I jak będzie ogólna zgoda to w momencie mniejszego ciśnienia dostaniesz czas na takie zmiany. Odświeżysz kod. Za 3 lata przyjdzie kolejny młody gniewny, zobaczy, że używana jest twoja przestarzała biblioteka i też będzie miał dwie możliwości. Itd.

Ło Panie! Kto to panu tak spi******ił?!

Jeszcze jedną kwestią jest narzekanie na jakieś rozwiązanie, które na pierwszy rzut oka łamie sporo „dobrych zasad”. Przychodzisz do projektu. Widzisz fragment kodu działający na zmiennych statycznych, wodospadzie dziedziczenia i tworzący obiekty przez refleksję. Zaczynasz krzyczeć „jak tak można!!”, „ten kod jest do dupy!”. Po czym zaglądasz w dokumentację albo zostajesz uświadomiony przez kogoś pracującego dłużej, że ten beznadziejny, twoim zdaniem kod, został napisany przez wcześniejszego senior developera i jest najprostszym obejściem specyficznego buga frameworka używanego w projekcie. Głupio Ci po tym? Mi by było głupio. Patrząc na dojrzały kod zawsze zadawaj sobie i innym pytanie „co autor miał na myśli?”, „na pewno nie dało się tego zrobić prościej?”.

Żeby nie było, że jestem święty, sam też popełniałem albo popełniam te błędy. Zdarza mi się narzekać na cudzy, starszy kod. Sam też jeszcze te 2 lata temu myślałem, że fajna praca programisty jest tylko wtedy jak trafi on do startupu gdzie nowy projekt jest otwierany co 4 miesiące jak wychodzi najnowsza wersja frameworka. Teraz coraz mniej mnie obchodzi wiek projektu (w granicach rozsądku). Chociaż jeszcze długo będę preferował nowości to jednak akceptuję to, że większość projektów na rynku nie ma szans być przepisywana od zera, a pewne decyzje projektowe miały w momencie ich powstawania konkretny cel i sens.

Także pamiętaj – zanim zaczniesz przeklinać decyzje projektowe twoich poprzedników najpierw zastanów się skąd one mogły wynikać i czy nie są jednak przemyślanym działaniem ;)