Wątek przeniesiony 2020-09-27 23:26 z Mobilne przez somekind.

Rynek pracy dla devów Android, jesień 2020

7

Jako programista Androida pracuję kilka lat. Inne działki IT znam raczej słabo, tzn. nigdy w nich nie kodowałem.

Ostatnio stwierdziłem że ten Android zrobił się bardzo zawiły i wymagania są duże, ale takie na moje oko o WIELE większe niż gdzie indziej. Może patrzę przez pryzmat mojej obecnej firmy, a może gdzieś indziej jest spokojniej?

Gdy zaczynałem przygodę z Androidem, to był AsyncTask, Aktywności, jakiś Retrofit (chyba nawet nie) i w sumie tyle. Jak ktoś na rozmowie kwalifikacyjnej wiedział na jakim wątku wykonuje się onReceive z BroadcastReceiver to już był dobry.

Teraz jakieś Daggery, Koiny, Hilty, RxJavy, Roomy (no to relacyjne bazy danych, SQL też wypada znać), mnogość wszelakich komponentów z androidx, wzorce projektowe, antywzorce projektowe, wersji systemu operacyjnego do wspierania i których właściwości trzeba znać jest z 18, budowanie apki na 12 flavorów bo przecież możliwych do testowania konfiguracji apki jest pierdyliard, gradle, Jenkinsy, cykl życia Aktywności, Fragmentu, databinding, Kotlin trzeba znać (a jest to przecież duży temat), oczywiście Javę też no bo połowa apki jest napisana w Javie 5 lat temu no to ktoś musi umieć tam zrobić poprawki, portokół HTTP, jak działa REST, całe wiadro zewnętrznych bibliotek (np. Glide), jak wypuszczać do Play Store, znać trzeba też gita, do tego śmigać po angielsku i jeszcze najlepiej mieć własne repo z 10 projektami open source. Oprócz tego dobrze jest przecież być na topie z Material Designem, umieć tworzyć grafiki w odpowiednich formatach, pisać testy jednostkowe a no i oczywiście też testy integracyjne oraz UI-owe. Właściwie to skoro znasz Javę to czemu nie napiszesz też backendu? A no i tylko czekam kiedy pojawi się następna wersja Androida która zmieni wszystko, wywróci do góry nogami i ty będziesz musiał ją poznać. A tu proszę bug na wersji 4.0.3 sprawdź i napraw. A do tego ogarnij logikę biznesową w wielkim korpo i ją "zakoduj". No i oczywiście szybko bo sprint się kończy. W międzyczasie przerwania co 2h bo kolejne spotkanie Scrumowe. A i nie zapomnij zrobić PR-review dla 6 swoich kolegów z których każdy wie najlepiej jak się kodzi. Oraz popraw swoje 2 PR gdzie ci sami koledzy nawrzucali ci komentarzy co im ślina na język przyniosła.

No nie powiem, ofert dla seniorów jest dużo, stawki pod 20k. Tymczasem dla juniorów nie ma ani jednej. To pokazuje że tzw. "rynek pracy" poszukuje osób z naprawdę szerokim wachlarzem umiejętności. Dla mnie to się robi jakieś szalone.

Czy macie podobne odczucia?

1

Byłem w tym samym miejscu kilka lat temu. Wyszedłem z tego i teraz mam spokojną pracę w której jestem konsultantem dla dużej firmy. Temat jest dość głęboki, możemy się zdzwonić, jak coś to pisz na priv. Podzielę się doświadczeniem.

4

Dlatego apki na androida pisze w angularze :D

3

Zaplaca 20k, a i tak są 30k do przodu, bo robisz za 3-4 osoby.
Dlatego ja opuszczam grono fullstackowcow, cssy, htmle, cssy, angulary, rxjsy, jasminy, reduxy, reacty, ngrxy, bootstrapy, angulary materiale, bazy danych dokumentowe, relacyjne bazy danych, node jsy, c#, Azure, konfiguracja CI/CD, zbieranie wymagań, pisanie maili, wypytywanie, testy, wdrażanie.
Panie, a kiedy programować.

Szukać, szukać i jeszcze raz szukać.
Każdy teraz chce żeby każdy robił wszystko.
A każdy wszędzie robi g**no.

4

Fajny rant - jest w nim trochę prawdy :)

Pamiętaj, że to że Google wypuszcza jakąś fancy libke typu Hilt i jakiś blogger pisze posta to nie znaczy że dzień później musisz to mieć w każdym projekcie. Chociaż słyszałem takie historie, że np. wychodził Room i kolega tydzień później już był z tego przepytywany na iterview (chociaż to bardziej świadczy o niepowadze firmy/rekrutera).

Przy okazji odpowiedziałeś sam na pytanie dlaczego mobilki są całkiem nieźle opłacane - przecież według biznesu zrobienie "apki" to powinna być chwila - 3 ekrany na krzyż i przecież aplikacje na smartfony to takie zabaweczki bardziej ;)

Chyba najlepszym pomysłem jest szukać szukać szukać aż trafisz na firmę i ludzi z którymi sam bedziesz chciał zostać na dłużej. Na szczęscie żyjemy w czasach gdzie opcji jest dużo.

2

Możesz uciec we Fluttera. Jeszcze nowy i nie zdążył się rozbuchać. Przynajmniej tylko jeden język - dart, jak znasz providera to jesteś już gość, a jak jeszcze bloc pattern, to jesteś master i unikat. I to tyle. No może jeszcze testy

Jeśli chodzi o Androida to mam podobne spostrzeżenia. Bez Daggera jesteś śmieciem.

7

Nie wiem jak bardzo jest to szalone dla androida, ale jak pisałem że jestem true backend developerem to został podniesiony krzyk że Java developer powinien znać też JSa. W internecie szaleni archtekci krzyczą że developer powinien znac też sysops (devops) wiec pewnie tez dockera i kubernetesa. A kiedyś krzyczeli że java developer powinien znać też 100 najwyraźniejszych przełączników JVM. Jak na razie temu szalenstwu sie opieram ale powoli zacząłem sie uczyć Dockera i Kubernetesa ale nie wiem ile wytrzymam

2

"A no i tylko czekam kiedy pojawi się następna wersja Androida która zmieni wszystko, wywróci do góry nogami i ty będziesz musiał ją poznać." Pamiętam czasy gdy wychodził android 5 (?) z runtime permissions. Google wprowadził wtedy 2500 zmian do API. Z nasza android-centryczną architekturą potrzebowaliśmy blisko miesiąca żeby odpalić projekt. Zastanowiłem się wtedy jak u diabła nie być w tym miejscu ponownie. Rozwiązaniem było wprowadzenie architektury hexagonalnej (pomysł zaczerpnięty z aplikacji na xamarina)

Mówiąc ogólnie u nas w projekcie mieliśmy moduły które były czysto JVMowe oraz te z androidem. Android zależał od JVMu a nie odwrotnie. W JVMie było tylko Java+Kotlin+Gson+Rxjava+retrofit. Uwaga było tutaj około 70% całej aplikacji. Włącznie z prezenterami. Sam android był tylko rozszerzeniem dla logiki biznesowej zawartej w tym module. Plusy? Przy podbiciu kolejnej wersji PM oszacował że zajmie to około dwa tygodnie, mi zajęło 4 godziny. Fakt były jakieś drobne sprawy do poprawy ( w module z androidem miałem też dobra architekturę), należy pamiętać że nawet jeśli google wywróci androida do góry dnem Ty mając podział 70% pure jvm ( java + kotlin, łatwa stopniowa migracja) + 30% android (activity, fragmens, views) w najgorszej sytuacji masz do przepisania tylko 30% aplikacji. Dzięki temu że de facto to jest mało jest to znacznie szybciej do przepisania.

Cykl życia Aktywności, Fragmentu - z MVVMem się o tym zapomina - fakt trzeba czasem dodać factory dla savedstate ale można to obejść.

Jeśli pracujecie w grupie warto wprowadzić np architecture meetings, tech huddles - cyklicznie spotkania gdzie poszczególne osoby mogłyby prezentować nowości (np Hilt, Koin, androidx, compose etc) a team by decydował czy można dodać to do projektu żeby przetestować, coś jak https://www.thoughtworks.com/radar/tools.

4

Ja osobiście w pracy stosuję kilka zasad które bardzo mi pomagają:

  1. Zmniejsz liczbę zależności w projekcie, jeśli chcesz dodać nową zależność pewnie jej nie potrzebujesz.
  2. Nie walcz z systemem - jakie elementy powinny być klikalne
  3. Rozmawiaj z biznesem na temat w którą stronę aplikacja będzie rozwijana
  4. Ustal zasady gry/ standard pracy z innymi teamami: np z grafikiem ustal że zawsze będziecie używać material design. Dzięki temu jego praca nie będzie dużym zaskoczeniem a w sytuacji "spornej" zawsze można poprosić o link z http://material.io/ jakiego komponentu on użył.

Oprócz tego warto podzielić aplikację na View Component oraz Data.
W View byłby by xmle, jak również recyclerviews, custom views etc. oraz http://material.io/
W Component byłyby Activity, Fragments, może navigation, MVVM / MVP - jako łącznik pomiędzy View oraz Data
W Data to u mnie te czysto jvm moduły, szybkie testy, można czytać jak dokumentacje.

Ja przeszedłem w swoim życiu już asynctask, executors, thread, runnables, loaders, rxjava, coroutines. Wiecie co Wam powiem? W 90% przypadków to jest zwykły fire and callback albo fork and join. Jak programując teraz asynca robię to jak najprostszymi metodami - jak korzystam z rxa to tylko proste operatory np map, flatmap, zip to już max jest. Bo jak google nam coś wprowadzi co nie będzie pasować do naszej konwencji to będziemy penetrowani analnie. Nasz kod ma być łatwy w utrzymaniu, łatwy w zrozumieniu. Rxjava jest zależnością zewnętrzną, jak się w niej zakopiecie to jesteście w czarnej.

1

Nie wiem. Z jednej strony rozumiem problem, z drugiej trochę trudno mi się z tym wszystkim sympatyzować. Moim zdaniem były tylko tak naprawdę tylko dwa przełomowe punkty w środowisku Androida. RxJava i Kotlin. Korutyny może trochę, ale tak naprawdę RxJava (zwłaszcza 2) realizowała wszystko co jest dostępne w korutynach, tylko API jest gorsze, bo nie ma wsparcia na poziomie języka. Wszystko pozostałe to naturalne wykorzystanie wszechobecnych wzorców, które są dostępne wszędzie w programowaniu obiektowym.

Trochę odrębną kwestią są zmiany w samej platformie. Wspomniane pozwolenia przez @lubie_programowac, niedawno zamieszanie ze scoped storage, teraz będzie wchodził Compose, itd. Może na tym polu zmiany są bardziej drastyczne i gwałtowne, ale też zazwyczaj nie aż tak uciążliwe, jeśli aplikacje pisze się od początku jako pluginy do platformy a nie na odwrót. Platforma będzie się rozwijać zawsze i na to nic nie poradzisz. Cały czas będą dochodzić nowe możliwości a wraz z nimi nowe wymagania biznesowe. Kto stoi w miejscu, ten się cofa i inne tego typu mądrości. Przy czym nie uważam, żeby to była specyfika Androida tylko naszego fachu.

Ku pokrzepieniu serc.

1

Persystencja:
Roomy, Gson mapping, SQL, SQL light, Realm, objectbox, shared preferences, file storage - jak wrzucicie wzorzec repozytorium to jeden piec co tam pod spodem jest. Wtedy baza danych jest szczegółem implementacyjnym. Oczywiście dochodzi do tego wydajność np Room będzie szybszy w filtrowaniu elementów niż czytanie jsona przez gsona. Warto tutaj zrobić oszacowanie jak nasze dane będą rosły - jeśli będziemy potrzebować szybkiego filtrowania po ~relacjach np jakieś dane medyczne albo sportowe to room dzień dobry. Ja np w poprzedniej aplikacji napisałem cały lokalny storage w uwaga plikach json które były zapisywane przez gsona. Dlaczego tak? bo znałem skalę jak to będzie rosło, tych plików było max 100 po kilka kilo. 0 Filtrowania tylko key-value. Nie było tam sensu dodawać rooma. Oczywiście samo dodaniei rooma było też dość proste - napisałoby się wtedy kolejne repozytorium + coś ponad tym (pewnie serwis albo use case) który robiłby migrację do nowego rozwiązania.

Dzięki temu można było odroczyć podjęcie decyzji jaka baza danych powinna być użyta. Miałem rozmowę z biznesem: hej lubie_programowac, tutaj masz flow, designy apki na trzy miechy do przodu/

1

A ja uważam, że Android stał się opasły. Sam taki Dagger pewnie już dorównuje Springowi pod względem skomplikowania. Powstaje masa bibliotek i wzorców, które mają przykrywać skopane api Androida.

Flutter upraszcza wiele rzeczy, a z kolei wprowadza nowe problemy. Np serializacja/deserializacja jsona. Nie ma odpowiednika gsona i podobnych, trzeba generować masę boileprate i to wynika ze specyfiki języka. Odpowiednik Retrofita jest, ale ułomny i zmusza do serializacji/deserializacji w wątku głównym, co wprowadza lagi w gui.

W większych projektach zarządzanie stanem aplikacji robi się problematyczne, więc wymyślono providera. Potem wymyślono bloc. Znów to samo, pudrowanie kupy. Powtórka z rozrywki.
Nie można prosto tworzyć różnych flavour aplikacji, bo Flutter nic nie wie o flavour z Gradle, nie mówiąc o iOS. Itd, znów jest na co narzekać.

3

Co prawda nie znam się w dziedzinie Androidowej (jestem javowcem), natomiast kilka rzeczy, spośród wymieniłeś, jak np Jenkins czy HTTP / REST to jest 1 dzień "nauki" i trochę (parę miesięcy np) doświadczenia w komercyjnym projekcie. Jeśli ktoś wymaga 1000 technologii, to raczej chodzi mu o kogoś z T-shaped wiedzą, czyli szczegółową wiedzą w jednym zakresie (np język Java / Kotlin) oraz powszechną wiedzą z wielu innych zakresów, czyli np jakiś framework czy biblioteka - wiedzieć po co ona jest, z czym się dobrze integruje, plusy i minusy. Szczegółów implementacyjnych raczej nie trzeba znać (różnie to jednak bywa - zależy też od firmy i poziomu stanowiska - junior czy senior).

Dlatego np sensowny Bootcamp od zera do java developera powinien zaczynać od 3 miesięcy samej javy - żeby dobrze poznać core, rdzeń tego wokół czego inne technologie będą się kręcić, a nie od razu Java + Spring Boot + Hibernate + REST API

2

Nie rozumiem problemu - identyczny jest dla typowego backendowca czy gościa od frontów. Jak dla kogoś za dużo to ciepła i niewymagająca posada w maku czeka

3

Dobrze płacą za dobre umiejętności także to raczej pozytywny aspekt niż negatywny, że jest czego się uczyć i co udoskonalać :)

2

Chyba nie jest tak do końca. Próg wejścia jest rzeczywiście wyższy, ale wymogi na mid i seniora są niższe. Kiedy ja byłem juniorem to każdy mid był android+druga platforma. Jeden senior i team leader ogarniali 3 platformy. Teraz na seniora nie trzeba znać JNI, a co dopiero drugą platformę.

1 użytkowników online, w tym zalogowanych: 0, gości: 1