Rant po toolach w stylu Mavane, Gradle, Bowera i całej tej hałastry

Będzie rant...

Wszystkie Maveny, Gradle, Bowery,  NPMy, Webpacki i cały ten chłam są narzędziami do rozwiązywania problemów trywialnych, które wprowadzają problemy poważne...

Nagle przez użycie któregoś z tych narzędzi Twój projekt staje się zależny od Internetu, od widzimisię różnych programistów i masy rzeczy na które nie masz wpływu.

Nagle z programisty Java'y, JavaScripta czy czegoś podobnego musisz stać się jeszcze ekspertem w kryptycznym XMLu, Groovy'm i JSONie.

Co jest najczęstszym źródłem problemu w firmach gdzie używa się Nexusa albo NPMa?
Najpierw to, że "wolno".
To ktoś wpada na pomysł "zrobimy sobie lokalne repozytorium".
A później przez kilka lat ludzie walczą z tym, że to lokalne repo nie jest do końca zgodne z tymi w Internecie....
A jak ktoś wpadnie na to by w różnych lokalizacjach mieć lokalne klony repa to jest jeszcze zabawniej.

W spróbujcie pożenić 2 takie systemy razem....

Ja mam teraz tak, że moje Android Studio spokojnie może skompilować aplikację, wszystko działa... ale sam edytor pokazuje na czerwono typ Tracker (com.google.android.gms.analytics.Tracker)... który nie jest też widoczny w UnitTestach....

W dawnych czasach poszukałbym gdzieś na stronach Google JARa z tą klasą, wrzucił do projektu i voila wszystko by działało...
Ale nie, teraz muszę robić doktorat z Gradle'a żeby ustalić co się dzieje.....

A wszystko przez to, że kiedyś ktoś uznał, że lepiej dodać komplikację rozwiązując trywialny problem zależności*.


* - bo to jest trywialny problem, po prostu trzymaj zależności jak najprostsze, jak Ci się zaczynają komplikować to masz coś nieteges w architekturze. Jak nie możesz zapanować nad JARami z 3rd party libraries to używasz ich po prostu ZA DUŻO.


Podobne posty^beta
Gdzie popełniliśmy błąd?
Może mi ktoś wytłumaczyć po co istnieją GWT i GWTP?
Taki tam rant po Gradle i Dockerze ;-)
Rant śmietnikowy ;-)
Electron + Airly = wskaźnik jakości powietrza w pasku ;-) - part 2, źródła ;-)