Що має знати Senior Android Developer. Аналіз вакансій на DOU

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

У дев’ятому випуску рубрики «Що має знати Senior» розглядаємо вакансії Senior Android Developer, опубліковані на DOU у вересні та жовтні 2021-го. У дослідження потрапили 38 вакансій від різних компаній.

Вакансії яких компаній потрапили в дослідження?

4IRE, AgileEngine, Ajax, appflame, AUTODOC, Brightgrove, BP Mobile, Capgemini Engineering, Envion Software, FORM, GlobalLogic, Godel Technologies, Intellias, itransition, JMIND, KitRUM, Leia Labs, Levi9, Lyft, Newxel, N-iX, NCube, Pinngle, Postindustria, Product Madness, Raiffeisen Bank, Reface, Sigma, SPD-Ukraine, SoftServe, Svitla, Tango Me, Transcenda, Vimeo, Wirex, Yalantis, Zenia, ПУМБ.

Reface не використовує тайтли, але я все одно додав у дослідження їхню вакансію Android Developer, яка вимагає чотири роки досвіду. Компенсація до $6000.

Також у дослідження потрапила вакансія Android Developer від Lyft, у якій серед вимог 6 років досвіду та знання англійської на рівні Advanced.

Досвід, освіта, англійська

Маючи три роки досвіду, можна вже претендувати на Senior-позицію. Кожна п’ята компанія готова взяти на роль Senior спеціаліста з мінімальним досвідом.


Освіта рідко відіграє роль, але все ж трапляються вакансії, де вона необхідна.

Capgemini Engineering (колишня Lohika) запрошує на проєкт у медичній галузі. Потрібно мати профільну вищу освіту та досвід роботи з Bluetooth Low Energy.

GlobalLogic шукає Android-розробника з експертним знанням C/C++ на проєкт в автомобілебудівній галузі. Обов’язкова профільна вища освіта, а також досвід розробки з використанням Linux.

Щодо англійської, то Intermediate може бути достатньо, щоб претендувати на Senior-позицію. Кожна п’ята компанія готова взяти на посаду Senior Android Developer спеціаліста з таким рівнем. Однак розмір винагороди буде відрізнятися залежно від рівня володіння англійською.

За традицією погляньмо на цифри. Альтернативний зарплатний віджет, який базується на даних останнього зарплатного опитування DOU влітку цього року, дає для Senior Kotlin Developer такі дані:

Intermediate. 30 анкет. 3990 доларів на місяць після податків.
Upper-Intermediate. 51 анкета. 4041 долар.
Advanced. 9 анкет. 4780 доларів.

Закономірність незмінна. Удосконаливши свою англійську з Intermediate до Advanced, можна сподіватися на підвищення доходів на (4780 — 3990) x 12 = 9480 доларів на рік.

Однак хочу зауважити, що компанії рідко відкривають вакансії, у яких рівень Advanced був би зазначений хоча б як «would be a plus».

Щодо інших мов, окрім англійської, то жодна компанія не вказала їх у вимогах. Але, вочевидь, в деяких компаніях знання додаткових мов може знадобитись. Так, в AUTODOC, за винятком звичних курсів англійської, пропонують оплачувані курси німецької та навіть польської.

Комп’ютерні науки, архітектура, мови програмування

Приголомшлива новина в тому, що 92,1% вакансій не згадують алгоритми як обов’язкову компетенцію для Senior Android Developer. Що вже говорити про інших, коли навіть у вакансії Lyft, американського сервісу таксі з мільйонами користувачів, про алгоритми ні слова.

Бувають і приємні винятки. Наприклад, KitRUM шукає розробника, що знає структури даних і алгоритми, оскільки позиція передбачає «a lot of vanilla solutions to a wide variety of software challenges».


Серед архітектур лідерами очікувано є MVVM та MVP, але вже з’являється і новіша MVI. А от VIPER ніхто не згадав. Для багатьох VIPER асоціюється з iOS-розробкою, але сайт Ray Wenderlich розвіює міфи та розповідає про VIPER під Android у книжці Advanced Android App Architecture.


Найчастіше у вакансіях Senior Android Developer вимагають знати як Kotlin, так і Java. Причому це настільки важливо, що обидві мови програмування невпинно згадують в абсолютній більшості вакансій. Можна дійти висновку, що не вдасться стати Senior Android Developer, маючи прогалини в хоча б одній з профільних мов.

Android-розробка

Кожна п’ята вакансія згадує Android Jetpack Architecture Components. Часто роботодавці очікують, що Senior Android Developer вміє виконувати performance tuning. З’являються вже згадки про Compose UI.


Графіки говорять самі за себе, тому нижче наведемо кілька прикладів без коментарів. Розділ на категорії є умовним. Про те, яка технологія має потрапити в яку категорію, можемо подискутувати в коментарях.

Асинхронне програмування

Dependency injection

Networking

Project structure

Інструментарій розробника

Testing

Інфраструктура розробки

Гібридна розробка, native code, нішеві знання

Попри весь хайп навколо гібридної розробки, особливо Flutter, ми бачимо, що роботодавці не вимагають від Senior Android Developer знати ці технології.

Гостра дискусія з цього приводу розгорілась у першій статті цієї рубрики про iOS. Деякі люди тоді дивувались, що про гібридну розробку не йдеться у вимогах, і ось це повторюється для Android. Думаю, причину варто шукати в тому, що гібридна розробка сьогодні виокремилась в незалежний напрям, і відповідні вакансії розміщуються на DOU в рубриках React Native та Flutter, а не Android та iOS/macOS.

Native code

Нішеві знання

Як плюс для кандидата найчастіше називали Kotlin, Firebase, Android NDK та OpenGL. Візьміть собі на замітку. Про Kotlin мовчу, адже це і так зрозуміло, але знання Firebase, Android NDK та OpenGL можуть знадобитися, щоб влаштуватися на посаду Senior.

М’які та гуманітарні навички

М’які навички відіграють велику роль для Senior Android Developer. У вас може бути мало досвіду, посередня англійська, але ви буквально мусите вміти спілкуватись і працювати в команді. У кожній третій вакансії йдеться про м’які навички. Подивимось, як компанії описують свого ідеального кандидата.

«We’re not asking you to be a 100% empath or to love everybody. Just don’t be evil, rude, or selfish. And try to communicate with the team like a human being» (Reface)

«A collaborative mindset with strong communication ability» (N-iX)

«Positive and open-minded style of communication» (AgileEngine)

«Well-developed communication skills» (Intellias)

Цікавинки, знайдені у вакансіях

Нещодавно вийшла новина про відкриття в Україні офісу Tango Me, однієї з найбільших стримінгових платформ, і ось вони вже шукають на DOU Android-розробників рівня Senior / Team Lead.

NCube і Newxel запрошують працювати над Viber.

Leia Labs пропонує компенсацію до $7000. Буде плюсом досвід з Computer Vision.

В офісі appflame є кімната для сну. А ще компанія регулярно ініціює загальнокомандні подорожі, відвідали навіть Мексику та Шрі-Ланку.

Product Madness може зацікавити відрядженнями зі Львова до Великої Британії.

SoftServe запрошує працювати над найбільшим у світі сайтом для мандрівників, який досягав 390 мільйонів унікальних відвідувачів на місяць. За даними SimilarWeb, найбільшою платформою про подорожі є TripAdvisor, який у серпні 2021 року мав трафік 143 мільйони відвідувачів, але до пандемії був значно популярнішим.

Yalantis пропонує sign-on bonus $1000. В Ajax такий бонус дорівнює одній зарплаті.

ПУМБ пропонує плюс одну зарплату за тренінг / сертифікацію.

В Zenia максимальна компенсація на позиції Senior Android Developer становить $3500. Потрібна англійська не нижче як B1. Буде плюсом досвід роботи з OpenGL ES / OpenGL / OpenCL, AR/VR. Є можливість релокації в Литву.

Думки технічних експертів

Анонімний Senior Android Developer, що має великий досвід проведення співбесід

Свого часу, коли шукав нову роботу, після кожної співбесіди нотував запитання. Приблизно третина з них перетиналася буквально на всіх інтерв’ю, дві третини повторювались хоча б раз.

На основі цього я й сформував свій список питань. Періодично його оновлюю, але загалом він не змінюється. Це розраховано на 2,5–3 години співбесіди, але я запитую половину, в рандомному порядку вибираючи питання, щоб було хоч якесь різноманіття між інтерв’ю. Хоча питаннями то назвати складно, це радше тезисно виписані теми, по яких я проходжусь з кандидатом, а в кінці — практична задача на проєктування фічі, такий собі мінігрумінг.

Грубо кажучи, в мене є п’ять блоків: Computer Science, Java, Android, Kotlin, RX/корутини, архітектура.

У першому блоці запитую елементарне на зразок ООП, SOLID, чим наслідування від композиції відрізняється тощо. Відповіді тут майже не впливають на результат співбесіди. Я це запитую, щоб людина «увійшла в ритм», бо багато кому треба кілька хвилин, щоб розговоритись. Якщо бачу, що відповідають чітко, відразу переходжу до наступного блоку.

На початку співбесіди я завжди даю дисклеймер, що очікую відповідей, начебто я початківець, якого кандидат менторить.

Загалом список такий, що я б міг запитувати це і в джуна, але з іншим формулюванням. Наприклад, запитуючи у сеньйора «що таке RecyclerView?», я очікую спіч на 3–4 хвилини, в якому почую, що це, яку проблему вирішує, за яким принципом працює, на які компоненти поділяється, а наостанок кілька слів про DiffUtils. Джуну я б ставив більш конкретні питання на кшталт «Що робить LayoutManager?», «Для чого потрібен ItemDecorator?». Якщо я бачу, що кандидат добре орієнтується в темі, можу зупинити його й дати практичну задачку, щоб закріпити результат. Щодо того ж RecyclerView, то я спитав би, яким чином організувати часте оновлення списку. Наприклад, щосекундне оновлення курсу валют. У відповіді б очікував почути щось про payload.

Передусім я дивлюсь на те, як людина комунікує, чи може вона викласти свої думки доступно і структуровано, а також звернути мою увагу на важливі моменти в питанні. Так, начебто я не розбираюсь в темі й мені потрібно провести короткий брифінг. I відповідь «я не знаю» значно краще, ніж намагатися додумати/вгадати або лити водичку. До незнання я ставлюсь толерантно й завжди ставлю більш детальні питання або перефразовую, якщо перший захід в тему був надто загальним і кандидат не розуміє, що я від нього хочу. Якщо спеціаліст сам ставить уточнювальні запитання, то це ледь не краще, ніж сама відповідь. На практичній частині це особливо актуально.

Якщо підсумувати, то я не можу сказати, що Senior — це той, хто знає певний набір технологій. З так званих хард-cкілів я очікую досвід роботи з більшістю стандартних компонентів SDK, знання популярних архітектурних патернів, синтаксису і стандартної бібліотеки Java/Kotlin. Ще, за відчуттями, корутини перейшли зі статусу «бажано» в «обов’язково». А от що обов’язково має бути — вміння доступно пояснювати іншим, як працюють штуки, в яких ти розбираєшся. Багато кандидатів, на жаль, погано це робить. А це важливо, нині розробка здебільшого командна, і вчасно та доступно проговорені речі економлять купу нервів не тільки вам, а й колегам.

Також за мотивами однієї з тем на DOU серйозно замислився над тим, щоб додати ще livecoding з FizzBuzz наприкінці співбесіди :)

Антон Козленко, Android Tech Lead в Noteworth

Я вважаю, що «seniority» вимірюється не тільки обсягом знань платформи та найпоширеніших бібліотек, інструментів, а більше умінням розв’язувати проблеми оптимальним способом і незалежно від рівня їх складності. Тобто Senior має вільно орієнтуватися у підходах до вирішення проблеми та вміти правильно обирати стратегію для кожного конкретного випадку.

Це не означає, що ви маєте знати абсолютно всі деталі платформи або бібліотеки (хоча на цьому етапі експертиза уже має бути солідна). Саме вибір підходу, початкової точки та розуміння загальної стратегії, які допоможуть досягти результату у відведені терміни, водночас на виході мати масштабований, чистий і стабільний код, який буде зрозумілий людині й достатньо швидкий у виконанні на машині — ось це необхідні навички для Senior Developer незалежно від спеціалізації.

На співбесідах я завжди приділяю увагу знанню базових речей в Android SDK (що є must), а ще намагаюсь запитувати так, щоб почути від кандидата, яким способом він би розв’язував задачу: питання щодо архітектури загалом чи щодо пошуку рішення для робочого застосунку. А також юніт-тестам, адже вони допомагають у написанні стабільного коду і водночас є своєрідною документацією для всієї команди.

Олександр Плєхов, Senior Mobile Engineer в Intellias

Хто такий Senior Android Developer? Мабуть, перше, що спадає на думку, це розробник, який знає та працює в усіх доменах, приділяє коду 100% часу та починає реалізацію відразу після вивчення головних вимог. Робить це, не зазираючи в документацію Android SDK та Stack Overflow, бо вже все знає. Здебільшого так і є, але є нюанси.

  • Звісно, можна спробувати вивчити всі домени, якщо поставити таку ціль. Але це не має такої цінності, як технічний стек за плечима, що є матеріалом для будування будь-яких бізнес-завдань. Та й охопити всі домени нереально. Для нових ринків та регіонів потрібні свої підходи до реалізації.
  • Якщо подивитися на роботу Middle- та Senior-розробників, можна помітити, що перший почне працювати над завданнями якомога швидше, на відміну від свого досвідченішого колеги. Все тому, що Middle Developer вже вміє вирішувати завдання самостійно, але ще не отримав достатнього досвіду, щоб передбачити наслідки поспішних рішень. Спочатку треба актуалізувати всі вимоги, скласти план реалізації та зробити його у поточній архітектурі.
  • Від Senior-розробників не варто очікувати написання проєкту крейдою на дошці, якщо ми говоримо про тезисне будування кроків, а не компільований код. Android SDK та сторонні інструменти так швидко розвиваються та застарівають, що тримати весь синтаксис у голові неможливо та й не має сенсу. Наш мозок швидко видаляє непотрібну інформацію. Треба розуміти принципи мобільної розробки та стежити за трендами. Новий інструмент Senior освоїть швидко. Але базові поняття знати детально обов’язково. Якщо ви прийшли до розробки відразу на RxJava2 і Kotlin, наприклад, без знання Java Core та вміння працювати з класами Thread, то далі буде складно рухатися.

У кожній компанії/продукті своє розуміння того, хто такий Senior-розробник. Один і той самий фахівець в одній компанії не отримає підвищення через брак скілів, а в іншій він же буде перекваліфікований.

У моєму розумінні Senior Android Developer має:

  • мати soft skills для комунікацій з будь-яким відділом розробки, виявляти деталі, розв’язувати конфлікти, пропонувати рішення;
  • бути ментором, вчитися в колег, володіти актуальною технічною експертизою;
  • мати комерційний досвід роботи з Java/RxJava/Kotlin/Coroutines/Android Jetpack та досвід у будуванні архітектури;
  • завжди цікавитися, як це працює під капотом;
  • писати код, який добре читатимуть люди, а не машини;
  • мати досвід створення проєктів під ключ;
  • вести pet projects, щоб практикуватися в альфа/бета-інструментах і з часом використовувати їх для продакшену;
  • на питання «Як зробити?» пропонувати рішення, а шукати відмовки.

Добре, якщо:

  • є досвід або розуміння кросплатформенних розробок. Це допомагає запропонувати зважені рішення для бізнесу;
  • є знання С/С ++. Це дає змогу отримувати доступ до проєктів, де потрібна максимальна працездатність пристроїв.

Тобто Senior Android Developer — це окрема одиниця проєкту, якій можна дати опис задачі, а на виході отримати готове її рішення.

Рекомендовані книги:

  • Effective Java, Joshua Bloc;
  • The Clean Code, Robert C. Martin;
  • Refactoring, Martin Fowler;
  • Kotlin in Action, Dmitry Jemerov;
  • Effective Kotlin: Best Practices, Marcin Moskala;
  • Head First Design Patterns, Elisabeth Freeman.

Андрій Флінта, Mobile Engineering Lead в Intellias

Senior Android Developer — це насамперед досвідчений інженер із добре розвиненими soft та hard скілами.

Необов’язково ідеально знати технічну теорію, фреймворки, всі алгоритми тощо. Річ у тому, що наш мозок не є сховищем інформації, а має бути ефективним фільтром та обробником даних.

Отже, хочу виділити три основні навички ідеального Senior-інженера:

  1. Вміння ефективно використовувати технології, обробляти та розуміти різну інформацію та дані, адаптувати це під потреби проєкту.
  2. Вміння комунікувати та ділитися інформацією з колегами, замовником як вербально, так і за допомогою коментарів у коді, документації, діаграм тощо.
  3. Вміння писати зрозумілий, гнучкий і тестабельний код, наприклад, використовуючи SOLID, KISS, TDD принципи.

Якщо говорити про конкретний технічний стек Senior Android Developer, то це:

  • SOLID, KISS, DRY;
  • UML diagrams;
  • Dependency injection;
  • Unit testing;
  • code quality, code review;
  • Kotlin/Java experience;
  • Android SDK/NDK;
  • Android Multithreading (RxJava/Coroutines);
  • Android Jetpack Architecture Components;
  • Android SDK/NDK;
  • Android Custom UI/Animations;
  • MVVM, MVC, MVP;
  • IPC;
  • JNI;
  • Application Profiler.

Роман Івасишин, Senior Android Engineer в Avenga

Архітектура Android-системи/застосунку є одним із найважливіших пунктів. Важливо знати принципи роботи Android-системи, модель взаємодії її компонентів, а також переваги та обмеження загалом. Поява і розвиток проєкту Android спрощує розв’язання архітектурних проблем під час розробки, але при цьому не треба забувати, що хоча знання бібліотек є must have, знання архітектурних компонентів Android SDK є основою. Що вирізняє Senior-розробника? Вміння аналізувати потреби проєкту та вдало використовувати потрібні архітектурні компоненти.

Також Android-система вимагає додаткових знань і зусиль:

  • знати менеджмент і профайлінг пам’яті;
  • враховувати енергоефективність;
  • розробляти ефективні моделі роботи при різних типах під’єднання до мережі та відсутності мережі.

Крім того, треба вміти аналізувати потреби бізнесу і конвертувати їх в ефективний програмний інструмент. Великою перевагою є досвід в інтегруванні аналітичних інструментів, які будуть давати корисну інформацію про застосунок.

Необхідні вміння аналізувати і вирішувати нетривіальні задачі, логічне мислення. Розбивати систему на модулі та підсистеми. Ухвалювати обґрунтовані рішення щодо архітектури та використання різноманітних бібліотек. Важливим чинником є саме зважені рішення, а не гонитва за трендами.

Знання принципів UI/UX Android-системи є одним з важливих пунктів. Адже потрібно дати не тільки інструмент для бізнесу, а й зручний та ефективний застосунок для користувача. Перед Senior-розробником стоїть завдання транслювати U/UX-принципи, які притаманні Android-системі, всередині команди.

Також невіддільною частиною є ті знання і вміння, які має мати кожен Senior незалежно від напряму: софт-скіли, менторинг, структури даних, бази даних, алгоритми, патерни, bug tracking, testing, CI/CD...

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному3
LinkedIn



40 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

С моей точки зрения в статье делается основной упор на фрейворках и это есть ошибочный взгляд. Толковый разработчик освоит нудные фреймврки в течение пары месяцев. Чтобы получить хорошего разработчика — это освновной упор на язык программирования, паттерны проектирования и понимание, именно правильное понимание их применения, дает тот класс разработчика. А язык учится благодаря алгоритмам. Уже сколько раз было показано, FAANG компании не проводят интервью по фреймворкам, как делают у нас :)

Я видывал код тех людей, которые решили освоить фреймворки прямо на проекте.
Фреймворк — это прежде всего идеология использования и паттерны, на которых он базируется. А не тупо синтаксис и зависимости.
Например, ViewModel и LiveData неразрывно связаны с MVVM-паттерном и Observer.
Но недостаточно знать Observer, чтобы понимать, LiveData. Нужно также знать его нюансы использования (а их — вагон и маленькая тележка), чтобы эффективно использовать их на проекте.
Не понимая этих особенностей, человек будет либо некорректно их использовать, либо пытаться писать вместо них свои костыли.

Ну и наконец, основное.
Андроид — это операционная система. По сути, один большой фреймворк. И уровень Android Developer’а в значительной степени определяется его умением с этим фреймворком взаимодействовать, а не знанием каких-то академических алгоритмов.
Не стоит переносить реалии ФААНГОВ, которые сами пишут все фреймворки на реалии украинского аутсорса/аутстаффа, где требуется выдать стабильный и быстрый результат, используя любые доступные 3d party решения.
Разработчик, использующий готовые решения всегда по велосити опередит разработчика, который используя академические знания, пишет свои.
Если мне нужно вскопать огород, я не буду изобретать лопату, я куплю её в «Эпицентре».

Я не говорил, что нужно осваивать фреймворки прямо на проекте. Безусловно, что надо изучать их вне основного проекта или, если разработчик на бенче. Я все же про то, что сами фреймворки осваиваются относительно быстро. Но чтобы их быстро освоить все же надо владеть языком программирования и базовыми паттернами в достаточной мере.
Все разработчики проходят следдующий путь (или большинство) — сначала синтаксис, потом решения базовых задач, ООП. Потом паттерны, потом уже системный подход с более высого уровня. Все приложения для той или иной платформы имеют уже заложенную архитектуру, так называемые шасси, на которые идет уже наработка бизнес и UI логики.

Я все же про то, что сами фреймворки осваиваются относительно быстро

К сожалению, нет. Освоить фреймворк можно только в боевых условиях. Написать на них пет проджект, например. По книжкам и статьям всего не узнать и не разобраться.

Все приложения для той или иной платформы имеют уже заложенную архитектуру, так называемые шасси, на которые идет уже наработка бизнес и UI логики.

Да. И умение строить это шасси — это и есть уровень разработчика.
Я не спорю, что важно хорошо знать язык, на котором пишешь наравне с фреймворками, которые используешь и подходами, на которых они основаны. Я не согласен, что продвинутая алгоритмическая подготовка в ущерб всему остальному поможет стать более востребованными мобильным разработчиком.

Вне книг и статей остаются только тонкости. Все остальное покрывается хорошей книгой. Смотря, правда, какого издательства читать. Я предпочитаю книги издательства «Manning», проверенные авторы, которые или сами практикующие программисты или архитекты. А тонкости — тонкости, да, познаются в боевых условиях, но это встречается не так часто. У меня был пример, я применил на проекте для реализации подситемы теотрию конечных автоматов, потом с этим никто почему-то разобраться не смог, у меня же оно работало. Так вот
эту подситему можно реализовать на любом ООП языке. Вот и все. А сделать UI и смапить это на соответствующую инфраструктуру — это несложно.

У меня был пример, я применил на проекте для реализации подситемы теотрию конечных автоматов, потом с этим никто почему-то разобраться не смог, у меня же оно работало.

Чувствуется рука «архитектора» ! Подозреваю после этого проект переписывали ?)

Вне книг и статей остаются только тонкости.

Которые и составляют суть работы разработчика. Банальности (бойлерплейт) может и сам фреймворк сгенерировать, тут программист и не нужен.

А тонкости — тонкости, да, познаются в боевых условиях, но это встречается не так часто.

Да, всего лишь в каждом проекте.

У меня был пример, я применил на проекте для реализации подситемы теотрию конечных автоматов, потом с этим никто почему-то разобраться не смог,

Молодец. Написал неподдерживаемое и нерасширяемое решение.
Хороший код — это код, с которым могут работать люди, а не только машина.

И чем же оно не расширяемое? :)
Оно то как раз очень даже расширяемое, применяется для избегания применения switch/case.

Я подозреваю, что конструкции типа switch/case читаются и правятся легче (особенно в нынешнем варианте when/is), чем доморощенная Стейт машина, для добавления нового экрана в которую нужно описывать новые состояния и переходы.
Стейт машина — хорошая штука для структурирования бизнес логики работы приложений, не взаимодействующих с REST и вынужденных самостоятельно управлять своим состоянием.
Но для навигации связка ViewModel, LiveData и JetPack Navigation рвёт любые доморощенные решения.

Я подозреваю, что конструкции типа switch/case читаются и правятся легче (особенно в нынешнем варианте when/is), чем доморощенная Стейт машина, для добавления нового экрана в которую нужно описывать новые состояния и переходы.

Скорее ты не совсем понял суть проблемы. Представь, что есть модуль. В твоей терминологии это один или несколько «экранов». Каждый из которых морфирует исходя из кучи разных источников правды (бизнесу так захотелось).

И вот под такой стейт менеджмент со множеством начальных условий и приятна стейтмашина. Условный свич очень резко разрастается при необходимости хендлить тупиковые кейсы и переходы между состояниями, а код попроще очень легко сломать, потому как там условия не прописаны очевидно. И никто не будет лезть в оригинальный тикет смотреть как оно должно было быть пока не сломает.

Стейт машина же просто явно прописывает исчерпывающий и полный объем возможных вариантов такой вот неочевидной логики.

Но вообще да, есть еще тесты и джавадок комментарии как документация

Я, кстати, тоже думал несколько месяцев назад использовать конечный автомат для стейтменджмента в одном из модулей. Отказался как раз потому что были сомнения, что будет

потом с этим никто почему-то разобраться не смог

Смотрите, в стейт машине вообще, по идее, нет ничего сложного. Вопрос только в том, где ее имеет смысл использовать. В бмзнес логике — это самое оно. Так как вы избегаете написание switch/case и прячете это все в иерархии наследования. Это в любой стоящей книге по ООП дизайну рассматривается. Трудности у девелоперов это вызывает лишь потому, что они помимо фреймворков не желают или не хотят углубляться в компьтер сайнс.

Два раза в своей профессиональной карьере декомпозировал сложную бизнес-логику через паттерн state.

Первый раз переделывал легаси с вложенными ифами на 4 экрана. На проекте был junior и я, junior позадавал пару вопросов, быстро вкурил что к чему, и вскоре сам дополнительные стейты реализовывал.

На втором были тока сеньйоры, и сложная бизнес логика с нуля, которая подразумевала сетку с 3×4 состояний (странная комбинация геолокации и поиска, а так же куча ивентов, которые сайд эфектом могут менять условия), только на обсуждение которой потратили несколько часовых митингов. Предложил реализовать через стейт машину. Согласились. Написал, сделал колл-презентацию как это работает, прошел код ревью. Через несколько дней прилетает пул реквест с кодом, который меняет часть UI напрямую, а не передает ивент в стейт машину.

Справедливости ради, та бизнес-логика была настолько дебильной и часто меняющейся, что конечный вариант никто так и не смог сформулировать отдельным документом. Но, блеать, именно на таких кейсах она и нужна, т.к. тебе не надо понимать всю картинку, только с каких стейтов ты можешь перейти в текущий, и куда можно перейти с текущего, мейнтейнить подобный мэсс сам боженька рукой банды четырех приписал.

Так как вы избегаете написание switch/case и прячете это все в иерархии наследования

Цепочка наследования — это один из самых запутывающих код приёмов программирования. Очень сложно бывает отследить иерархию вызовов функции, которая была переопределена в овер 9000 наследниках 100500 раз.

Смотрите, в стейт машине вообще, по идее, нет ничего сложного

Ну прям ни одного минуса?
А расширяемость?
Нужно каждый раз писать бойлерплейт для добавления нового стейта, переходов на него и сайд эффектов. Это долго и скучно.

Трудности у девелоперов это вызывает лишь потому, что они помимо фреймворков не желают или не хотят углубляться в компьтер сайнс.

Потому что главная характеристика кода — лёгкость поддержки. Нажимать кнопки намного легче, чем учить матан. С кодом, который можно читать и менять без знания матана, намного проще работать.

Я все же про то, что сами фреймворки осваиваются относительно быстро. Но чтобы их быстро освоить все же надо владеть языком программирования и базовыми паттернами в достаточной мере.

«Относительно быстро» ты можешь разве что README на гитхабе прочитать. Все ньюансы и особенности познаются с годами работы

вы так уверены? Изучив более чем 4 платформы я знаю о чем говорю. Еще раз — основная трата времени идет на изучения самого языка и правильного применения паттернов. Фреймворки сами по себе изучаются достаточно быстро. Хороший специалист изучит андроид за два три месяца.

Хороший специалист изучит андроид за два три месяца.

лол. Ага с 3 месяцами изучения можно сразу в фейсбук подаваться на сеньйора.

По моему опыту люди изучавшие много фреймворков за короткое время знают их все одинаково хреново

давайте по существу. Там, где используется Java/Kotlin — основная идея работы строится на рефлексии и кодогенерации. Пример кодогенерации Retrofit. Пример испозования рефлексии — DI посредством Dagger, если память мне не изменяет. И так далее и тому подобное. Что тут может вызывать трудности?

Java/Kotlin — основная идея работы строится на рефлексии и кодогенерации.

ОС Андроид. Основная идея строится вокруг жизненных циклов разных компонентов. И мостиков между ними, которые позволяют им между собой взаимодействовать.
Компонентов этих — вагон и маленькая тележка. Не зная их все и нюансов их жизненных циклов, можно при идеальном знании Java и Kotlin и знании всех паттернов, писать страшный и нестабильный говнокод. Я встречал архитекторов, которые вместо ливдаты, пытались подписывать активити и фрагменты на корутин флоу. Видел попытки делать то же самое с Rx ранее.
Это всё проистекает из непонимания нативных компонентов, таких как ливдата и неумения ими пользоваться ввиду незнания их нюансов и хороших практик работы с этими нюансами.
Например, многие wanna be Андроид архитекторы не понимают, как использовать ливдату для передачи событий навигации по приложению, не ломая при этом бэк навигацию, корректно обрабатывая поворот экрана, не теряя событий при повороте экрана и т.п. эдж кейсы.

Хороший специалист изучит андроид за два три месяца.

Я видел код таких «хороших специалистов».
Спасибо, не надо.

Читал на днях очень забавную статью по Андроиду: medium.com/...​-application-924c91bafcac
Суть — человек 3 месяца исправлял баг. Репродьюсить баг на тесте не получалось. Приходилось делать изменения, выкатывать на прод, ждать логов и перепроверять. И казалось бы что все логично, что логи должны появиться — а они не появлялись...
Это я к чему, это я к тому что 3 месяца отлавливался один баг...один. А вы предлагаете всю платформу за 3 месяца изучить. И да, случай в статье очень специфичный(а может и нет), но вся разработка по Андроид — это борьба с такими очень специфичными случаями, которые постоянно всплывают. И когда ты, казалось бы, уже думаешь что познал Андроид, то обязательно прилетит какая нибудь херня, от которой ты готов волоса во всех местах повырывать, не понимая как вообще такое возможно.
И поверх всего этого каждый год с новой версией прилетают новые «подарки» от гугла. И каждый год надо подгонять уже написанный код под новые ограничения. А эти ограничения иногда ой как не укладываются в концепцию написанного кода... И каждый год надо вырабатывать best practices что бы в дальнейшем можно было писать поддерживаемые приложения. И вы говорить что все это можно за 3 месяца? Ну-ну

По первому кейсу — тестировать надо локально, для начала. И не пропускать unit testing, как это делается за частую в мобильной разработке, я уже не говорю про то, что в большинстве случаев пытаются сэконочить и выбрать не нативный путь разработки. Но не это сейчас предмет разговора. По второму — кейсу, что в андроид есть баги. Да, есть — это проблема открытой платформы, плюс каждая компания, как пример, Samsung кое что делают исключительно про свои дивайсы. Я сталкивался с такими случаями и не одним, как пример — на Samsung при фотографировании имедж переворачивался на 90 градусов. Модель не помню. Был еще кейс, когда на Samsung все взлетает — на Sony Xperia — вообще не работало. Но это все познается в процессе и фиксится так же в процессе работы. Но ничего тут сверестесственного нет. И никто никогда не охватит все сразу. Но вы как раз смешали общее и частное. Кто-то быстрее зафиксит ишу, если имел уже с ним дело, кто-то будет сидеть разбираться. Но чтобы спокойно сесть работать — да, это возможно.

По первому кейсу — тестировать надо локально, для начала

Вы даже невнимательно прочитатли мои слова. Я же написал, что «Репродьюсить баг на тесте не получалось.». Т.е. там случай, для которого невозможно написать тесты. И даже зная где баг — вручную его не получалось воспроизводить. Там даже теоретически невозможно было представить как такое может случаться. Так что тут вы мимо.

По поводу писать тесты — как правило тесты(если же конечно они пишутся в проекте) в большей степени покрывают бизнес логику приложения и с ней обычно проблем и багов нет. Ну или вполне очевидно(хотя не всегда) где и как исправлять. Проблемные баги как раз возникают в том месте, в котором идет взаимодействие с ОС. А в тестах это либо не покрывается, либо мокается, либо используется какой нибудь robolectric, который не гарантирует 100% совпадения поведений. И вот как раз в этом месте и возникает судорожные ситуации «Ну какого х**ра оно тут так себя ведет». И как вы предлагаете это покрыть тестами? Как вы правильно заметили, иногда поведение на разных версия ОС или у разных вендеров отличается. И тут остается только выезжать на опыте разработчиков.

Кто-то быстрее зафиксит ишу, если имел уже с ним дело, кто-то будет сидеть разбираться.

А это разные люди пытаются объяснить в разных коментах уже несколько раз — реалии рынка таковы, что когда вы работаете на аутсорс, то компании не нужет человек, который «кто-то будет сидеть разбираться», им нужет «Кто-то быстрее зафиксит ишу». А еще лучше, нужен человек, который предвидит эту ишью и не сделает. Таковы реалии. Поэтому для Укр. рыка модель с «Нам нужен хорошый инженер, он всегда сможет решить любую проблему» не подходит. Такое подходит только для продуктов или для заподного рынка. Укр. рынку нужен человек, который может закрыть задачу еще вчера.

Вы придираетесь к словам. Я к тому, что такой кейс — это частное. Я не знаю контекста и потому тут можно вести спор исключительно на абстракциях. Более чем уверен, что там могло оказаться все тривиально. Это не только проблема андроид, где такое может возникать.
И то что все пытаются доказать, еще раз хотел бы подчеркнуть. Большинство упирает на частности. Я же говорю про общее.
Про украинский аутсорсинговый рынок вообще не хочу говорить. В большинстве случаев — это не здоровые процессы, в силу определенных обстоятельств, которые мало кто хочет фиксить.

Большинство упирает на частности. Я же говорю про общее.

Почти все проекты, на которых я работал — частные случаи.

Погоджуюсь. Я навіть написав в статті, що понад 90% вакансій не згадують алгоритми. Мені би самому хотілося, щоби вага алгоритмів була, як у FAANG. Але, на жаль, навіть Lyft в своїй українській вакансії не згадував алгоритми на момент проведення дослідження.

так и в 99% позициях вы их и не будете использовать.
На Mobile найти другую работу кроме клепания форм это нужно очень постараться.

Мені би самому хотілося, щоби вага алгоритмів була, як у FAANG

Этого никогда не будет.
В мобайл все алгоритмы давно зашиты в СДК.
Будете пытаться писать свои велосипеды — вас уволят за лоу перфоманс.
Не будете знать, как с помощью фреймворка быстро и качественно напедалить фичу, полетите туда же.
Рынок и его потребности определяют требования к кандидатам, а не Ваши предпочтения.

вы наверное оторваны от реальности в сфере мобильной разработки. 99,9% задач в реальных проектах не связаны с алгоритмами и базируются уже на существующих решениях

Я займаюся мобільною розробкою з 2012 року і донині, але не це зараз головне. Хочу закликати учасників дискусії до взаємоповаги. Скільки людей, стільки й думок, — давайте це приймати!

а что ты собираешься делать со «специалистами» без знания фреймворков, когда задачи нужно решать уже здесь и сейчас? Я не представляю как брать на проект человека не знающего например реактивные фреймворки и давать задачи из беклога продакшена. Там масса ньюансов, и без их знания можно такого наворотить что никакое «знание алгоритмов и паттернов» не поможет

Собеседования сейчас в большинстве — лютый треш. Онлайн кодинг, вопросы из теории, которые заучиваешь, а через пару недель уже не помнишь. Был у меня даже случай, когда спросили об образовании и когда узнали, что у меня оно не профильное, то начались насмешки.

Но были и реально интересные собезы с классными вопросами. К сожалению их не так много...

Розкажіть мені приклад застосування букви «D» із SOLID у вашому коді за останні 2 тижні ©

Я можливо зараз буду занудою, но ця стаття явно показує якого рівня зріз по цих команіях, можливо імено через це в них 23% відсотки це Senior в якого три роки досвіду, АЛЕ KOIN немає нічого спільного з Dependency injection, KOIN це SERVICE LOCATOR, будьласка перестаньте путати гіршене з правидним, Dependency injection і Dependency inversion, це не одне і теж саме, і якщо вам хотілося підвести Dagger і Koin під одну риску, то правильно було б використовувати термін «Dependency inversion»

Дякую за коментар, Володимире! Це моя помилка. Врахую у наступних випусках.

DI — паттерн, який можна реалізувати що на фабриках, що з коіном, що з даггером. Також даггером можна користуватись як сервіс локатором, якщо, наприклад, зберігати лінк на компонент в класі аплікейшна і смикати всюди його для костиляння.

До речі, навіть ствердження, що Koin не є DI-фреймворком спірне. Так, він не імплементує JSR-330. Але, на хвилиночку, він не для Джави зроблений.

Якщо під DI мати наувазі Dependency inversion тоді я з вами повнісю згідний, або в статі ішла мова про Dependency injection, і я не казав що koin не є DI-фрейтморком, я казав що він немає нічого спільного з Dependency inversion, так як він є service locator. JSR-330 не зроблений для java , він зроблений для того що google як автор більшості JSR називає java platform, до яких kotlin теж відноситься

Ноуп. Даже использование конструкторов с параметрами — уже Dependency injection

Посмотрите детально отличие коина и даггера
www.youtube.com/watch?v=D0rpUBVXSCw
Koin может выполнять функции как DI фреймворка, так и сервис локатора , но DI фреймворком от этого он не перестанет быть

Підписатись на коментарі