jarekr000000

Tak mi się przypomniało (pewnie nie pierwszy raz).

Ponad 20 lat temu dostałem prace w polskim software house.
Już pierwszy dzień to był szok, a potem było tylko lepiej:
Codziennie tony pożarów, projekty z kilkukrotnie poprzekraczanymi terminami, telefony wściekłych klientów, którzy nie tylko przestają płacić, ale i grożą sądem - normalka.
Serwisy dziurawe jak sito -> dzieci się uczyły jak robić SQL injection na naszych stronach (serio - na pierwszej konferencji IT, na której byłem, dowiedziałem się tego od ludzi).
Ogólnie miazga. Repozytorium kodu to folder współdzielony -> samba - trzeba pilnować, żeby nie nadpisać zmian kolegi (średnio 5 razy dziennie awantura z powodu nadpisania.)
(Co jakiś czas korci mnie, żeby (na podstawie tych doświadczeń) napisać książkę dla programistów -> jak wszystko zrobić źle - od zarządzania po implementację i deployment).

Oczywiście byłem po studiach (w odróżnieniu od większości programistów tej firmy) i g**no wiedziałem (doświadczenie: to jeden mały studencki startupik), jednak miałem pomysły jak część rzeczy usprawnić (od organizacji projektu, do zmiany pewnych praktyk programistycznych).
Paru innych gości też miało różne pomysły - bo np. przeczytali choć jedną książkę z dziedziny IT.

I wtedy zawsze pojawiało się magiczne:

• "po kiego zmieniać? skoro zawsze robiliśmy po naszemu i było dobrze. Zobacz ile projektów zrobiliśmy i działają na produkcji"

I wbrew temu co wam się pewnie wydaje... to nie management. Takie podejście głównie reprezentowali inni programiści.

Słyszałem ten tekst później wielokrotnie, od różnych programistów, w różnych firmach, ale nigdy już tak bardzo było dobrze nie było odklejone od rzeczywistości.
Wiedziałem też już, jak bardzo łatwo ludzie potrafią przyzwyczaić się do "this is fine".

Tytuł mnie zaciekawił, bo wiadomo, że java obsysa

Zaczyna się dobrze: od polewu z javowych stacktraców, ale potem autor narzeka na to, że nie może dodać null do int :-)

Z mojego punktu widzenia wadą javy jest to, że w ogóle ten null jest. Tym niemniej, to całkiem dobrze, że nie można dodać tego null do Integera. Słabo natomiast, że w javie można dodać null do Stringa (to jest mały, ale jednak WTF). Strasznie mi przykro, że java nie jest totalną pagologią jak JS albo PHP w tym temacie.

Jest krytyka rozwlekłej składni (przykład mapy) - słusznie.

Powolne streamy, jak najbardziej słuszna krytyka, z tym że to nie jest takie proste. Tzn. nie zawsze jest wolniej, zależy co się robi, ale na pewno streamy nie muszą być w ogóle wolniejsze, można tu dużo w JVM poprawić. Na pewno dużo poprawiono w Graal (ale nie mierzyłem sam - nie wiem jak to obecnie wygląda). Z drugiej strony jeśli się zastanowić ile razy musiałem przepisać streamy na for i tablice, z powodu wydajności to o ile dobrze pamiętam, to mniej niż raz.

Fragment o zmianach w DB, HikariCP - to jakiś WTF, nie wiadomo co właściwie jest problemem, i nie wiadomo dlaczego prezentujący w ogóle myśli, że connection pool miałby coś pomóc. Akurat opisywany przykład to coś co normalnie robi się na jednym połączeniu. Nie wiadomo dlaczego jakaś kolejka miałaby pomóc. Raczej słaby kod i brak umiejętności diagnozy problemu (profilery w javie są relatywnie proste w obsłudze, ale trzeba wiedzieć, że są).

interfejs i metody default - słuszna krytyka, dokładnie pokazuje jak starzeje się język i jak java robi się skomplikowana (twórcy nie chcieli wielodzedziczenia, więc mają wielodziedziczenie i dodatkowo jeszcze kilka słów kluczowych i dziwny warunków (choć tak porypane jak w C++ to nadal nie jest). Tym niemniej, akurat te metody default to rzecz, której IMO nawet się nie dostrzega (przeszkadza prawie w ogóle).

pom.xml i Maven - w zasadzie nie wiem o co prezentującemu chodzi, akurat mavena nie lubie, ale trzeba przyznać, że zależności to jedna z największych zalet javy - masz 100 bibliotek używanych w korpo kobyle, dodajesz sto pierwszą i nic się nie sypie - rzecz do której się przyzwyczaiłem, i luksus o którym sobie przypominam zawsze jak posypie mi się projekt w TS/JS, Scali czy Haskellu.