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 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0