Burdel w projekcie

Lider techniczny chce by pisać byle jak i to grubo byle jak. Nie chcę podawać szczegółow bo nie chce być rozpoznany. Sytuacja w projekcie jest napięta i nie chcę żeby np ktoś wykorzystał jakoś fakt pisania na forum.
Nie chce się na to godzić, bo w efekcie to ja jako deweloper będę pisał i ja za to będę odpowiadał.

No i jestem wrogiem bo się czepiam zamiast pracować, a ja nie chcę tak pracować. Czuję się jakby wymagano ode mnie gotowania dania z nieswiezych produktów.

Wychodzi na to że będzie trzeba postawić sprawę na ostrzu noża.

Nie jest to jakiś tzw Janusz soft ale zespół w korporacji z siedzibą w USA. Poza mną jeszcze jeden dew to widzi, też o tym głośno mówi, ale to ja.jestem bardziej twarzą w tym duecie, bo pierwszy się postawiłem i pierwszy powiedziałem głośno o szaleństwie pomysłów lidera technicznegi. Ostatni trzeci programista jest swiezakiem totalnym w branży to korzysta z okazji i siedzi cicho.

Co zrobić?
Jak dodatkowo manager chce mieć święty spokój i gra na czas oraz trochę na tzw emocjach,bo projekt czas ucieka itd.

Mieliście kiedyś taką sytuacją że byliście naklaniani do totalnej bykejakosci, ale takiej że np tylko brak testów w projekcie to przy tym mały pikuś. Powiem jedno - spytałem o testy, na co tech lead, a co już chcesz testować? Teraz wyobraźcie sobie tego typu odpowiedź na każde techniczne pytanie.

Jak sobie z tym poradziliscie?

Jak wyżej - a jeśli to z jakichś powodów nie wchodzi w grę to jest prosta zasada - miej wyj*bane a będzie ci dane. W tym wypadku zasada ta dotyczy ludzi lida technicznego :)

jest takie powiedzenie:

let employee;
while (employees.length) {
    employee = employees.pop();
}
employee.turnOfTheLight();

;)

Byłem kiedyś w podobnej sytuacji: mając dwa lata doświadczenia w branży w androidzie zostałem wysłany w delegację do doliny krzemowej z "liderem" na kilku miesięczny projekt. Lider wylądował na miejscu dwa tygodnie wcześniej. Po przylocie do stanów zobaczyłem projekt: o kur... Jak dla mnie całość do przepisania, zapytanie do bazy danych na 400+ znaków, 0 czystego kodu, 0 testów, overengineering na każdym kroku. Miałem z liderem kilka cięższych rozmów o zmianę tego, wszystkie sprowadzały się do tego: ja jestem liderem ja decyduję a od strony klienta: no hej ale jakie zmiany terminy, przecież działa nie będziemy tego zmieniać! Naszym PO / PM byli ludzie od strony klienta. Co zrobiłem? Największy błąd, zaakceptowałem to. Po kilku miesiącach lider odszedł z firmy a ja zostałem z całym tym bagnem. Miałem później kilka nieprzyjemnych rozmów prawie z każdym szczeblem w firmie - nie polecam.

Co bym zrobił teraz w takiej sytuacji: jeśli jesteś pewien swoich racji alarmuj piętro wyżej ponad lidera, może jakiś line manager? Może na przykład niech inna doświadczona osoba zrobi PR / audyt wewnętrzny Twojego projektu? Warto mieć po swojej stronie osoby które mają więcej doświadczenia i są szanowane w firmie.

Mój ex szef jak się ostatnio dowiedziałem robił już takie czary w projektach, że daty sumowal na stringach/intach (a mógł skorzystać z wbudowanych klas od dat/czasu) no i potem klient dostał informacje o terminach typu 34 październik, albo 27.14.2018.

U takich mentalnych Januszow widziałem już takie scenariusze
S: "ej, dopisz mi tu funkcjonalność"
Ja: "ale to potrwa minimum 2 dni robocze"
S: "no ale to przecież wystarczy ifa jednego dodać, co Ty będziesz to dwa dni pisał?"
Ja: "wbrew pozorom jest tam więcej zależności i jak dostawie ifa to to pier.olnie"
S: "rozumiem, ale wiesz.. To co już mamy działa i nie mamy czasu na takie rozgrzebywanie kodu"
Ja: "ok"

Po określonym czasie (tydzień, max miesiąc)
Klient: "panowie. Nowa funkcja działa dobrze, ale nie możemy teraz zrobić x, y, z"
Szef do mnie: "no to dlaczego to tak kiepsko napisane i niedziala? Ile czasu zajmie Ci naprawa?"
Ja: "no teraz odkrecenie tego to już zajmie z 3 dni"
S: "to Ty takich prostych rzeczy nie umiesz zrobić? I tyle czasu Ci trzeba.... Ehhhh, daj mi ten kod to sam dopisze"
Po tygodniu
Szef do mnie: "Spier.olilo się na amen, pomush [sic!]"

Jak to u nas się mówi, nie warto kopać się z koniem. Dokończ projekt, a w międzyczasie szukaj innej roboty.

Ech nawet nie wiesz jak ky wszyscy Cię rozumiemy. U nas jest w projekcie dociągnę ponad 90 randomowych gemow, juz o backdoorach czy innych podatnosciach nie wspomnę. Plus jest taki ze mlody za 3 miesiące odchodzi do innego teamu, więc mówimy mu co jest zwalone, ostatnio nawet funkcjonuje tekst: Jak zrobisz cos takiego jak tutaj to odesla cie do nas z reklamacja.:)

Jeśli to nakłanianie do bylejakości
To montuj spierdolkę.

Tracisz czas, kiedy inni programiści w innych firmach uczą się jak pisać kod coraz lepiej (a to neverending story). Będziesz coraz bardziej z tyłu.

Jak ten lider pisze i robi ten bajzel to pewnie tylko on się w nim rozeznaje i jeszcze będzie wychodzić, że tylko on umi kodować :-)

W międzyczasie wysyłaj linki i artykuły do wszystkich na temat konkretnych zasad kodowania, jakie macie naruszone, to czasem minimalnie przemawia do managementu.
Zwłaszcza jak uda się powiązać bug z konkretnym przypadkiem. Powracające błedy to np. często wynik braku testów.
Pomożesz chociaż innym programistom trochę.

często słabsze firmy stosują metodę na "zamęczenie" klienta, po prostu przyjmują poprawki, nieudolnie je implementują, potem to wraca i tak w kółko, klient z czasem je odpuszcza (chcąc mieć produkt, bo termin goni) firma wykonująca ma to gdzieś, bo ciągnie takich projektów kilka, więc nawet jak spłaty się przedłużają to ma je z kilku (też nowych) źródeł, więc tak czy inaczej ktoś zapłaci, a reszta jest "męczona" :)

W słabym kodzie też trzeba umieć pracować.
Trzeba wiedzieć kiedy można zrobić refaktoring (np. po implementacji testów).
Trzeba umieć zacisnąć zęby jak widzisz private final class xxxUtil z logiką biznesową.
Albo for który nie jest pętlą - to akurat przypadek z tego tygodnia.
Po prostu odpalasz n analiz statycznych i to co możesz naprawiasz.
I nie wymądrzasz się bo na studiach to nam mówili że tak się nie robi. Bo może lead dawno o tym wie, tylko też ma związane ręce.

Polecam narzędzia:

• Checkstyle
• Sonar
• IDEA \ analiza kodu
• FindBugs

Uciekać. Ja jestem juz na wypowiedzeniu, sytuacje podobne. Najpierw robimy demo technologiczne żeby sprzedać pomysł, wtedy jest gadka "zrób jak najszybciej i byle jak, jak kupią projekt to zrobimy na porządnie". Po miesiącu klient się zdecydował i słyszę "No to połowę roboty już mamy, dopisz do tego reszte funkcjonalności", i lead rzeczywiście wycenia mi projekt na połowę realnego budżetu, FML