Niska jakość kodu w projekcie

Cześć,

Od kilku dni jestem w nowej firmie i tym samym dostałem do rozwijania nowy projekt. Nie ma w tym nic specjalnego, kod nie jest udany, brakuje w nim OOP (nie mówiąc o samych wzorcach :D), testów, dokumentacji i przemyślanego wykorzystania frameworka do programowania asynchronicznego. W kodzie nie ma jednolitej konwencji klasa czasem jest pisana jak zmienna, a zmienna jak klasa; sporo zakomentowanego kodu, który został dla potomnych i wiele innych potworków.

Przez ten weekend myślę jak powinienem postąpić w pracy i nie nachodzą mnie optymistyczne wnioski. Choć kodu nie ma na szczęście milion linii :D to i tak nie kalkuluje mi się przepisywać wszystko. Z moich obserwacji i spotkań w jakich uczestniczyłem widzę, że taką firmę nie bardzo obchodzi jakość tworzonej usługi, a raczej przyrost realizowanych zadań.

Myślę, że część z was powie to zmień pracę :p Ten wariant to złe wyjście, bo uciekać z projektu tylko dlatego, że jest brzydki to niezbyt profesjonalne zachowanie (w przyszłości będą dużo trudniejsze rzeczy do rozwijania) dlatego chciałbym już od młodych lat wypracować podejście, które pozwoli mi wywiązywać się ze stawianych zadań.

Zastanawiałem się czy jest sens prowadzić rozmowę z biznesem i tłumaczyć jak bardzo ważny jest clean code. No, ale tego nie robi się pod biznes tylko pod programistów. Poza tym myślę, że wytykanie wad zespołowi już od pierwszego tygodnia nie sprawi, że oni nagle zmienią swoje nawyki, wypracują nowe i zaczną to lubić. Czuję, że w tym przypadku wiele rzeczy może obrócić się przeciwko mnie.

Co w takim przypadku byście zrobili?

Dzięki za uwagę.

Zapytaj czy nie byłoby prościej wykonać tego w ten sposób i wytłumacz albo pokaż jak.

Jak zaczynałem pracę w obecnej firmie trafiłem do projektu, który był delikatnie mówiąc bagnem. Miałem o tyle komfortu, że nie było to coś dużego i namówiłem team leada do przepisania całego kodu, co z czasem dało dużo korzyści, a czas poświęcony na napisanie tego od nowa w konsekwencji się zwrócił. Nie zawsze jednak da się to zrobić, a wtedy pozostaje małymi kroczkami pokazać, że ma to sens.

Z punktu widzenia biznesowego zwykle człowieka nie obchodzi, czy kod jest dobry, czy nie. Ważne że działa i zarabia kasę. Takiej osobie można wytłumaczyć pewne techniki dobrego programowania pokazując realne korzyści, jakie dadzą. Przykładowo jeśli nie ma testów w kodzie, to często zapewne pojawiają się bugi, czy - co gorsza - brak zrozumienia oczekiwań biznesowych przez programistę. I w konsekwencji następują ciągłe zwrotki (z własnego doświadczenia zdarzyło nam się 6 pełnych iteracji dla pojedynczej funkcjonalności, bo obie strony nie mogły się dogadać). Jakby policzyć koszt tych zwrotek, to dajmy na to z 5 tysięcy robi się 15, a można było tego uniknąć, albo chociaż zmniejszyć rozrzut liczbowy. Niestety sprawy nie załatwisz pewnie po jednym spotkaniu, u mnie batalia o wykorzystanie TDD toczyła się ponad pół roku.

Twoja sytuacja jest często spotykana w firmach. Zwykle brak pieniędzy, czasu i niewiedza co do procesu wytwarzania oprogramowania skutkują cięciami w jakości. Czy w zespole stosowana jest jakaś przemyślana metodyka? Jeśli nie, to może warto od tego zacząć. Polecam zapoznać się z XP (i może ogółem filozofią agile) - sporo zagadnień z XP pomaga młodym zespołom w zgraniu się i dopracowaniu jakości.

Inna sprawa, że w Twoim zespole może też po prostu brakować ludzi bardziej rozgarniętych. W tej sytuacji może być trudniej przekonać do pewnych nawyków, bo po prostu nie mieli styczności z tym. Może pomóc wtedy sięgnięcie po jakiś autorytet i case studies, w których warunki są podobne do Waszych.

Zaczynałbym prowadzenie rozmów z najbliższym otoczeniem i zainteresowanie ich dobrymi praktykami. W dalszej kolejności poszedłbym dalej - do osób zarządzających i wyjaśnił, jakie realne korzyści płyną, jeśli podejmiecie odpowiednie działania. Trzeba tylko chcieć i nie zrażać się początkowymi blokadami z różnych stron. To długi proces, dobrze mieć kogoś jeszcze u boku w firmie - wtedy łatwiej się przebić. Z czasem jak wypracuje się odpowiednią pozycję, jest dużo łatwiej.

Na koniec: wszystko zależy też od wielkości firmy. Raczej nie licz na rewolucję w korporacji - w małych zespołach prędzej, jeśli to nie jest rewolucja na lata - a wprowadzenie jakiejś kompletnej metodyki tyle może też trwać. Natomiast małe zmiany to często kwestia miesięcy i do tego da się ludzi namówić, trzeba jedynie znaleźć odpowiednie argumenty. A jak i to nie pomaga, to pytanie czy warto tracić nerwy. Ja "ewangelizowałem" ze znajomym długo. On już dał sobie spokój i pracuje w firmie X. Ja jeszcze się w to czasem bawię, a zaczynaliśmy od totalnego kodu spaghetti. ;)

Zależy co masz do zrobienia. Raz miałem do czynienia z bardzo kiepskim kodem wykonanym w PHP. Do zrobienia było usunięcie widocznych błędów (czas na wykonanie 5 dni 2 programistów) w celu odebrania go przez klienta. Robota zrobiona klient odebrał go (start up) z naszymi uwagami że w razie powodzenia kod wymaga przepisania. Słuch po start upie jak i kodzie zaginął. Trochę się umiałem przy robocie z jednego komentarza w kodzie w języku polskim /jeszcze tylko dziada z babą tu brakuje.