Wątek przeniesiony 2020-04-13 23:11 z Edukacja przez cerrato.

Technologie hybrydowe czy natywne?

0

Witajcie,
rozważałem założenie tego tematu w dziale "Kariera" - ostatecznie padło tutaj. Jak pomyłka to proszę o przeniesienie :)

Mam 21 lat, od ~ roku działam zawodowo w Androidzie. W między czasie miałem również okazję, jednak mocno pobieżnie (raptem 2 aplikacje biznesowe) zapoznać się z iOS.
Ostatnio za sprawą większej ilości wolnego czasu na studiach (albo i może przez epidemię :) ) zacząłem zastanawiać się nad kierunkiem rozwoju. Czy brnąć w technologię natywną i dalej odkrywać Androida (oraz dorzucić iOS)? Czy lepszym pomysłem w dzisiejszych czasach byłby jakiś React Native / Flutter - jednym słowem hybrydy.
Zdaję sobie sprawę z ograniczeń hybryd, jednak nie wiem czy nie warto zacząć się nimi mocniej interesować :) Pracę mam w Androidzie, jednak mając wiedzę z hybryd w aktualnej firmie też bym miał co robić + obecny rynek pracy zdaje się faworyzować React'a nad natywnym Androidem (w PL Flutter wydaje się chyba czymś egzotycznym).

Jakie są wasze przemyślenia na ten temat? Co Wy byście zrobili na miejscu juniora - w którym z tych dwóch kierunków podążali?

3

Zanim zaczniesz pracę, to trzy razy projekty będą zgaszone / nowe, firmy kupione / sprzedane, modne fronty przestaną takimi być itd..

Trzeba nauczyć się uczyć.

0

Doskonale wiem, że nasz zawód wiąże sie z nieustanną nauka - zwłaszcza jak ktoś rozwarza zabawę z frameworkami JS. Moje pytanie było zgoła inne.
Co w obecnej chwili oraz bazując na doświadczeniu dotyczącym dynamiki IT (moje jest zbyt małe by szacować kierunki rozwoju) Wy byście zrobili. Skupiali się zawodowo na natywnych technologiach i w nich sie dalej rozwijali? Czy większość wolnego czasu przerzucili na hybrydy i natywnymi sie ewentualnie wspierali?

1
Zielony Banan napisał(a):

Doskonale wiem, że nasz zawód wiąże sie z nieustanną nauka - zwłaszcza jak ktoś rozwarza zabawę z frameworkami JS. Moje pytanie było zgoła inne.
Co w obecnej chwili oraz bazując na doświadczeniu dotyczącym dynamiki IT (moje jest zbyt małe by szacować kierunki rozwoju) Wy byście zrobili. Skupiali się zawodowo na natywnych technologiach i w nich sie dalej rozwijali? Czy większość wolnego czasu przerzucili na hybrydy i natywnymi sie ewentualnie wspierali?

Osobiście w natywne, hybrydy fajne, Flutter jest nawet bardzo fajny, ale osobiście wolę pisać natywnie iOS/Android. Jak zajdzie taka potrzeba to mogę robić we Flutter, ale jak dla mnie wolę mieć solidne doświadczenie w rozwiązaniach właśnie natywnych, co wg. mnie daje więcej na przyszłość.

1

Jedno i drugie, native w jednej platformie jako specjalizacja + hybryda jako dodatkowy atut. Ogólnie hybrydy to rozwiązania budżetowe albo gdy potrzeba PoC dla inwestorów. Na dłuższą metodę utrzymanie tego to mordęga bo i tak potrzebujesz na pewnym etapie dotknąć natywnego API.

Tylko jako cel dla świeżaka to mobile IMHO jest średnim wyborem. To już dojrzały z naciskiem na schyłkowy rynek gdzie żyła złota się skończyła ;) Ofert za duże pieniądze jest stosunkowo niewiele, zazwyczaj trzeba się babrać w archeologii. Dodatkowo nie wiadomo czy za parę latek PWA nie zeżre wszystkiego ograniczając native support do tych niewielu przypadków gdzie inaczej się nie da.

1

Wątpię w to, że PWA cokolwiek zmieni. Gdyby tak miało być, to by już było. PWA istnieje już od dawna i jakoś zbytnio nie widać, żeby wszyscy porzucali aplikacje mobilne na rzecz PWA. To tylko ciekawostka i raczej to się już nie zmieni.
Co do hybryd, to przyjmą się tylko te, które po pierwsze nie dają żadnego narzutu w kwestii wydajności (czyli Xamarin od razu odpada), a po drugie działają stabilnie (czyli odpada ReactNative i częściowo Xamarin, zwłaszcza Xamarin Forms).

Xamarin i ReactNative będą dalej tkwić w tych niszach, w których są dziś, programowanie natywne to dalej będzie większość, a Flutter będzie rósł w siłę powoli (chyba, że Google da ciała) przede wszystkim dlatego, że będzie najbardziej kompatybilny z Androidem (w końcu to Google), nie generuje praktycznie żadnego narzutu i działa znacznie stabilniej, niż ReactNative. I nie mniej ważne, bardzo łatwo przesiąść się z ReactNative na Fluttera, sam znam kilka przykładów firm rozczarowanych problemami z ReactNative, które przeszły z sukcesem na Fluttera.

Jeśli bym miał doradzić, w co iść teraz zaraz żeby łatwo znaleźć pracę na dłużej, to Kotlin lub Swift/iOS. A dodatkowo, myśląc przyszłościowo, warto uczyć się Fluttera, bo nadchodzi czas, gdy jego znajomość będzie bardzo przydatna. W ReactNative czy Xamarina nie radziłbym inwestować swojego czasu, to nie ma większej przyszłości. Ani jeden, ani drugi nie zdobędzie już większej popularności niż ma, a ja przewiduję wręcz powolny spadek zainteresowania nimi.

4

Jak coś ma być zrobione szybko i tanio to hybrydy. Jak coś ma być zrobione dobrze i drogo to natywnie.

Oba te pojęcia są rozłączne, tak samo jak łączenie Androida z iOS mi się nie klei.

W dużych korpo masz natywnie a devowie nigdy nie robią obu systemów na raz bo musisz być ekspertem w głąb technologii a nie wszerz (każda z tych technologii ma tyle zakamarków że pojęcie tylko jednej z nich zje cały twój czas do emerytury a to są żywe, wciąż powiększające się światy).

W małych januszexach (lub będąc freelancerem) częściej musisz zrobić coś szybko i od razu na wszystkie możliwe platformy (więc raczej hybryda) i jeszcze samemu backend postawić, grafiki pociąć itp. itd. A że czasem React będzie mulił a serwer będzie się wieszał januszexa mało obchodzi.

1

@Roman Mokrzan: wydaje mi się trochę niefajne, że wrzucasz wszystkich piszących nie natywnie do jednego wora i nazywasz ich Januszami.

1
Roman Mokrzan napisał(a):

łączenie Androida z iOS mi się nie klei.

Tobie może się nie kleić. Ale dla twórców Androida to się jednak klei, Google od dłuższego czasu dostarcza swoje usługi (mapy, Firebase i inne) także na iOS. A teraz dostarcza cały framework - Flutter. Dlatego to nie jest to samo, co ReactNative czy Xamarin, gdzie to firma trzecia lub w zasadzie tylko społeczność stara się coś sklecić z miernym skutkiem.

2
Zielony Banan napisał(a):

Doskonale wiem, że nasz zawód wiąże sie z nieustanną nauka - zwłaszcza jak ktoś rozwarza zabawę z frameworkami JS. Moje pytanie było zgoła inne.
Co w obecnej chwili oraz bazując na doświadczeniu dotyczącym dynamiki IT (moje jest zbyt małe by szacować kierunki rozwoju) Wy byście zrobili. Skupiali się zawodowo na natywnych technologiach i w nich sie dalej rozwijali? Czy większość wolnego czasu przerzucili na hybrydy i natywnymi sie ewentualnie wspierali?

Tutaj jest długa historia. Zgodnie z hasłem: "Żyj tak aby kochać się uczyć" zaczerpniętym z https://static01.helion.com.pl/helion/okladki/326x466/jakpro.jpg chciałbym nakreślić kilka przemyśleń:
Nasz zawód wiąże sie z nieustanną nauka - ogólnie to jest prawda. Natomiast jeśli uważasz że ciągła nauka w świecie IT dotyczy nauki nowych technologii to nie do końca jest prawda. (Notabene sam napisać mądre słowa w kolejnym zdaniu że możesz mieć wąskie pole widzenia z powodu małego doświadczenia). Należy nauczyć się rozmawiać z biznesem, szacować koszt podjętych decyzji, ustalać priorytety na zadania, różnych podejść np. lean. I teraz tak:

  1. Nauczyłem się programować czysty agnostyczny kod - dzięki temu dodanie wsparcia do nowej wersji androida trwa godziny / dni a nie tygodnie.
  2. Nauczyłem się rozmawiać z biznesem: ustalać kolejność zadań w celu minimalizacji ryzyka, time to market oraz ogólnie w celu uzyskania przewagi konkurencyjnej.
  3. Nauczyłem się pragmatyzmu, podejścia lean - należy się zastanowić nad kosztem jaki przyniesie zmiana. Jestem wielkim zwolennikiem automatyzacji pytanie czy poświęcenie trzech dni na automatyzację np. wpisywania wersji w aplikacji podczas jej wydania jest sensowne. Taka ręczna zmiana np trwa 5 minut raz na dwa tygodnie vs 3 dni czyli 24 godziny. Ten czas lepiej przeznaczyć na pisanie smoke testów BDD na farmie firebase oraz szkolenie klienta w celu poprawienia sposobu przygotowania przypadków testowych.

Wracają do Twojego pytania: patrząc z perspektywy ośmiu lat programowania na androidzie, pracy nad wieloma projektami z czołówki światowej mogę Ci poradzić:

  1. Ja poszedłbym w technologie natywne - jest bardzo dużo stabilnych projektów które wymagają utrzymania. Może nie brzmi to bardzo satysfakcojnująco ale ja ogrom wiedzy zdobyłem właśnie na utrzymaniu.
  2. Równolegle ucz się rozwiązań które spowodują że przeskoczenie do nowej technologii będzie dużo prostsze. Mówię tutaj o czystym kodzie czy podejściu agnostycznym.
  3. [zwłaszcza jak ktoś rozwarza zabawę z frameworkami JS] - z podwórka androida wygląda dla mnie to tak że ja np migruje pewne moduły w aplikacji np co dwie zmiany. Nie śledzę androida cały czas, nie jestem z najnowszymi rozwiązaniami na bieżąco. Dzięki pragmatyzmowi dążę w projekcie do minimalizacji liczby
    liczby zależności - dzięki temu nie muszę rozwiązywać problemów które nie powinny istnieć.

Mogę później podesłać Ci kilka książek które warto przeczytać. Sam ostatnio kupiłem PMBOK, uczyć trzeba się cały czas ;)

3

Książki:
Rozwój programisty:
The Complete Software Developer’s Career Guide, John Sonmez
Becoming a Better Programmer, Pete Goodliffe
The Clean Coder: A Code of Conduct for Professional Programmers, Robert Cecil Martin
The Pragmatic Programmer: From Journeyman to Master, Andy Hunt and Dave Thomas
Leaders eat last, Simon Sinek
The secrets of consulting, Gerald Weinberg

Sztuka programowania:
Clean Code: A Handbook of Agile Software Craftsmanship, Robert Cecil Martin
Design patterns : elements of reusable object-oriented software, Erich Gamma, John Vlissides, Richard Helm, Ralph Johnson
Working Effectively With Legacy Code, Michael Feathers
Rapid development, Steve McConnell
Refactoring to Patterns, Joshua Kerievsky

Testowanie:
Test-Driven Development by Example, Kent Beck

Architektura:
Clean Architecture: A Craftsman's Guide to Software Structure and Design, Robert C. Martin
Just Enough Software Architecture: A Risk-driven Approach, George Fairbanks
Patterns of Enterprise Application Architecture, Martin Fowler

Zarządzanie projektem:
Peopleware: Productive Projects and Teams, Timothy Lister and Tom DeMarco
The Mythical Man Month, Fred Brooks
Agile Product Management with Scrum, Roman Pichler
Learning Agile: Understanding Scrum, XP, Lean, and Kanban, Andrew Stellman
Management 3.0, Jurgen Appelo
Project Management Body of Knowledge, Project Management Institute

Domena:
Domain-Driven Design Distilled, Vaughn Vernon
Domain-driven design, Eric Evans

Strategie w biznesie:
The Lean Startup, Eric Ries
Start With Why, Simon Sinek
Good to Great: Why Some Companies Make the Leap...and Others Don't, James C. Collins
Blue Ocean Strategy, W. Chan Kim, Renée Mauborgne
Zero to One, Blake Masters and Peter Thiel

OKR / KPI:
Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, John Doerr
High Output Management by Andy Grove

Zdecydowaną większość w/w pozycji posiadam/przeczytałem. Książki są posortowane (według mnie oczyście) według ~trudności. Polecałbym przeczytać pierwszą pozycję z każdej grupy - wszystkie ze sobą tworzą dobrą synergię. Sama kolejność grup też nie jest przypadkowa.

Blogi które mam dodane do zakładek: (tutaj kolejność przypadkowa)
https://www.yegor256.com/best.html
https://www.joelonsoftware.com/
https://hillelwayne.com/post/
https://exceptionnotfound.net/
https://handstandsam.com/category/kotlin/
https://blog.ploeh.dk/2015/08/10/type-driven-development/
https://dariuszwozniak.net/kurs-tdd/
https://hackernewsbooks.com
https://martinfowler.com/bliki/WaterfallProcess.html
https://engineering-management.space/
https://lethain.com/forty-year-career/
https://blog.pragmaticengineer.com/
https://randsinrepose.com/archives/
https://news.ycombinator.com/
https://danluu.com/p95-skill/
https://boardofinnovation.com/
https://fs.blog/mental-models/

Na yt można znaleźć bardzo dużo materiałów, z polskiej społeczności polecam:
Sławomir Sobótka - DDD
Jakub Nabrdalik - testy + java
Jakub Kubrynski - architektura + biznes
Mariusz Gil - zarządzanie projektami + biznes

Jak na osiem lat pracy androida jest tam mało androida. Z tej działki polecam:
The Busy Coder's Guide to Advanced Android Development, Mark Murphy
https://codelabs.developers.google.com/
https://developer.android.com/docs

https://material.io/design/

3
Meini napisał(a):
Roman Mokrzan napisał(a):

łączenie Androida z iOS mi się nie klei.

Tobie może się nie kleić. Ale dla twórców Androida to się jednak klei, Google od dłuższego czasu dostarcza swoje usługi (mapy, Firebase i inne) także na iOS. A teraz dostarcza cały framework - Flutter. Dlatego to nie jest to samo, co ReactNative czy Xamarin, gdzie to firma trzecia lub w zasadzie tylko społeczność stara się coś sklecić z miernym skutkiem.

No dokładnie - MI się nie klei - to jest forum i ktoś wrzuca filozoficzne pytanie lepsze jabłko czy tramwaj. To wyrażam swoją opinię, wkładam kij w mrowisko, sieję zamęt i mącę wodę bo do tego służy taki byt jak to forum. Może ktoś mnie do czegoś przekona. Może zmienię zdanie. Może nie zmienię.

0

Mnie nie klei się przede wszystkim coś innego. Gdy jakaś inna firma próbuje pisać taki framework bez wiedzy i wsparcia twórcy systemu operacyjnego. To się zawsze kończy źle. Zwłaszcza, gdy ta firma to Microsoft albo Facebook i gdy używane do tego jest Mono albo JavaScript.

W przypadku Fluttera mamy jednak tu coś nowego.

0

Przerobiłem tutorial Darta i stworzyłem te aplikację Generator Słówek. Jak teraz ruszyć dalej ten temat, przerabiać kody innych apek z githuba? Ogarnąć bardziej ze szczegółami język Dart?
Do zabawy i nauki konsolowymi programami nie instalowałem tego kompilatora Dart lub VM czy jak go tam nazywają. Po prostu dodałem ścieżkę w IDE do Darta z tych rozpakowanych plików Fluttera, to może mieć jakiś negatywny wpływ, skoro programy Dart dobrze kompilują się w edytorze? Maszyna wirtualna Darta działa na tej samej zasadzie co Node V8? Dlatego nazywam ją VM ponieważ inni programiści z ponad 30 letnim doświadczeniem programistycznym, też tak ją nazywają.
youtube.com/watch?v=CsyrvKoKKXQ

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