Ponieważ nasz zespół backendowy nie wyrabia z taskami, zacząłem mu ostatnio pomagać. Zaczęło się od zadań potrzebnych dla mnie z punktu widzenia aplikacji mobilnych, gdzie tworzyłem nowy kod, pisałem własne testy bez żadnych mocków praktycznie i było znośnie. Teraz pomagam przy rozwijaniu już gotowego kodu. W skrócie to się trochę załamałem, jak zacząłem przeglądać. Wczoraj i dzisiaj implementowałem zadanie, którego implementacja zajęła mi może tak z 2 godziny. Pozostały czas został poświęcony na konfigurację mocków. Tak naprawdę ta sytuacja skłoniła mnie, do stworzenia tego tematu.
Żeby nakreślić charakter projektu trochę bardziej, to napiszę, że nasz architekt od backendu to tak naprawdę człowiek orkiestra, który robi jednocześnie za scrum mastera i nie ma dogłębnej wiedzy w żadnej dziedzinie. To pomaga na iOS'ie, to na Androidzie, to na backendzie. Często ja z kolegą musimy myśleć jak zaprojektować API, jak połączyć ze sobą komponenty itd. Nad nim jest jeszcze jeden architekt, który ma dosyć dogłębną wiedzę, ale bardzo lubi kobylaste rozwiązania ze swojego drugiego projektu, które przemyca ze sprintu na sprint do nas. Zazwyczaj też feruje wyroki bez zbadania tematu i jego zdanie jest najważniejsze w kwestiach rozwiązań. Do tego mam wrażenie, że klient bezgranicznie wierzy, że jego decyzje są te właściwe. Potem oczywiście trzeba te rozwiązania poprawiać. Obaj są fajnymi ludźmi, ale ciężko się przebić przez beton momentami.
Teraz o samym projekcie.
- Spring, bo a jakże. Niby wersja 5, ale tylko dla picu. Piekło adnotacyjne i Tomcat wiecznie żywi.
- Klasy z konstruktorami przyjmującymi nawet i po 15 argumentów.
- Klasy domenowe splugawione wstrzykiwanymi propertisami. Nie mogę ich przez to nawet użyć w testach bez stawiania kontekstu.
- Mockito Driven Development. Zmieniam linijkę kodu produkcyjnego i testy wymuszają na mnie zmianę w 100 różnych miejscach.
- Kontrolery po 1000 linii z kluczową logiką biznesową. Korzystają zarówno z repozytoriów, jak i serwisów. W zasadzie można rzucać monetą, żeby odgadnąć, co zostanie użyte.
- Wszędobylska mutowalność i nullowalność.
- Sterowanie wyjątkami.
- Kfiatki tego typu to normalka.
- Rozwijanie dwóch osobnych zadań zazwyczaj prowadzi do konfliktów przy mergowaniu.
- Menadżment przyjmuje taktykę, że w zasadzie nieważne co umiesz jako programista. Bylebyś miał jakiegokolwiek taska z JIRY. Ostatnio nasz człowiek od iOS'a robił zadania na backend (proste, ale zawsze), podczas gdy ostatni raz Javę na oczy widział 10 lat temu na studiach.
Mam wrażenie, że jestem jedyną osobą, która jednocześnie to widzi i chce jej się to zmienić. Większość osób narzeka, ale w gruncie rzeczy ma to gdzieś. Uciekać z projektu jeszcze nie chcę, bo jest niesamowicie ciekawy. Teraz moje pytanie. Jak przekonać wyższe instancje, że należy coś z tym zrobić? Jest to w ogóle możliwe z mojej pozycji (pozycji programisty Androida, który pomaga przy backendzie głowom „mądrzejszym” od siebie)? Od czego w ogóle przy tym wszystkim zacząć? Jak przy tym wszystkim przekonać klienta, żeby dał czas? Argument, że z każdym deploymentem są jakieś problemy do niego nie trafia.
Dodam, że jak przyszedłem do projektu, to w Androdzie było dokładnie to samo. Kod odziedziczony po projekcie matce, który był kupą gówna. W pewnym momencie miałem tego dość i odciąłem się całkowicie od jedynej słusznej drogi i przepisałem całą aplikację (z wyjątkiem jednego modułu, z którego niestety muszę korzystać). Dalej jest mnóstwo rzeczy do poprawy, ale przynajmniej da się w tym odnaleźć i szybko dostosowywać kod do nowych wymagań. Na backendzie nie mogę sobie niestety na to pozwolić. Brakuje mi autorytetu i czasu.