Czy Java zazwyczaj oznacza pracę przy nudnych projektach w korpo?

Jak w temacie. Czy ktoś z was pracuje przy "ciekawych" projektach jako programista Java?

Jeden rabin powie tak... Inny rabin powie nie...

Pracowałem przy wielu ciekawych projektach w Javie.
Patrzysz na kod, unosi Ci się jedna brew i mówisz:
Ciekawe......

Powinieneś zadać jeszcze dodatkowe pytanie, czy Java zazwyczaj oznacza pracę w projektach reliktach z Javą 1.6 ;)

Miałem kilka projektów na java 6 i 7 - wszystkie wyciągnąłem do Javy 8 minimum. (w kilku przypadkach to było trudne).
Jak ktoś siedzi na Javie 6 (bo np. websphere) to trzeba spadać. Skoro nie ma kasy na podciągnięcie do nowej wersji to pewnie nie ma też kasy na to żeby pisać dobry kod z testami i refaktorować. Skoro projekt nie ma kasy to warto go opuścić i dać umrzeć.

Zastanawia mnie co autor miał na myśli z "Ciekawy projekt". Opisz mi proszę jak wygląda dla ciebie ciekawy projekt.

W sumie też mnie nurtuje to pytanie. Tylko odpowiedzi tak/nie raczej niewiele powiedzą.
Możecie podać przykład takiego ciekawego projektu w Javie?

mysle ze jest sporo fajnych projektow i czesto tez mozna nudny projekt zrobic ciekawym przez robienie go po swojemu (bo zazwyczaj nikt ci nie zabroni).
pewnie jakis system dla hr'ow do wklepywania urlopow nie bedzie specjalnie ekscytujacy ale juz np. wiekszosc programistow hft nie patrzy goraczkowo na zegarek bo im sie dniowka dluzy ;)

Pieniądze zarabia się zwykle na nieciekawych projektach, niezależnie od języka. Na ciekawy projekt możesz trafić, ale musisz odsiać firmy na rozmowie kwalifikacyjnej. Rozmowa kwalifikacyjna powinna właśnie działać w obie strony - nie tylko, żeby firma dowiedziała się, że kandydat spełnia wymagania, ale także by kandydat dowiedział się, że firma spełnia jego wymagania.

Inną sprawą jest to, że można stare projekty modernizować i to też może być fajne. Masz już gotowy produkt, użytkowników, realne problemy z n.p. skalowalnością i trzeba te problemy naprawić. Jeśli wypracujesz sobie zaufanie u zarządu (poprzez skuteczne naprawianie problemów i dostarczanie solidnie działających funkcjonalności) to możesz dostać zielone światło na potrzebne modernizacje. Sam projekt jednak powinien się dać stopniowo modernizować, a w tym moim zdaniem najlepiej sprawdza się architektura oparta o mikroserwisy połączone RESTem (HTTP + JSON) lub innym protokołem, który jest równie kompatybilny ze wszystkim dookoła. Mikroserwisy można modernizować jeden po drugim, bez przestoju w rozwoju całego systemu.

Ciekawy Duży Projekt to było przepisać twitter z Ruby on Rails do Scala/Java?

jarekr000000 napisał(a):

Miałem kilka projektów na java 6 i 7 - wszystkie wyciągnąłem do Javy 8 minimum. (w kilku przypadkach to było trudne).
Jak ktoś siedzi na Javie 6 (bo np. websphere) to trzeba spadać. Skoro nie ma kasy na podciągnięcie do nowej wersji to pewnie nie ma też kasy na to żeby pisać dobry kod z testami i refaktorować. Skoro projekt nie ma kasy to warto go opuścić i dać umrzeć.

A mógłbyś napisać, jak się do takiego "wyciągania" zabrać? Z czego wynikały trudności? Właśnie wrzucili mnie w taki projekt (Java 7, EJB, biblioteki z 2013/2014. Jakość kodu: jedna z klas ma 6500 linii i jest tam dużo innych "kwiatków").

ciekawi mnie geneza powstawania takich klas po 6,5k linii

Java 7 to już nie najgorzej wróży. Największy problem to application serwer i czy możecie podbić łatwo wersję do takiej, która obsługuje Java 8.
Jak się zabrać? To zależy od projektu.
Raczej nie jest problemem brak Javy 8 tylko syfny kod.
Generalnie:
Ogarniać kawałek testami i poprawiać. Testy nie muszą być szczegółowe. Dla takiego systemu wystarczą integracyjne na początek - robimy dumpa bazy danych, a potem piszemy troche scenariuszy
jeśli to i to wywołamy to wynik bedzie taki (Black box).

Wprowadź zasadę, że nie dostawiasz po prostu kolejnego IFa tylko zawsze przy modyfikacjach choć lekko poprawiasz kod. Uwzględniaj to w szacunkach. 2 dni na IFa -> 1-2 dni na lekki refaktoring.
Moim trickiem jest dodawanie metryk (cyclomatic complexity itp) i pokazywanie czy się poprawiają / pogarszają. (Sonar takie rzeczy pokazuje).

No i najważniejsze - cały zespół musi pracować "na plus". jak będziesz miał olewaczy syfiarzy... to niewiele się da zrobić. Róbcie sobie wewnętrzne szkolenia z poprawiania kodu.

Poza tym jest też książka z różnymi pomysłami i zasadami (już mi troche wyleciała z głowy, ale na pewno kiedyś pomagała) https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

Ważna jest zasada skauta czyli znam się i poprawiam. Gorzej jak ktoś ją stosuje i robi jeszcze większy syf :) U mnie w pracy w innym zespole jest projekt javowy, który pod właściwym kierownictwem ogarniętego gościa, który później został architektem, wyszedł na naprawdę elegancki kawałek kodu. Mieli toto w javie 1.6 i springu, bez pokrycia testami i ogólnie rzeźba w spaghetti. Sonar po załączeniu pokazał 542 dni długu technicznego. Stopniowo przepisywali bałagan, pokrywali testami, zatrudnili nowych i dobrze ogarniających ludzi i koniec końców teraz mają dobrze pokryty testami projekt, w którym nawet najstarsza część springowa śmiga na javie 1.8, a resztę podzielili i zrobili w spring boocie. Ważne jest, by ktoś miał wizję i umiejętności, by zrobić coś więcej niż dopychać na siłę ficzery metodą copypaste.

filemonczyk napisał(a):

ciekawi mnie geneza powstawania takich klas po 6,5k linii

Tu jest wyjaśnione :-)

jsc napisał(a):

Jak w temacie. Czy ktoś z was pracuje przy "ciekawych" projektach jako programista Java?

Jak wylądujesz w korpo to istnieje duże prawdopodobieństwo, że trafisz na jakiś zasyfiony projekt. Są jednak alternatywy w postaci np. software house, które piszą projekty w Javie. Tam masz pewność używania świeżej Javy 8/9 i technologii w okół również aktualnych.
Takich miejsc co prawda jest niewiele i zapewne ciężej się do nich dostać ale jakby ktoś pytał to są i oferują całkiem sensowną jakość pracy. A na pewno lepszą niż w miejscach z setkami koderów...

Autorze a ile masz lat że szukasz fajerwerków?