«Всю веброзробку повільно поглинає хаос»: як я пропрацював з Android 10 років та чому більше туди не повернуся

У своїй статті на Medium розробник та архітектор Мартін Новосад пояснює, чому він назавжди залишив Android-розробку після майже 10 років роботи у цій сфері. Але спочатку трохи розповість, як будував свою кар’єру.

Передаємо йому слово.

Старі добрі часи

Я почав свою кар’єру Android-розробника у 2013 році, коли Android 4.4 був ще новинкою. AsyncTasks сприймались як стандарт, у нас були OttoEventBus та інші жахливі речі. Я був свідком того, як змінювались архітектурні тренди: від MVC до MVP/MVI, потім до MVVM і, нарешті, до поєднання MVVM/MVI.

Я пам’ятаю часи, коли RxJava була новинкою. Пам’ятаю, як розробники (привіт, Джейк Уортон) говорили про нову мову Kotlin. Я пам’ятаю, як Kotlin ставав все популярнішим та змінював сферу Android-розробки.

Пам’ятаю, як з’являлися корутини, які спочатку сприймались як «вбивці RxJava» («Гей, тепер ви можете писати весь асинхронний код синхронізованим способом! Немає потреби у потоках!»). Чарівна ідея, але не досконала. Проте низькорівневі асинхронні примітиви, такі як Channels, стали Rx-Way для Kotlin.

Пам’ятаю веселі розмови з моїм колегою Девідом про стани та події. Що таке стан і що таке подія? Що подія робить із станом і навпаки?

Я пам’ятаю, як не спав цілу ніч, щоб вивчити Dagger 2: це було ще до того, як її замінили Koin та Dagger Hilt. Пам’ятаю, як уперше прочитав книгу «Чиста архітектура» дядечка Боба: визначальний момент, що вплинув на мою кар’єру.

Тепер я міг розробляти та писати майже всі застосунки, не думаючи про MVVM/MVP/MVC чи будь-які інші деталі, специфічні для платформи. Я дізнався, чому тестування є важливим, я спробував TDD і полюбив та зненавидів його. Я дізнався про DDD і BDD.

Мій поїзд під’їжджає до кінцевої станції?

(Я обрав цей підзаголовок, тому що пишу цю статтю у потязі, який прямує зі Швейцарії до Німеччини)

Час йшов і я раптом опинився на посаді, де керую командами великих підприємств, таких як Porsche чи IBM. Це була чудова поїздка, хоча я відчував, що після шести-семи років роботи я досяг того, чого прагнув.

Я працював над складними застосунками з інтенсивним шифруванням E2E, зв’язком із датчиками, чіпами NFC, маяками BLE, застосунками для чату з високим трафіком і з легендарними застосунками для списків справ.

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

Мій попередній досвід у бекенді

Мені пощастило, що протягом останніх чотирьох-п’яти років я інколи працював над бекенд-частиною проєктів моїх клієнтів. 

Я витратив багато часу на те, щоб зрозуміти тонкощі бекенд-розробки:

• написання супровідного коду;
• створення розподіленої системи;
• вертикального та горизонтального масштабування;
• обробки розподілених транзакцій;
• різних типів баз даних;
• яку базу даних слід використовувати для якого типу даних.

Я рефакторив системи Java EE у Go. Дивлячись на отриманий двійковий файл, скомпільований Go, оцінюючи як він використовує пам’ять та наскільки незначним є об’єм, що використовується, я зрозумів, чому Go такий популярний.

Проблеми, які я вирішував як бекенд-розробник не йдуть у жодне порівняння з тими, які я мав на Android (я розповім про них незабаром). Це було щось значно більше, ніж пересування пікселів у Android-розробці.

Чи справді Android — те, що мені треба?

Згодом я втомився від усіх зустрічей із UI/UX-дизайнерами та пояснень основ матеріального дизайну або чому ми не можемо викликати «просто так» поведінку X у застосунку Y.

Я пам’ятаю, як годинами говорив про проєкти, що призводило до того, що мій мозок зрештою вимикався. 

Коли команда розуміла чисту архітектуру та предметно-орієнтовану розробку, нам вдавалось написати домен + рівні даних за дуже короткий час. Щойно ви поясните різні auth-потоки команді, обробка правильної логіки оновлення маркерів стає досить простою.

Майже завжди основний виклик — це UI-рівень, який постійно стає іншим через зміну API фреймворку. На UI сильно вплинули UI/UX дизайнери та POs.

Останнім часом майже всі мої проєкти перетворилися на повсякденну роботу. Мова йшла не так про розробку, як про бізнес, а процес роботи найчастіше був пов’язаний з Android API.

У найкращому випадку у мене було завдання щось оновити, наприклад, написати Custom View та використати лінійну алгебру, але найчастіше це завдання було нудним. 

Я думав: навіщо це мені? Звісно, гроші – це добре. Але скоро мені буде 30 років. Чи бачу я себе у цій сфері?

Як досвідчений розробник Android, я можу претендувати лише на вакансії, де потрібно працювати з Android. Усі мої навички були побудовані на розробці зручного, чистого коду, який правильно працює на платформі Android.

Що я буду робити, якщо зникне Android? Та й набір навичок, які ми розвиваємо під час своєї роботи, має дуже відносну цінність для більшості компаній, де б ми спробували претендувати на посаду керівника чи штатного інженера-програміста.

Занепад Android-розробки

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

Також я не хотів вивчати нові бібліотеки Android, щоб краще керувати життєвим циклом Android або навігацією: все одно через плюс-мінус рік виникне щось нове. Я уже проходив це кілька разів.

У кожному новому поколінні розробників з’являється хтось, хто прагне написати нову бібліотеку для обробки вашого UI стану або нову бібліотеку навігації. Тести? Звісно, ні. Але, на жаль, багато розробників обирають ці бібліотеки. Розробка Android повільно поглинається хаосом, як і вся веброзробка (ви пробували встановити create-react-app? Ви завантажите тисячі бібліотек, у тому числі деякі вразливі).

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

Тепер у моїх планах є те, про що я не думав, коли займався Android:

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

Я відчуваю, що мені знову цікаво працювати, бо є складні інженерні проблеми, які потрібно вирішувати.

Сумно, але простий Android-розробник навряд чи зможе стати архітектором чи інженером (неважливо, керівна посада, чи ні). У нього просто немає необхідних навичок. 

Тому це був цікавий етап моєї кар’єри, але я більше ніколи не повернусь у проєкти як Android-розробник.

Автор: Мартін Новосад

Текст адаптувала Євгенія Козловська