Modern Mutex

Я уже писал, что пару моих знакомых сеньоров заворачивали на собесах за "несовременность".

Им отказывали ответами "решил классическую задачу архаичным GCD". Комментировать адекватность таких решений я не могу, но это говорит, что нужно тратить немного своего внимания на хайповые и зумерские штуки. Даже если вы никогда их не затроните в проде из-за тяжести легаси 🫣

Из-за чего могут посчитать GCD критически вредным легаси и архаичным? Мы не будем пока глубоко погружаться в Swift 6 и Sendable, но попробуем вкратце, что использование очередей GCD и объявления типов как @unchecked Sendable может часто работать, но смешение GCD с Swift Concurrency — потенциальный источник проблем.

Для этого многие авторы в сети предлагают использовать swift-concurrency-ориентированный подход. С использованием Synchronization Framework. Относительно недавно вот вышел новый Mutex. Чем он отличается от привычного нами Lock? Ну там нет прямого lock()/unlock(), а вместо этого withLock

private let count = Mutex<Int>(0)
count.withLock { $0 += 1 }

Зачем он нужен и когда поможет?
- он более совместим с легаси кодом. Он сам является Sendable, поэтому можно безопасно оборачивать не‑Sendable типы, такие как NSBezierPath, Array и т.п.
- Дает синхронный доступ без async/await
- Меньше накладных расходов по сравнению с actor


Полезные ссылки:
- Modern Swift Lock: Mutex & the Synchronization Framework
- Synchronous Mutual Exclusion Lock 🔒
- Mutex in Swift Lang

What is Mobile System Design?

В чем ключевое отличие мобильного сисдиза от бэкенда? Я не сразу стал мобильным разрабом. До этого я писал пару лет сайты на php, node.js, немного на go. Потом был react и react native разрабом и только потом стал iOS. Сюда я пришел по любви и здесь мне нравится.

Насмотренность и опыт мне помогает сравнить несколько платформ на разных уровнях. И часто я вижу многие заблуждения когда инженеры живут только в одной платформе и в своем вакууме. Одно из таких заблуждений "Что такое System Design?".

Хороший ответ дает второй мой любимый автор Tjeerd in 't Veen, автор книги Mobile System Design, регулярно генерит отличный контент. В своей статье он разбирает отличную тему "что такое мобильный систем дизайн?".

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

Все нюансы не соберешь. Чтение статей и просмотр видосов — полезно, но недостаточно. Это как учить язык только по книгам и видеоурокам. Без разговорной практики ты не начнёшь по-настоящему понимать носителей и хорошо звучать.

В отличие от бэкенд архитектур — мобильные имеют ряд ключевых отличий:
🟣оффлай, синхронизация данных, пуши, диплинки, модульные кодовые базы, кроссплатформенность, постоянные изменения продукта и операционной системы.
🟣UI фреймворки. Мы уже знаем что выбираем SwiftUI для простых экранов, а UIKit для сложных.
🟣Релизы и раскатки. Мобильная апка — это один бинарник на устройствах, который нельзя быстро отменить после установки (либо заранее сильно проработав этот момент). Это требует высокого качества перед релизом, тк ты не откатишь предыдущую сборку.
🟣Архитектура растет не по числу пользователей, а по количеству фич и команд, участвующих в проекте. Это приводит к необходимости модуляризации и новой организационной координации
🟣При большом количестве пользователей даже мелкая ошибка может повлиять на сотни тысяч человек

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

✅ Swift Concurrency: Подборка задач и вопросов для собеседований №2

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

Чтобы не отставать от рынка я и пишу в этом канале. В этой подборке мы узнаем:
🟣как работает Swift Concurrency: компилятор, состояния, жизненный цикл, утечки памяти
🟣что такое suspension point
🟣как работают task, actor, executor
🟣и многое другое

Другие подборки задач:

- Сборник задач по синхронизации асинхронных тасок: GCD
- Шаблон для собеседований № 2
- Подборка задач на Swift Concurrency
- Вопросы для собесов по Swift Concurrency | часть 1

🧬 Получить доступ можно 💰тут или ⭐️ тут

Деградация кодовой базы или code rot

Еще одно популярное заблуждение среди программистов — это код, написанный один раз, всегда остается свежим и рабочим. Забавное совпадение. Почти все мои сложные фичи были большими и с долгим релизным циклом от пары кварталов до года. Я это не выбирал, а как-то само тянуло.

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

🔴Безопасность нетворк слоя и пин-коды. Это фича была в сберздоровье. Где основная логика была в том, что время жизни любого нетворк запроса было равно 5 минутам. Для его "прогрева" мы юзали пинкод как в банке. Здесь мало верстки, но много запутанной логики от чего рождался не менее запутанный код 😄

🟣Мультипрофиль и авторизация. Еще одна большая фича, которую мы делали год в Авито — это мультипрофили. Это сложная логика которая меняла флоу и всю инфу об аккаунте: мессенджер, избранное, тарифы и тп. А аккаунты могут быть личные или компании.

🔘Текущая фича (пока под NDA)

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

В книге Mobile System Design есть крутые правила как минимизировать ущерб:

1️⃣ Проектируй архитектуру, поддерживающую рост. И нет, архитектура — это не про TCA/VIPER/MVP. Это про модуляризацию и масштабируемость.

- Нужно делить фичи на независимые модули
- задумываться о меньшей связи (low couplin)
- упрощать тестирование и замену отдельных модулей.

2️⃣ Делай Self-sufficient features. Это фичи, которые минимально зависят от других фичей напрямую. Общались либо через абстракции, либо через протоколы. И не протекали друг в друга (leaky boundaries)

3️⃣ Использовать BFF (Backend For Frontend). BFF позволяет адаптировать API под конкретные нужды клиента, не нагружая мобильное приложение избыточной логикой.

4️⃣ Фичатоглы, автотесты, contract-first программирование, четкие границы ответственности модулей и инкапсуляция логики. Все это не просто "догмы", а при осознанном программировании и долгих релизах — спасение.

Какие антипаттерны приводят к быстрой деградации?
- Использование глобального состояния (Привет TCA и синглтоны)
- Сквозные зависимости между модулями.
- Повторение бизнес-логики в разных частях приложения.
- Сильная связанность UI и логики (fat ViewControllers).

Полезные статьи:
- Choose Boring Technology
- Coupling and Cohesion
- Legacy Code Rescue: Taming a Thousand-Line View Controller

Ну и мотивирующего вайба вам из инстаграмов🤣

Подборка статей про развитие своего «визибилити»

Слово визибилити мне не нравится. Его использовали уже лет 5, но сейчас еще чаще. Да и я напрямую его не качал. Все как-то само и органически. Но вижу как много «блогов» начало развиваться в эпоху чатгпт и хочется не скатиться в такую же посредственность в гонке за видимость.

Visibility — это ваша узнаваемость, доверие и репутация. Это то, что помогает вам не утонуть среди тысяч других кандидатов.

В чате сообщества мы часто обсуждаем современные проблемы найма. Последний год стало еще хуже:
🔘 огромное число фейковых резюме сломало поиск всем. И новичкам, и старичкам. Даже сеньоры не могу пройти фильтр рекрутеров и попасть на собесы под тысячами однотипных резюмешек
🔘 работодатель перестал пользоваться хх и другими старыми инструментами. После функции «авто-отклик» ему за час прилетают тысячи спам сообщений, в которых не хочется разбираться.
🟡Резюме — уже не главный источник правды.

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

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

Вот в целом полезные статьи как с умом качать видимость:
- Personal Branding for Developers – A Step‑by‑Step Handbook
- How to gain visibility as a software developer?
- What does visibility really mean for engineering teams?

Swift Concurrency: Swift 6 и чекеры

Swift 6 сломает ваш код. Это заключительный пост почему GCD будет считаться архазимом и почему после Swift 6 многие будут опасаться использовать его и брать разрабов только со знанием Swift Concurrency.

Это не просто обновление, а полноценный геймченджер в плане тред-сейфти. Теперь этот язык по-настоящему strict by default.

Что это значит?
Инженер теперь должен думать "А безопасно ли это для многопоточности?" на каждом шаге при работе с async, Task, class, var, и замыканиями:
1. переменные класса должны быть защищены от одновременного доступа
2. Все замыкания в Task должны быть безопасны для многозадачности
3. объекты с изменяемым состоянием нельзя бездумно передавать между тасками
4. нужно захватывать self безопасно: или через @MainActor, или через actor, или избегай shared mutable state.

Что должен переосмыслить инженер?
- изоляция уже часть архитектуры. Теперь появится actor mindset и нужно думать что будет актором, а что просто структурой или классом.
- thread safety уже обязательно. Теперь комплиятор будет не запускать приложение, если увидит потенциальную проблему.
- теперь нужно юзать TaskGroup, DetachedTask, async let почти всегда

Это значит, что придется не просто писать и проектировать "хороший код", а "хороший безопасный код".

Важные ресурсы:
🔘SE‑0302 — Sendable и @Sendable замыкания. Основа потокобезопасности.
🔘Strict concurrency for global variables. Чуть про глобальные свойства
🔘Incremental migration to concurrency checking. Полезный инструмент для миграции.

5/5

Непредвзято о BDUI

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

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

Чтобы узнать мнения о BDUI я собирал опрос "скама в мобильной разработке", а также отношения самих разрабов к технологии. Можно посмотреть реальные цифры от практиков. А почитать некоторые интересные мнения можно тут. Еще на технобренд компаний, где bdui 99% работы можно посмотреть тут.

Но хватит о критике и опустим острые вопросы в стиле "а как искать работу на рынке рабам внутренних велосипедов?" или "почему только разрабы bdui довольны bdui?", и попробуем найти плюсы:

когда ты пишешь сам bdui - хорошо.
когда на нем фичи верстаешь - плохо.
когда ты продакт - хорошо, когда разраб - плохо.
когда ты хочешь стагнировать - хорошо, когда развиваться - плохо. (с) из чата

🟣Если ты разраб BDUI — это хорошо. Так сказали в нашем чате. Один из популярных ответов в комьюнити это мнение, что разрабатывая свой BDUI движок ты легко получишь премии и повышения. Свой BDUI уже начали делать и Х5, и т-банк. Это отличный трамплин для тех, кто хочет быстрых и хороших повышений.

🟣Быстрый Time-to-market. Действительно, после этапа активной разработки, некоторые фичи на уже обкатанных виджетах и компонентах, можно быстрее заделиверить в прод. Мы опускаем некоторые вопросы по тестированию и поддержке, кол-ву багов на проде перед релизом (ведь релизный цикл мобилки давал плюсы к строгому обеспечению качества). Но в целом да, ценной качества ttm чаще быстрее.

Для быстрых MVP решений это хороший выбор.

🟣Повышение уровня абстракции. Тебе правда о многом в простой верстке не нужно думать. Это похоже на лего, где ты делаешь однотипные экраны не думая о сложной верстке.

🟣Консистентность интерфейсов. Визуальный стиль, отступы, размеры, цвета — стандартизировано.

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

Согласны с этими плюсами и какие бы вы выделили отдельно? Может быть что-то забыли?