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