Jak działać w zrypanym projekcie?

0

Powiedzcie mi, bo jestem jeszcze młody i głupi. Jak mam zachowywać w się teamie, gdzie projekt nie ma nic wspólnego z współczesną inżynierią oprogramowania?

Między innymi zauważyłem:

  • brak jakichkolwiek testów
  • brak abstrakcji w klasach - po prostu klasa to bardziej namespace dla długich metod
  • nadużywanie dziedziczenia (dziedziczenie już występuje, gdy klasa bazowa ma jakąś funkcję), a w rzeczywistości ani klasa bazowa ani klasa pochodna nie powinna jej posiadać (tylko zupełnie inna klasa)
  • grube modele (active record na potęgę - to jednoczesnie pełni odpowiedzialność za dane, logikę i jakieś pomocnicze przeliczenia) Ja bym wszystko wydzielił z niego, tak, żeby łatwiej to testować.
  • nazewnictwo czasem polskie czasem angielskie
  • numerowane kolumny w tabelkach
  • brak transakcji, wszystko leci na pałę
  • podejście na krótką metę - typu skocz dopisz ifa i po sprawie

Wiem, że taki projekt nie jest przykładem dobrego oprogramowania i, że właściwie więcej bym się nauczył, gdybym zmienił pracę. No, ale nie chciałbym uciekać z takiego powodu. Powiedzmy, że kasa się zgadza, a ja wierzę, że praca nad legacy code wpłynie na mój skill.

Z drugiej strony widzę, że mam przed sobą nie tylko projekt do pokonania, ale również zespół, który chyba przywykł do klepania. Nie chciałbym już w pierwszych dniach mój zestaw punktów zaufania wykorzystać do krytyki i pokazywania jaki mają słaby kod, bo to było nie na miejscu.

No, ale jakieś działanie wypada podjąć inaczej z czasem szlag mnie trafi jeśli będę pisał tak jak oni.

1

Porozmawiaj otwarcie z ludźmi i szefem, jeśli nie wytłumaczysz im że fundamentem firmy tworzącej soft jest "o dziwo" soft, to lepiej uciekaj. Też tak miałem, że szef twierdził że najpierw trzeba zarobić kasę, a potem będzie czas na poprawki oraz kasa od klienta, który będzie w stanie wtedy płacić za jakość. Pracując tak kilka lat, niestety nie dorobiłem się ani kasy, ani poprawy jakości kodu. Taki tryb pracy powodował w uproszczeniu kilka sytuacji:

  1. Czemu tak wolno to robisz? (bo analizuję sporo przypadków użycia, skrajnych wartości itp itd, bo piszę to tak żeby potem ktoś mógł to rozczytać). Przecież tam wystarczy IF'a dodać
  2. Czemu ten moduł nie działa tak jak powinien? (bo olewałem sporo przypadków i robiłem na pałę, tak aby tylko coś działało, przyczyną jest IF z punktu nr 1)
  3. Próbujesz wszystko robić zgodnie ze sztuką, chciałbyś robić tylko idealny kod, a my na to nie mamy pieniędzy - no i tutaj zmieniłem firmę :)

Macie code-review w firmie? Jeśli nie to wprowadźcie. Jeśli szef nie zaakceptuje Twojej prośby o drastyczne podnoszenie jakości kodu, powiedz że skoro szefa nie stać na tworzenie dobrego kodu, to Ciebie nie stać na brak rozwoju.

2

czy ktos Ci broni pisac testy i pracowac zgodnie z praktyka?

Jezeli nie to po prostu to rob
Jezeli tak, to otwarcie przedyskutuj ta kwestie i jezeli nie ma zadnej opcji szukaj innej pracy (pracujac ciagle w tej)

5

W projekcie ze złym kodem najgorszy jest zwykle nie kod, ale cała kultura firmy, która pozwoliła na stworzenie takiego gie.

Jest coś takiego jak "Prawo Conwaya"
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
https://en.wikipedia.org/wiki/Conway%27s_law

I w sumie rzeczywiście często jest tak, że:

brak jakichkolwiek testów

Jeśli w firmie się co chwila powtarza bezmyślnie i krótkowzrocznie "na testy nie ma czasu" to wynik jest, jaki jest.

podejście na krótką metę - typu skocz dopisz ifa i po sprawie

i znowu - bardziej czynnik ludzki (czasem wymuszany przez menedżerstwo), niż brak umiejętności pisania kodu (w zasadzie to też, bo niektórzy, szczególnie początkujący, nie umieją pisać inaczej niż na ifach - ale to też czynnik ludzki bo tacy ludzie w ogóle nie powinni być zatrudniani. Więc byłaby to wina osób odpowiedzialnych za rekrutącję, że zatrudnili osoby niekompetentne).

nazewnictwo czasem polskie czasem angielskie

Bo programiści tak zwykle rozmawiają ze sobą na codzień, takim niechlujnym pidżinem-pongliszem ("weź zrób nowego brancza i pusznij do mastera"), i piszą w ten sposób kod. Czyli znowu, czynnik ludzki, niechlujność formułowania wypowiedzi i przekładanie nawyków z bardzo potocznej mowy mówionej na język w kodzie projektu (który powinien być jednak o kilka poziomów wyżej niż to, co sobie mówią programiści przy ekspresie do kawy).

Z drugiej strony widzę, że mam przed sobą nie tylko projekt do pokonania, ale również zespół, który chyba przywykł do klepania.

Widzę, że moja diagnoza jest dobra (pisałem powyższe punkty zanim doczytałem do końca posta). Jak dla mnie sytuacja raczej nie do uratowania jest. Co innego, gdyby kod był słaby, ale zespół zdawałby sobie sprawę z tego (no bo kod nie zawsze jest idealny - czasem się przejmuje też projekt po kimś - ale co innego, jeśli zespół o tym wie i chce zmienić, a co innego jeśli po prostu lubi się babrać w gównie, bo nawet tego nie zauważa).

Powiedzmy, że kasa się zgadza, a ja wierzę, że praca nad legacy code wpłynie na mój skill.

To prawda, ale pod warunkiem, że będziesz mógł stosować zasadę skauta (zostawiać kod w lepszej postaci, niż go zastałeś). Jeśli nikt w firmie nie widzi problemu, to potem może być tak, że np. będziesz refaktorować jakiś moduł albo pisać testy - a reszta zespołu będzie się pukać w głowie i mówić, że tracisz czas na głupoty. Myślę więc, że możliwe, że największym skillem, jakiego się nauczysz będzie to, w jaki sposób rozmawiać z galaretami umysłowymi i jak robić zmiany w projekcie na lepsze, żeby ukryć ten fakt przed przełożonymi ;)

3

Myśle że powinieneś zacząć działać zgodnie z zasada skauta. Jest spora szansa, że ludzie pójdą w Twoje ślady.

Czasami samo rzucenie hasła: „hej, zacznijmy pisać testy” nic Ci nie da. Tak było w mojej pierwszej pracy. Próbowałem przekonać i kolegów, i managerów, że trzeba coś zacząć robić. Efekt był taki, ze koledzy przytakiwali, ale nikt nic nie zaczęli robić, a managerowie mówili ze nie jesteśmy duża korporacja i nie ma na to (testy) czasu i kasy.

W mojej drugiej firmie z początku kontynuowałem podejście z pierwszej firmy, ale szybko się opamiętałem. Kupiłem odpowiednie książki, swoisty starter pack (opisałem na mikro blogu) i zacząłem działać. Ku mojemu zdziwieniu kolega do mnie dołączył. Najpierw jeden, później drugi...

Spróbuj pokryć testami jakiś ważny z punktu biznesowego kawałek kodu. Możesz nad ta metoda/klasa nawet napisać ze metoda ma testy i prośba o uruchomienie przed commitem. Jak przyjdzie Twojemu koledze zmienić ten kawałek kodu i będzie dysponował testem napisanym przez Ciebe, to na własnej skórze się przekona jak ogromna wartość taki test dostarcza. Wtedy nawet nie będziesz musiał go przekonywać.

Tobie tez polecam to podejście. Jeżeli i ono zawiedzie, to proponuje spróbować zmienić firmę i na początku zaznaczyć jak ogromne znaczenie ma dla Ciebie code review i testy, dzięki czemu znowu nie trafisz na jakieś bagno.

1 użytkowników online, w tym zalogowanych: 0, gości: 1