Zdarzyło Ci się, że projekt, do którego trafiłeś w żaden sposób nie sprostał Twoim oczekiwaniom? To co zastałeś było bardzo niskiej jakości i na pierwszy rzut oka tylko cud trzymał całość przy życiu? Bardzo rzadko jako programista masz możliwość sprawdzenia projektu, w którym będziesz pracował. Coś co na pierwszy rzut oka wygląda ok po zagłębieniu się w szczegóły przeradza się w tragedię. Pierwsza myśl, która się pojawia zapewne sugeruje, że stracisz czas na głupie utrzymanie zamiast się rozwijać. Ale czy na pewno? Czy faktycznie trafienie do słabego projektu to strata czasu?

Coś tu śmierdzi

Przyszedłeś pierwszego dnia do nowej pracy, albo przeniosłeś swój komputer do innego działu. Zaczyna się proces wdrażania w projekt. Wcześniej może słyszałeś od osób rekrutujących, że jest to „całkiem dobry projekt, nie idealny ale wiadomo, że każdy ma jakieś wady”. Brzmi sensownie, nie zwiastuje tragedii.

Po kilku dniach szkoleń czy pierwszych zadań widzisz jednak obraz dużo różniący się od „całkiem dobrego projektu”. Wszystko wygląda jak posklejane taśmą. Przebijanie się przez jakikolwiek fragment kodu zajmuje długie godziny. Debugowanie niewiele daje. Mała zmiana albo powoduje, że system nawet nie chce się skompilować rzucając dziwnymi błędami, albo co gorsza okazuje się dopiero po kilku tygodniach, że inna część systemu się przez to popsuła.

W tym momencie masz już wyklarowaną opinię o tym do czego trafiłeś – jest to bardzo słaby projekt. Ta myśl zagnieżdża Ci się w głowie i idziesz z nią dalej przez życie. Cokolwiek by się nie działo – wszystkiemu winny jest słaby projekt. Jakiekolwiek rozmowy o dobrych praktykach, nowych bibliotekach – po co, przecież to i tak jest słaby projekt i nie uda się nic zmienić?

Zaczyna się frustracja i spada motywacja do czegoś więcej niż odklepywania zadań. Ale czy faktycznie tak musi być? Czy zawsze taki bardzo słaby projekt oznacza jedynie męczarnię aż do momentu kiedy uda Ci się zmienić pracę? 

Czym tak naprawdę jest słaby projekt?

Nie ma jednej konkretnej definicji słabego projektu. Dla każdego słaby projekt będzie objawiał się innymi elementami. Jednak w przeważającej większości przypadków wiąże się to z kodem, który jest ciężki w utrzymaniu, nielogiczny albo generujący dużo trudnych do zidentyfikowania błędów.

Łatwo jest poznać słaby projekt jeśli ma on niechlujnie pisany kod z masą powtórzeń, rozwlekłych metod i klas, nieczytelnych nazw albo wręcz brakiem spójnego formatowania. W takim wypadku od razu wiadomo z czym ma się do czynienia. Pozostaje jedynie dowiedzieć się jak głęboko sięga problem i czy łatwo jest cokolwiek naprawić.

Gorzej jeżeli projekt jest słaby na poziomie architektury czy bardziej ogólnych konceptów. W takim wypadku problemy wychodzą po dłuższym czasie pracy z projektem kiedy próbując dodać prostą rzecz okazuje się, że jest to niemożliwe w żaden sensowny sposób. Taki przypadek wymaga naprawdę dużo pracy i zaangażowania całego zespołu.

Nie wszystko stracone

Przyszła pora aby odpowiedzieć na tytułowe pytanie – czy słaby projekt zawsze oznacza stracony czas?

Skoro takie pytanie się pojawiło to pewnie większość z Was od razu domyśliła się, że odpowiedzią będzie „nie”. I tak też jest. Trafienie do gorszego projektu, który nie spełnia naszych oczekiwań jakościowych to niekoniecznie musi być marnowanie czasu. Warto pomiędzy kolejnymi narzekaniami zastanowić się co można z tej sytuacji wynieść. Bo wynosić można wiele.

Tak to nie będzie działać

Pierwszą istotną informacją jaką da się zdobyć lądując w kodzie, który jest wątpliwej jakości jest informacja jak czegoś nie robić. A jest to bardzo cenna informacja, bo jak mówi powiedzenie – najszybciej człowiek uczy się na błędach. Nic tak nie udowadnia, że jakieś rozwiązanie się nie sprawdza niż faktyczna próba użycia tego rozwiązania.

Istnieje bardzo duża szansa, że trafisz w takim projekcie na koncepcje, które pojawiały się np. w książkach czy kursach i tam, gdzie przykłady były krótkie, wyglądały na użyteczne i fajnie. Słaby projekt może udowodnić, że nie zawsze się takie pomysły skalują i coś co przy małym projekcie może działać, podczas rozrastania się staje się kulą u nogi. W tym wypadku idealnie jest jeżeli w zespole nadal pracują osoby, które były tutaj w początkowych fazach pracy, kiedy to były podejmowane decyzje jak coś powinno zostać zaprojektowane. Rozmowa z takimi osobami i zapytanie dlaczego wtedy się na to zdecydowali zasili głowę dużą porcją wiedzy na przyszłość, kiedy to Ty będziesz stał przed takimi wyborami.

A gdyby tak…?

Drugim dosyć oczywistym obszarem gdzie słaby projekt pozwala czegoś się nauczyć jest refactoring. Jeżeli masz ten komfort, że w projekcie pracujecie bez napiętych terminów i współpracownicy są otwarci na nowe pomysły to próba wprowadzania zmian da Ci bardzo wiele.

Widzisz fragment kodu i od razu masz w głowie rozwiązanie, które uczyni go lepszym/czytelniejszym/łatwiejszym w utrzymaniu? Sprawdź czy uda Ci się je wprowadzić w życie. Bo czytanie o dobrych praktykach i sposobach poprawy jakości kodu to jedno, ale próbowanie faktycznych zmian i rozwiązywanie realnych problemów to zupełnie coś innego. Na początek zapewne będziesz to robił lokalnie, na jakimś testowym branchu w GITcie. Nawet jeżeli ostatecznie cała próba pójdzie do kosza to zobaczysz z czym to się je. Pierwsze podejścia do refactoringu nawet małego fragmentu kodu mogą Ci boleśnie pokazać, że Twoje pomysły też nie są doskonałe, a coś co w modelowym przykładzie w książce działa wyśmienicie, w tak dużym systemie będzie bardzo trudne. Można to porównać do naprawy samochodu – co z tego, że obejrzałeś mnóstwo poradników i przeczytałeś masę instrukcji? Dopiero jak sam chwycisz za narzędzia przekonasz się jak wygląda rzeczywistość i element, który w sprzyjających warunkach jest prosty do znalezienia i wymiany przy próbie dostania się do niego w Twoim samochodzie okazuje się wielogodzinnym wyzwaniem.

Jednak jeżeli nie spróbujesz to nie będziesz wiedział jak to się robi. A nie ma lepszego miejsca do nauki refactoringu niż ogromny kawał kodu, który tego refactoringu wymagał już od kilku lat.

Może uda się to obejść

Ostatnia z poruszanych tutaj rzeczy, jakiej możesz się nauczyć w słabym projekcie to praca w słabym projekcie. Brzmi to zabawnie, ale jednak ma to sens. Jeśli wcześniej zawsze pracowałeś z projektem, który jest dobrze udokumentowany i ma czytelny kod to wskoczenie do słabego projektu na pewno będzie dużym zaskoczeniem i wyzwaniem. Ale będzie to też nauka radzenia sobie w sytuacji kiedy wiele rzeczy nie jest jasnych, albo nie wszystko działa tak jak powinno. Konieczność pracy w słabym projekcie zmusza do lepszego poznania narzędzi do debugowania i czytania kodu. Gdzie się zapiąć debuggerem? Jak najszybciej szukać wywołań dziwnych funkcji? Jak sprawdzać czy to na pewno nie ten fragment kodu powoduje błędy? To są tematy, które w słabym projekcie poznasz bardzo szybko. Inaczej polegniesz.

Słabej jakości projekt z nic nie znaczącymi nazwami i szczątkową dokumentacją to również dobry materiał do nauki komunikacji z klientem albo managerami w zespole. Po pierwsze trzeba będzie na pewno dużo częściej pytać jak jakaś istniejąca funkcjonalność docelowo powinna działać (zdarza się, że to co teoretycznie wynika z kodu i to co klient myśli, że jest to dwie zupełnie inne rzeczy). Po drugie będą momenty gdzie trzeba będzie przekazać i uargumentować, że jakaś funkcjonalność wymaga więcej pracy. Jeżeli chcesz realizować poprzednie punkty to także będziesz musiał nauczyć się jak pozyskać czas na refactoring i poprawianie już istniejącego kodu. Będziesz negocjował. A więc twoje umiejętności miękkie zostaną wystawione na próbę.

Do tego pracując z mocno nieświeżym kodem będą przychodziły momenty wymagające dużej kreatywności i kombinowania. Nie zawsze dany fragment da się albo można poprawić, a podpiąć się do niego trzeba. Co wtedy? Jak to obejść? Jak elegancko i bez orania systemu rozwiązać problem tak żeby każda ze stron uznała, że jest przynajmniej „w miarę ok”?

Podsumowanie

Trafienie do słabego projektu nie musi oznaczać straconych miesięcy życia i odliczania do kolejnej rozmowy rekrutacyjnej. Dużo zależy tutaj od naszego podejścia, opanowania nerwów ale też od nastawienia reszty zespołu. Jeżeli zespół rozumie problem to z takiego projektu można wyciągnąć wiele cennej wiedzy. W dodatku może być to dobry sprawdzian naszych umiejętności. Fakt, że do tej pory nikt nie poprawiał tego co jest nie musi wynikać z ignorancji całego teamu. Może przejęli projekt, ale mieli za małą wiedzę, żeby próbować coś usprawnić? Może nie było osoby, która wynegocjuje czas na poprawki? Może się okazać, że przychodząc do słabego projektu dasz sygnał do zmian, którego do tej pory brakowało? ;) A nawet jeśli nie przekonasz wszystkich to przynajmniej spróbujesz dostać zgodę na poprawki i sam będziesz dbał o jakość tego co robisz i co zmieniasz.

Oczywiście w życiu nie ma samych sukcesów. Dlatego istnieje też szansa, że ciągle będziesz słyszał, że nie ma czas na jakiekolwiek poprawki, a reszta zespołu uzna, że wybrzydzasz i po co coś ruszać. W takim wypadku jak najbardziej słuszne będzie trzymanie się zasady „ostatni gasi światło”. Ale takich projektów Ci nie życzę :)