Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Странный выбор Clojure. Можно же было загуглить статистику вакансий и выбрать что-то из более популярного, типа Go, Java, C#
Выбор был бы странным, если бы целью было любой ценой уйти в бекенд. Мне ничего не мешало сделать это в auto.ru, а потом и в SberDevices — можно было перейти в соседнюю команду на Kotlin/Java.
Логично было выбрать Java. Я первый год под Android писал на Java. Читал Effective Java и Concurrency in Practice. Kotlin — это по сути сахар над Java + корутины.
Зато благодаря иррациональному выбору сейчас у меня есть прочитанный и проработанный SICP, реализованные интерпретаторы (concatenative), переводчик c Dart на Clojure. Опыт в проде в бекенде на Clojure и Kotlin. Опыт на фронте на ClojureScript (пару месяцев в крипто-стартапе) и TypeScript (в той же Австралийской конторе, куда ушел писать бекенд). И всё время было интересно.
Уйди я в бекенд на Java, не видел бы сейчас дальше своего носа, опыт был бы очень ограниченным по части того, как можно писать код. Да и скорее всего я бы без интереса не вывез, бросил и вернулся в Android.
Андройд говорите тихая гавань? Я перешёл в веб на фронт (Ангуляр) и вот думаю вернуться на бек на Го (когда то им занимался).
Андройд - это лютое месиво из сырых технологий: java + xml, compose, room, mvvm, mvp, mvi, итд итп и конца и края не видно. И все ПОСТОЯННО устаревает. Гуглу вообще похеру на разработчиков, на их опыт. Они хотят взять из большого рынка monkey реакт разработчиков и посадить их за Conpost свой, ебучий. Как я это все дерьмо не навижу, горите в аду)).
Работал с беком, кажется там более стабильные технологии: база, кеши, очереди, один язык, один фреймворк. Всё. И нет вендор лока на Гугол.
Моё мнение - карьера Андройд разработчика - это тупик!!!!!!!
и вот думаю вернуться на бек на Го (когда то им занимался).
Возвращайтесь на бек, конечно. Go — отличный язык, сам хочу на нём писать.
В остальном что вы сказали — согласен. Но когда у меня было ~7 лет опыта разработки под Android, мне, разумеется, этот стек казался самым простым, понятным, я уже всё вдоль и поперек обошел на нем.
Какой последний стек на Андройд вы использовали? Просто интересно.
Последнее, что я пробовал, это был Compose + Accompanist (костыли для Compose, которые туда не успели войти). Mvvm паттерн.
Ну... верстать UI на Compose наверное проще чем на xml. Однако вся эта декларативная модель работы с данными и однонаправленные потоки данных мне кажется как то очень сложно реализованы на Андроиде... В итоге всегда было ощущение, что сидишь на кактусе... К тому же ты ещё должен знать и о gotchas которые могут вызвать лишние рекомпозиции. Ага, норм фрейм, где ты не только бизнес логику должен делать, но ещё и на рекомпозицией следить..
Эх, жалко что с Clojure пришлось уйти. Грустновато закончилась эпопея(
Странно что про мобилку так однобоко. Мол, все просто и есть потолок.
Я так лет 5 назад думал, мол, че еще можно в этих ваших ios и swift. А щас куда ни копнешь - бездонные колодцы какие-то и постоянно надо что-то читать изучать и ресерчить.
То что надо постоянно что-то читать-изучать и ресерчить — особенно, если задачи выходят за рамки запросов к серверу и рисования ленты, — с этим не спорю. В android я в сбердевайсах и с плеером поработал, много IPC было с нативными сервисами, медиа-сессию дружил со споттером и голосовым ассистентом, которые на плюсах и имеют свои приоритеты на звук. Даже Youtube показывали в Cobalt браузере (вместо WebView).
Но есть другая сторона, когда ты тратишь огромное количество времени просто на то, чтобы научиться обходить подводные камни и кривые АПИ, переучиваешься каждые пару лет на новый способ описания UI, пока предыдущий деприкейтят. Куча проблем с версиями ОС (ветвления нужны), специфика работы с конкретной ОС (пример: samsung health SDK), разные размеры экранов. Способов организовать многопоточку — несколько десятков (обычные потоки, Java.util.concurrent, AsyncTask, LoaderManager, HandlerThread, IntenService, RxJava1,2,3, Корутины) — каждые 3-5 года меняется популярный способ. Решения про то, чтобы сделать что-то в бэкграунде (выйти из спящего режима, запустить джобу), меняются тоже каждые 3-5 лет.
Всё в абзаце выше — accidental complexity (кроме размеров экрана). И вот на это тратить время всегда было неприятно.
Мне кажется, в любой области такое есть. Имею в виду неприятные и рутинные задачи. И да языки меняют, фреймворки тоже. И в беке точно также битва с окружением, версиями пакетов и все такое прочее. Вместо решения бизнесовых задач надо фиксить версии и пытаться завести эти сервисы и апишки.
На моём опыте больше всего acidental complexity во фронте, затем идет мобильная разработка, и далее бекенд.
За 3+ года в бэкенде в проде не помню, чтобы возился с какой-то фигней. Если и возился, то дело было в говнокоде, который написали коллеги. Остальные проблемы были связаны с реальной сложностью системы, вроде оптимизаций выполнения запросов к базе при больших TPS.
Помню опыт написания мультиплеерной игры: и бэк, и фронт — на Clojure. Больше всего намучился на фронте, когда проблемы лечились перезапуском npm спустя несколько часов гугления.
Все-таки это очень сильно зависит и от проекта и от команды. И тут могут быть абсолютно разные комбинации.
Команда сильная, но в проекте дохрена легаси. И наоборот, проекст со свежим стеком, но команда использует карго-культ и тащит в него все что модного услышала начиная от процессов заканчивая библиотеками.
Поэтому и проекты можно найти абсолютно разные. Если вопрсо статистики - то я пока не представляю кто такое исследование мог бы сделать. Тут же надо в проект вгрызаться и код смотреть, а там все закрыто чистоколом из NDA и злыми юристами.
Поэтому можно только опрашивать бывших работников и то, я каждый раз говоря о том или ином прошлом проекте всегда поправку делаю, что это было Н лет назад и как щас утверждать не берусь.
Все-таки это очень сильно зависит и от проекта и от команды.
Если вопрсо статистики - то я пока не представляю кто такое исследование мог бы сделать
Это да, но можно подойти с другой стороны — через примеры задач.
Мой тезис, что в мобильной разработке больше accidental complexity, чем в бекенде.
Пример 1: запись и чтение файла с диска. В Clojure на бекенде (или декстопе) я бы сделал так:
(spit "path/to/file.txt" "test") ;; записали
(slurp "path/to/file.txt") ;; прочиталиС Kotlin чуть длиннее: `File(path).readText()`.
Не знаю, как на IOS, но на андроид для этого понадобится много-много строк, они умудрились даже фреймворк для задачи написать.
Пример 2: всё что касается кастомных сертификатов. Привет ghost на IOS (статья на хабре). На бекенде/десктопе никаких проблем, может 4 строчки кода.
Пример 3: работа в бэкграунде. На бэкенде — сам себе хозяин, что хочешь, то и делаешь. Не знаю, как на IOS, но на андроиде апи менялось несколько раз и всегда было убогим. До work manager был job scheduler, который надо было трай-кетчами с ног до головы покрывать.
Пример 4: ветвления из-за ОС, выше упоминал самсунг.
Пример 5: IPC. Не знаю, делают ли что-то подобное иосеры, но в андроиде напридумывали херни — биндеры, AIDL, content provider (в зависимости от задачи).
(Блин...кучу букв написал, сорян... просто утро выходной да и в форумах я не часто сижу) :)
Тут я опять же вернусь к своему тезису, что зависит от проекта и подготовленности команды.
Главную сложность в iOS, как мне кажется, создает сама Apple. С той же многопоточкой. Вначале были треды, только их освоил и разобрался с локами и семафорами, пришла apple и говорит "а теперь давайте очереди использовать". И только ты их освоил - снова они врываются и говорят, а теперь вот вам modern concurrency. И снова куча людей должны освоить модель акторов и набить шишки. А если это в прод тащить то это гарантировано баги.
И все это работает в целом стабильно и круто, но для начала надо в это влезать и изучать. И даже в исходный код смотреть. И никто не хочет в голову запихивать новые знания. Поэтому кстати, щас много кто до сих пор не переходит на Swift 6 и SwiftUI. Поэтому и копиться легаси и в итоге имеем что имеем.
И короче основной момент это лень. Есть апи, и если запускается, работает, то никто не лезет дальше. И еще главную хитрость apple сделала, так это до жути стабильная работа приложений. Иногда в проект смотришь и честно не понимешь как он вообще запускается и выполняет свою задачу (а он выполняет!). И если все крешится, то пользователя просто выкидывает на главный экран. В андройде в этом плане честней сразу алерт с текстом ошибки java.exception.что-тотам и понятно что jopa какая-то произошла.
Но и сложностей в iOS хватает. Например, ради стабильности iOS нет гарантий что фоновые таски будут гарантировано и вовремя выполнятся или пуши будут гарантировано приходить и куча всяких других приколов.
Но я пытался в бекенд заглянуть в плане разработки. С джанго вроде все более-менее понятно. Хотя опыта мало и шаг влева-вправо уже не понимаешь почему база падает и миграции не накатываются. С FastAPI еще сложней. Когда GPT-Клодович не смог помочь - пошел к живому специалисту. Он смотрел в код и также как я недоумевал "а почему тут такой способ выбрал, а почему другой не выбрал" и в итоге простую api сделать оказалось совсем не просто. Про базу и миграции молчу. Так что для меня бек такой же шаткий и не определенный, как только дело доходит до модификаций. А когда ТЗ четкое - по нему просто генерируешь модели, прописываешь ручки и если не трогать - пожалуйста, все пашет.
А! еще можно накинуть на iOS что дохрена архитектур выдумано. Поэтому это может создать дополнительную сложность. Но щас на многих проектах тенденцию видел к созданию слоистой архитектуры и все более-менее стандартизируется. Как в беке с этим - хз. Взять вот руби, там много лет практиковалось mvc и никто не парился. Кода много, зато он понятный и простой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из мобильной разработки в бэкенд. История и впечатления