Czy trafiłem na Janusza?

Witam,

w końcu zdecydowałem się za wyjście poza okno swojego monitora i znalazłem pracę w małym startupie. Niestety nie jestem do końca przekonany czy właśnie tego powinienem oczekiwać. Pracuję w technologii .NET, w pracy mam dostępne VS2015 bez Resharpera(pierwsze wtf?). Pracuje przede wszystkim z 2 ponoć doświadczonymi programistami. Co prawda zagadnienia którymi się zajmują w projekcie są dość zaawansowane, jednak sam projekt to jak dla mnie jedno wielki spaghetti. Brak DI, brak unit testów (zresztą jak bez DI?), jedynie testy integracyjne oraz metody po 100 - 200 linii kodu, wszędzie obładowane reflection. Niestety ciężko się w takim czymś odnaleźć, mimo to team leader jest dość wymagający i po pary dniach pracy oczekuje że będę ogarniał projekt. Nie wiem jak to wygląda w innych firmach dlatego też nie jestem przekonany czy powinienem póki co myśleć o zmianie. Pytanie, trafiłem na Janusza, czy mam wyimaginowane oczekiwania co do jakości komercyjnych projektów?

Pytanie, trafiłem na Janusza, czy mam wyimaginowane oczekiwania co do jakości komercyjnych projektów?

Jedno nie wyklucza drugiego. Też kiedyś myślałem, że większe firmy = lepsza jakość projektów.

trafiłem na Janusza, czy mam wyimaginowane oczekiwania co do jakości komercyjnych projektów?

masz - mogę Ci zapewnić, że nigdy nie znajdziesz ładnego kodu dopóki sam go nie napiszesz - a ten napisany przez Ciebie będzie uważany za spaghetti code przez innych
im mniejsza firma tym jakość kodu pewnie gorsza - mówisz że jest was tam trzech - w tym wypadku jeśli oszczędzono na rekrutacji to projekt będzie zchrzaniony od samego początku bo od dwóch ludzi zależy architektura szkieletu całego projektu

a Janusza nie poznaje się po jakości kodu

brak unit testów (zresztą jak bez DI?)

jeśli uważasz że DI jest niezbędne do pisania unit testów to może jednak coś nie tak

jedynie testy integracyjne oraz metody po 100 - 200 linii kodu

no coś nie tak

wszędzie obładowane reflection

jeśli jest to ukryte gdzieś pod płaszczem to może być sensowne - być może zaglądasz w miejsca w których powinien być tylko senior developer / architekt i stworzono tam framework który pozwoli rozwijać aplikację nawet przez idiotów. A może nie...

mimo to team leader jest dość wymagający i po pary dniach pracy oczekuje że będę ogarniał projekt

z grubsza powinieneś. W moim pierwszym projekcie spodziewałem się wdrożeń w kod, szkoleń z konwencji w firmie, jakiegoś wewnętrznego frameworka, ślicznej dokumentacji, diagramów UML i innych pierdół. W im większej ilości projektów brałem udział tym szybciej łapałem o co w nim chodzi. Nie musisz ogarniać co robi każda metoda żeby ogarniać kod. Po roku w obecnym projekcie nadal 50% kodu nie widziałem na oczy i jest dla mnie czarną skrzynką o której nie mam pojęcia. Jednak gdy zaistnieje potrzeba zmiany czegoś to wiem że będę potrafił to zrobić w locie bez zaznajamiania się z tym kodem bardziej niż do poznania zależności modułu który mam zmienić

Moja propozycja jest taka - jeśli znasz się faktycznie lepiej i wiesz co jest źle to poświęć parę dni na zaznajomienie się z projektem na tyle żebyś czuł się w nim swobodnie, a potem powoli i coraz śmielej narzucaj swoje zmiany. Jeśli projekt jest młody to może uda się go uratować

Jak można pisać kody jednostkowe bez dependency injection? Test jednostkowy powinien sprawdzać pojedyncza metodę, nie zależności między modułami.

Krwawy Kot napisał(a):

Brak DI, brak unit testów (zresztą jak bez DI?)

No co Ty. Ja swego czasu napisałam test do metody z pęczkiem świeżutkich, nowiutkich (new) zależności i operacjami na systemie plików, nieskalanej interfejsami. Dwa dni zeszły jak z bicza strzelił.

Nie jest to dobre miejsce dla Ciebie. Nie znaczy ze znajdziesz coś lepszego łatwo, ale sam widzisz, że Ci się nie podoba. Porozmawiaj z nimi o tym, czemu jest tak a nie inaczej, może mają ku temu powody jednak?
Mimo wszystko... Nie brzmi to na coś sensownego. Nie widzę kodu, więc może nie jest tak źle, ale łatwiej założyć, że to kiepski kod, bo takiego więcej na świecie.
Co nie znaczy że to JanuszSoft, może to projekt do kitu tylko.

Co do testowania i DI - Po pierwsze zależy co rozumiesz przez jednostkę. Czasem lepiej testować cały moduł bez mockowania zależności - integracyjnie. Zależy ile wyjdzie dobrych testów, żeby pokryć całą logikę.
Co do DI, rozumiem, że nie chodzi tylko o brak kontenera do DI, co jest trochę dziwne, ale ogólnie mechanizmów (wstrzykiwania, np przez konstruktor albo do pola klasy), czyli wszystkie zależności są tworzone wewnątrz obiektu - ciężko testować to nieintegracyjnie bo nijak nie zamockujesz tych zależności, chyba że użyjesz biblioteki która potrafi takie cuda robić, bodajże PowerMock sobie z tym radził. Ale raczej świadczy to o kiepsko napisanym kodzie. (Stąd też wniosek wyżej, iż raczej to nie jest dobry zespół i projekt). CO nie znaczy, że nie napiszesz testów. Po prostu będzie to trudne, bardziej niż powinno być, do tego będą to testy integracyjne a nie typowo jednostkowe.