Najgorszy projekt w jakim pracowaliście

Raz przyszło mi pracować w projekcie na szczęście krótko w którym:

• nie było jakiejkolwiek architektury, każdy programista bym swoim własnym architektem
• brak unit testów
• coding standard był, ale mało kto przestrzegał
• brak code review. Teoretycznie było, ale od razu się dawało Code review +1 bo nie było na to czasu
• totalne spaghetti. część rzeczy napisana w C++03, część w C++11, inne w czystym C, pliki większe niż 10k linii

Wszystko spowodowane było tym, że było bardzo mało czasu i ludzi na stworzenie programu. Oczywiście nie wszystko było pisane od zera, dużo kody zostało zapożyczone z innych podobnych projektów.
Co najdziwniejsze, produkt finalnie działa całkiem znośnie, jak na totalny brak procesu, klient zadowolony(zagraniczny) a firma zarobiła bardzo dużo.

Brzmi jak kazdy inny projekt

Każdy projekt do 2016. W 2016 nastąpiła jakaś magiczna zmiana i ludzie zaczęli pisać testy i używać gita i czasem nawet review robić

KamilAdam napisał(a):

nastąpiła jakaś magiczna zmiana i ludzie zaczęli pisać testy i używać gita i czasem nawet review robić

Magia kasy, to się w dłuższej perspektywie biznesowo opłaca.

Każdy projekt w AMBasic. Ależ to było g**no. Nawet Adabas był lepszy...
EDIT: Adabas +Natural.

Dobra moga napisać. Był taki projekt i ktoś wpadł na genialny pomysł użyć Spring WebFlow.
Takiej kupy to żech jeszcze nie widziol co tedy

Ze spedżetti czy brakiem testów to nie kłopot sobie poradzić, ale z szefostwem już gorzej, dlatego ja uznaję najgorszy projekt ten, w którym mój szefu postanowił że zacznie projektować architekturę do projektu. Nie będę mówił, że źle projektował bo było ok ale... Wszystko było by spoko gdyby projekt wcześniej nie został wyceniony na dużo prostszą architektur gdzie zrobienie prostego endpointa nie miało zajmować 8h z przejściem przez kilka nikomu nie potrzebnych warstw z wymogiem pisania testów do każdej warstwy. No i wszystko było by ponownie spoko gdyby szefu znał konsekwencje tego co robi a nie najpierw wymagał robienia kodu w wersji 3x dłuższej a potem się pytał "czemu o kilkaset h wyszło więcej niż było wycenione" wraz z groźbą potrącenia kasy za to wszystkim :D Tak to był moment gdy postanowiłem się zbierać z tego miejsca.

Takie rzeczy co niemieccy programiści PHP wymyślali to się fizjologom nie śniły. To nie jest temat do rozmowy przez internet i na trzeźwo.

Trochę tego było. Jeden z gorszych to był jak pracowałem w utrzymaniu projektu napisanego początkiem lat 90 poprzedniego stulecia dla elektrowni atomowej. Krążyła legenda, że pierwsi twórcy mieszkali w namiocie na terenie elektrowni jak go pisali. Potem jak urośli wysłali developmnet na Sri lankę to kod to był poklejony na sznurkach i gumie do żucia a do tego na to wszystko nakładanie były modyfikacje dla klienta. Po prostu poezja czasem człowiek ja debugował to się czuł, że to szambo go przykrywa. Do tego proces wdrożenia był mega zepsuty. Część logiki była napisana w PL/SQL front w takim nikomu nieznanym narzędziu, które potem sportowali do C# co skutkowało, że to był najgorszy kod w C# jaki widziałem. I tam jeszcze były kary umowne na poprawę błędów co powodowało, że poprawa bardzo często kończyła się odpaleniem jakiegoś skryptu co naprawiał skute, a nie przyczynę. Wytrzymałem tam 1.5 roku.

Najgorsze projekty to były takie, jak rekrutowano mnie na programistę a potem kazano zajmować się czymś innym (kłamanie na rozmowie).

Ale najgorszy technicznie czy taki co mi sie najmniej podobal ?

Bo paradoksalnie, najgorsze technicznie legacy w jakim siedzialem (XSLT, wlasny system regulowy, bardzo skomplikowany proces budowania, praca bezposrednio z klientem ktory nie do konca wiedzial co chcial) bylo najlepszym projektem pod katem zespolu, ludzi i atmosfery.

Mieliśmy (ja + 3 juniorów) do naklepania coś jak google forms, ale z logiką - jak wybierzesz odpowiedź A to idź do pytania 3, jak wybierzesz B to idź do 4. Deadline - miesiąc. Nie wiem jakim cudem ktoś w ogóle przyjął taki projekt.

O Panie. No to siadamy i nie tyle do samego projektu co do całości.

"Powazna" aplikacja do odpalania on-premise i cloud-native z racji specyfiki klientów docelowych. Jedni odpalą instancję na Azure, a inni w piwnicy na stacjonarce.

• Firma trzepie buzzwordami na prawo i lewo: Docker, Kubernetes, Ansible, Terraform, Helm, Rancher, Redis, Istio, Kto da wincyj!
• Serwery albo poważne albo laptop stojący w serwerowni
• Zespół ułomnych programistów robiących projekt od startu opartą o mikroserwisy
• Brak env w projekcie. Wszystko hardkodowane. Płacz przy każdej zmianie, że coś jest nie tak!
• Polskie albo polsko-angielskie nazwymetod
• Architekt od infrastruktury zjada każdego wiedzą, bo przeczytał ponad 100 książek i zna każde możliwe narzędzie (https://landscape.cncf.io/) - Jak wejdziesz w polemikę teoria vs. praktyka, architektowi odcina prąd i nagle ma coś pilnego do zrobienia.
• Architekt: CentOSy! CentOSy! Wszystko robimy na CentOSach! Mów, że przygotujesz maszynę pod deployment, postaw CentOS, nie potraf otworzyć portu na Docker-Registry
• Architekt: Zjedz na Linuxie zęby / twierdź, że drugi monitor podpięty Ci nie działa, bo to wina monitora / nie potraf zrobić fixa / pracuj na jednym.
• Rozkminiaj czy wirtualka z dockerem obsłuży 200 osób - miej ambicje na obsłużenie 2 mln.
• Notoryczny brak zasobów, problem z dokupieniem porządnego serwera > ktoś w firmie specyfikuje sobie jednorazowe laptopy 2 in 1 za 10k sztuka.
• Zespół programistyczny na 2 tygodnie przed oddaniem aplikacji wymyśla sobie, że przebuduje jakieś 2 duże moduły (ale super!).
• Chyba brak zbierania logów w aplikacji, bo za każdym razem gdy coś im nie działa to lecą z awanturą do adminów/devopsów, że to ich wina.
• Brak kultury pracy: delegowanie tasków na gębę po czym przypieprzanie się, że coś jest zrobione (tak jak zostało zlecone) w taki, a nie inny sposób.
• Programista wynajduje jedno narzędzie, rzuca temat do opsów żeby sprawdzili, bo może być fajne - jednocześnie sam nie wspomina o tym jaki jego problem to rozwiązuje i jaki jest cel sprawdzania narzędzia.
• Mógłbym tak wymieniać pewnie drugie tyle ale już mam dośc.

PS. Co wygrałem?

W firmie mieliśmy Lotus Notes, to taka gotowa platforma, którą można rozszerzać. System był personalizowany przez jednego programistę pracującego w firmie przez lata i zajmującego sie tylko tym. Pewnego dnia ów programista odszedł.

Dostałam na swojego kompa designera (takie oprogramowanie dedykowane do rozwijania platformy) i uprawnienia, żeby móc tam przeglądać kod i coś zmienić w razie potrzeby.

Poczynając od tego, że nie było żadnego środowiska testowego (lokalnego ani zdalnego), każda wprowadzona lokalnie zmiana była na produkcji. Nie było systemu zarządzania wersjami - żaden git, svn nic. Po prostu zapisujesz plik i nowa wersja śmiga na produkcji i już nie cofniesz do starej. Nazwy zmiennych, plików po polsku. Kod masakra. Przeglądam listę agentów (czyli scryptów js) żeby znaleźć odpowiednie powiadomienie mailowe a tam nazwy: powiadomienie1, powiadomienie2, ... powiadomienie21.
Było dużo więcej tego, ale chyba juz trochę wyparłam z pamięci tę traumę :)

Mam podobny przykład jak @szarotka . Sam w sobie Notes działa znośnie (wcale nie dobrze, po prostu znośnie), ale z wieloma pisanymi na kolanie dodatkami zrobił się potworek. Dobrze, że jest w firmie ktoś, kto ma tajemną wiedzę jak to działa, bo sam parę razy mocno się zdziwiłem, że nie mogę od tak użyć jakiegoś pola.

Oprócz "standardowych" braków takich jakich code review, brak testów czy słaba komunikacja z biznesem to najgorzej jakościowo z kodem było:

1. Modyfikacja skryptu do baselinkera:

• wszystko funkcyjnie,
• zmienne global,
• same czyste SQL'e,
• funkcje po kilkaset linii kodu,
• ręcznie napisane funkcje json_decode i json_encode
• konfiguracja wpisywana na sztywno w pliku

Jakimś cudem to działa i działa całkiem w porządku. Ale modyfikacja tego to jest koszmar. Gdyby ktoś był ciekaw jak wygląda taki plik integracyjny mogę podesłać na priv :)

1. Modyfikacja wtyczki do revolution slider. Spaghetti w którym widziałem funkcje z 1000 liniami kodu.

Mjuzik napisał(a):

Oprócz "standardowych" braków takich jakich code review, brak testów
Jakimś cudem to działa i działa całkiem w porządku. Ale modyfikacja tego to jest koszmar

Dlatego te wszystkie review tracenie cennych 30 minut na omówienie kodu, nikomu nie potrzebne testy dostają magicznej odmiany dopiero wtedy gdy projekt musi się zmieniać, ewoluować i dostosowywać do aktualnej sytuacji biznesu i rynku.
Projekty "raz postaw i działa" albo "całą kreację i serwisy za rok i tak zrobi inna agencja" nie potrzebują niczego takiego.

Starszy projekt w C++:

• polskie nazwy funkcji i zmiennych mieszane z angielskimi
• pliki po około 15k linii
• funkcje po 1k linii
• mieszanka c++98 z c++11
• winapi + bardzo stary COM
• kod miał być portable więc w wielu miejscach są ifdefy i mieszanka linuxowo windowsowa
• makra na każdym kroku
• brak dokumentacji, komentarzy i wiedzy na temat produktu. Debugowanie żeby dodać jednego ifa nieraz zajmowało dużo czasu.
• gdzieniegdzie globalne funkcje i globalne zmienne

:( strasznie chce sie w tym wątku wypowiedzieć, ale nie wiem czy chce sobie to przypominać...

Jak tak czytam te projekty to sobie myślę... kiedy weszła bankowość elektroniczna? Jaka była szansa na jakieś bugi? :D

Po najgorszym projekcie w jakim byłem do dziś mam traumę, i to nie ze względu na nie wiem, brak testów albo problemy z zespołem. Akurat zgrany zespół to była jedna z niewielu pozytywnych rzeczy w tym projekcie

• dosłowny CRUD na kilkanaście tabelek, dodaj usuń wyszukaj i do przodu - to jeszcze byłoby do przeżycia, w końcu projekt jak prawie wszystkie
• projekt to był rewrite dymiącej kupy napisanej w Perlu na JVM (z wieloma błędami, niezrozumiale, bez kontroli wersji, z kodem deployowanym ad-hoc w różnorakim stanie, przekazywanym z rąk do rąk w ZIP, filtrowanie gigabajtów!! danych na froncie) - samo ustalenie co właściwie próbujemy odtworzyć było problematyczne
• nawet nie to, że baza CRUDa była współdzielona z innymi. Celem CRUDa było dosłownie pożenienie (i konfiguracja tego "żenienia") dwóch krów third-party przez wspólną bazę.
• nad projektem czuwał wielki pan i władca z USA
• pan i władca miał problemy z napisaniem zrozumiałego emaila, generalnie dawał takie popisy słowotwórstwa i niedbałej pisowni że zarówno Polacy, jak i inni Amerykanie mieli czasami spory problem z rozgryzieniem, o co mu chodzi
• jednocześnie trudno byłoby uświadczyć 3 maile z rzędu bez albo nawrzucania komuś, albo traktowania polskich wyrobników i roboli z góry, albo wykłócania się że przecież tysiąc razy tłumaczył nam i Amerykanom coś w mailach (choć w mailach nie było absolutnie nic na dany temat)
• mając na uwadze powyższe wyciągnięcie jakichkolwiek dokumentacji, informacji "co, jak, dlaczego" wymagało nie lada cierpliwości, gimnastyki, strzelania emailami z karabinu i dodawania pół departamentu do CC, żeby tabun managerów dyszał mu w kark swoją wirtualną obecnością
• jak już udawało się ustalić "co, jak, dlaczego" przeważnie okazywało się, że ktoś zabrał się do sprawy od d**y strony
• wszelkie próby usprawnień, poprawek etc. były torpedowane argumentami w stylu "bo tak", "bo ja tak mówię", "macie robić po mojemu"...

Jeden projekt trafił do mojej dawnej firmy chyba tylko dlatego, że Panowie od sprzedaży zaproponowali klientowi śmiesznie niską cene i nierealny termin. Oczywiscie odbiło się to na kilku zespołach developerow na przestrzeni kolejnych lat. Nie chodzi mi o to, że jednocześnie pracowało nad projektem kilka zespołów, ten projekt spowodował, że kolejni ludzie po prostu uciekali z firmy, gdy ja do niego trafiłem to nie było w nim już nikogo kto przy nim pracował na początku.

No a co sprawiło, że był to według mnie najgorszy projekt?

• Backend napisany w typowej architekturze controller/service/repository. Projekt był jednak na tyle duży, że po otwarciu paczki serwis naszym oczom ukazywało się ponad 30 różnych klas. Oczywiście wszystko rozmawiało ze wszystkim, serwisy miały po 15+ zależności, spaghetti w najlepszej formie.
• Same serwisy miały zawierać konkretną logikę biznesową, trzymano się tego tak sztywno że nie było nawet klas pomocniczych, po prostu cała logika serwisu w jednym pliku, często po 1k+ linii.
• Testy były, coverage minimum 80%... ale niestety 90% kodu testowego to były mocki. Raz zakomentowałem logikę w kilku metodach jednego serwisu - wszystkie testy nadal zielone ;)
• No i frontend... mimo tak rozbudowanego backendu, lwia część logiki była sprawdzana na frontendzie. Backend tak naprawdę wystawiał usługi getAll() i updateAll(), których model to było WSZYSTKO. Ponad 80 tabelek na bazie danych zawartych w jednym DTO, który byl ładowany to Reduxa. Następnie ten model był dzielony między kilka ekranów użytkownika. Zmiana wartości na jednym dropdownie, powodowała odpalenie kilkudziesięciu reguł biznesowych, ktore również mogły zmienić inne wartości. Zmiana tych innych wartości triggerowała kolejne reguły, często więc aplikacja wpadała w infinite loop. Dodatkowo, część komponentów działała na lokalnej kopii modelu, czyli zdarzało się że po zmianie tej wartości na dropdownie i przeliczeniu 100 różnych reguł i przeliczeniu 10 innych wartości, tylko ostatnia z nich została zapisana w store, bo komponent za nią odpowiedzialny pracował na starszej wersji zmian... ciężko to mi nawet wytłumaczyć, do tej pory nikt chyba do końca nie wie co się działo wewnatrz tego systemu, ale sam fakt że zaczęto stosować timeouty, żeby to jakoś skleić, mówi chyba za siebie.
• Z powodu powyższego, zmiana na ekranie Z mogła całkowicie zepsuć ekran A. Ale nie zawsze, czasami timeout zadziałał jak powinien, czasami nie ;) Żadnych testow na froncie też nie było tak więc jedyna opcja by przetestować jednego małego ifa dodanego na ekranie Z, to było dokładne przeklikanie całej aplikacji kilkukrotnie, co zajmowało ponad pół dnia.
• Mimo wszystko, kolejne feature'y były sprzedawane jak wcześniej. W efekcie cały zespół musiał siedzieć przez dwa tygodnie przed releasem do 19:00 - 20:00, rekord to było jakoś 01:00 ;) ostateczna paczka była zazwyczaj gotowa na godzinę przed ostatecznym deadline. Następnie startował kolejny stage, którego jednak nikt nie miał czasu ruszyć przez tydzień bo spływały błędy od klienta z poprzedniego release, a naprawa jednego błędu == zrobienie przypadkiem dwóch kolejnych.

Wytrzymałem jakieś trzy miesiące.

Emdzej93 napisał(a):

Jeden projekt trafił do mojej dawnej firmy chyba tylko dlatego, że Panowie od sprzedaży zaproponowali klientowi śmiesznie niską cene i nierealny termin.
kolejne feature'y były sprzedawane jak wcześniej. W efekcie cały zespół musiał siedzieć przez dwa tygodnie przed releasem do 19:00 - 20:00, rekord to było jakoś 01:00 ;) ostateczna paczka była zazwyczaj gotowa na godzinę przed ostatecznym deadline. Następnie startował kolejny stage, którego jednak nikt nie miał czasu ruszyć przez tydzień bo spływały błędy od klienta z poprzedniego release

To nie projekt był 'do zadka' ale janszerka rządziła w firmie.
Regularne niewyrabianie z czasem i solidne nadgodziny w normalnej firmie oznaczałoby zatrudnienie dodatkowych ludzi.

Emdzej93 napisał(a):

• Mimo wszystko, kolejne feature'y były sprzedawane jak wcześniej. W efekcie cały zespół musiał siedzieć przez dwa tygodnie przed releasem do 19:00 - 20:00, rekord to było jakoś 01:00 ;) ostateczna paczka była zazwyczaj gotowa na godzinę przed ostatecznym deadline.

Abstrachując od tematu wątku, to ja nigdy nie zrozumiem jak można się dawać tak wykorzystywać. U mnie na umowie jak byk widnieje że mam pracować tyle a tyle godzin dziennie, a że nie jestem akcjonariuszem firmy / klientem a od powodzenia projektu nie zależy życie moich dzieci, to po prostu sumiennie wykonuję swoją pracę 8h i wychodzę do domu nie spoglądając za siebie, niezależnie co się tam dzieje.