Architecture Decision Records
Мы уже выяснили, что архитектуры — это не про выбор паттерна между VIPER/TCA/MVP. Писали это посте "Вы переоцениваете UI-архитектуры" и "О, нет! Ты выбрал неправильную UI архитектуру!". И нет, выбор архитектуры это тоже не про шаблонное рисование схем "System Design Interview: как сделан ютуб".
Выбор архитектуры — это оценка ресурсов, сроков. Где выбирая архитектуру ты должен задумываться об ее росте и сопротивлению деградации. Так тебе и команде проще жить.
Теперь перейдем из абстрактных советов к практике. Один из важных инструментов, которые помогают разрабам — это ADR.
В больших и сложных проектах, где внедрение или изменение технологий может идти годами. Может произойти такой момент, где все потеряют смысл и вектор происходящего. Зачем мы это делаем? Почему такое было сделано? Куда мы идем?
В этот момент помогают такие инструменты как TDR или ADR. На моей работе даже сейчас одна из сложных задач — это понять и зафиксировать вектор, а также не размыть и потерять все контексты.
Если у вас такие же проблемы, то вот отличные подборки публичных гайдов:
🌟 adr-tools
🌟 Amazon
🌟 GitHub
🌟 RedHat
Мы уже выяснили, что архитектуры — это не про выбор паттерна между VIPER/TCA/MVP. Писали это посте "Вы переоцениваете UI-архитектуры" и "О, нет! Ты выбрал неправильную UI архитектуру!". И нет, выбор архитектуры это тоже не про шаблонное рисование схем "System Design Interview: как сделан ютуб".
Выбор архитектуры — это оценка ресурсов, сроков. Где выбирая архитектуру ты должен задумываться об ее росте и сопротивлению деградации. Так тебе и команде проще жить.
Теперь перейдем из абстрактных советов к практике. Один из важных инструментов, которые помогают разрабам — это ADR.
Когда архитектура ПО развивается в результате ряда решений, которые сами по себе рождаются из гипотез и экспериментов, проверяющих эти гипотезы, командам разработчиков нужен способ отслеживать принятые ими архитектурные решения.
В больших и сложных проектах, где внедрение или изменение технологий может идти годами. Может произойти такой момент, где все потеряют смысл и вектор происходящего. Зачем мы это делаем? Почему такое было сделано? Куда мы идем?
В этот момент помогают такие инструменты как TDR или ADR. На моей работе даже сейчас одна из сложных задач — это понять и зафиксировать вектор, а также не размыть и потерять все контексты.
Если у вас такие же проблемы, то вот отличные подборки публичных гайдов:
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - joelparkerhenderson/architecture-decision-record: Architecture decision record (ADR) examples for software planning, IT…
Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation - joelparkerhenderson/architecture-decision-record
1
DispatchQueue.main.async ВСЁ! Теперь в современном мире мы используем MainActor. Но с ним есть множество нюансов, которые нужно учитывать.
Большинство иосеров думают, что @MainActor просто гарантирует выполнение кода на main thread. Но это лишь верхушка айсберга. Реальная магия и потенциальные проблемы скрываются в том, КАК именно Swift изолирует ваши данные.
Допустим, что если класс помечен @MainActor, весь код выполняется на main thread, верно?
@MainActor
class ViewModel: ObservableObject {
@Published var data: [Item] = []
// Весь ли код выполнится на main thread?
func loadData() async {
let items = await apiService.fetchItems()
self.data = items
}
}
На самом деле MainActor изолирует только доступ к свойствам, а не выполнение методов. Из прошлых постов про изоляцию мы уже поняли что await может переключить контекст.
Почему это важно? Ну, во-первых, это может сломать код, если после await apiService вы работаете с UI элементами.
Давайте разберем еще несколько важных примеров, где MainActor === изоляция данных, а не изоляция выполнения кода. Я мало где видел, чтобы спрашивали такие детали. Можете брать задачи для собеседований в свою компанию.
Полезные ссылки:
- MainActor usage in Swift explained to dispatch to the main thread
- @MainActor – The Rules!
- How to use @MainActor to run code on the main queue
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from TechSparks
Гугл не только других учит, как ИИ использовать, но и сам отчитался о целых 14 способах, которыми его сотрудники используют ИИ.
1. Естественно, генерация кода. 30% нового кода пишет ИИ
2. Ускорение всей разработки. Не только написание кода, но и его ревью, тестирование, миграции.
3. Приоритизация и починка багов
4. Помощь с креативами
5. Написание контента
6. Создание всякого визуального
7. Тестирование новых идей
8. Ускорение создания коммерческих предложений
9. Улучшение качества лидов
10. Генерация заметок после встреч и обсуждений
11. Безопасность пользователей на всех платформах: обнаружение контента, нарушающего правила
12. Улучшение работы с отзывами пользователей
13. Поиск новых талантов для найма
14. Снижение количества пищевых отходов
Масштаб, конечно, разный у разных пунктов, но в целом подход впечатляет. И это только начало, утверждается: Ultimately, AI not only boosts efficiency and fosters creativity but also leads to the creation of new roles and opportunities that help our teams concentrate on high-impact work
https://blog.google/technology/ai/google-ai-workplace-examples/
1. Естественно, генерация кода. 30% нового кода пишет ИИ
2. Ускорение всей разработки. Не только написание кода, но и его ревью, тестирование, миграции.
3. Приоритизация и починка багов
4. Помощь с креативами
5. Написание контента
6. Создание всякого визуального
7. Тестирование новых идей
8. Ускорение создания коммерческих предложений
9. Улучшение качества лидов
10. Генерация заметок после встреч и обсуждений
11. Безопасность пользователей на всех платформах: обнаружение контента, нарушающего правила
12. Улучшение работы с отзывами пользователей
13. Поиск новых талантов для найма
14. Снижение количества пищевых отходов
Масштаб, конечно, разный у разных пунктов, но в целом подход впечатляет. И это только начало, утверждается: Ultimately, AI not only boosts efficiency and fosters creativity but also leads to the creation of new roles and opportunities that help our teams concentrate on high-impact work
https://blog.google/technology/ai/google-ai-workplace-examples/
Google
14 ways Googlers use AI to work smarter
See how Googlers are using tools like Gemini and Imagen to save time, spark new ideas and build more helpful products.
ADR, System Design и глобальные рефакторинги
Кстати, отличная новость для тех, кто не знает чем заняться в субботу.
❣️ Тут в Яндексе устраиваем фестиваль практики и технобатлов для мобильных разрабов.
Если хотите увидеться, то я выступаю с нашим руководителем мобилки. Это не совсем доклад, а peerlab. Здесь ценится обмен живым опытом и общение.
На нем мы:
🌟 поделимся опытом с каким вызовами сталкиваемся в разработке сложных продуктов большой экосистемы
🌟 обсудим про mobile system design
🌟 какие сложные задачи мы делаем в команде
🌟 как планируются и реализуются сложные рефакторинги
🌟 что такое ADR и как у нас происходит арх.ревью
Короче, глубоко погрузимся в Mobile System Design. Здесь будет много практики и закрытой кухни, которую обычными докладами и статьями не перенесешь.
А также многое другое. На этом ивенте мы будем много общаться и дискутировать.
📍 Приходите поддержать)
Кстати, отличная новость для тех, кто не знает чем заняться в субботу.
Если хотите увидеться, то я выступаю с нашим руководителем мобилки. Это не совсем доклад, а peerlab. Здесь ценится обмен живым опытом и общение.
На нем мы:
Короче, глубоко погрузимся в Mobile System Design. Здесь будет много практики и закрытой кухни, которую обычными докладами и статьями не перенесешь.
А также многое другое. На этом ивенте мы будем много общаться и дискутировать.
Please open Telegram to view this post
VIEW IN TELEGRAM
2
Вам больше не нужны фреймворки и шаблонные архитектуры.
Есть более фундаментальные и важные принципы, которые лежат глубже, чем SOLID. Они настолько базовые и естественные, что часто не проговариваются явно. Они становятся чем-то вроде "инстинктов" программиста. Настолько встроены в мышление, что воспринимаются как само собой разумеющееся.
К таким относятся KISS, DRY, YAGNI. А SOLID — это уже надстройка, а в основе лежат вот эти глубинные принципы, которые пронизывают всю инженерию. По сути, тру инженер не просто берет готовые фреймворки и надстройки, но и легко может оценить их с позиции фундаментальных принципов, которые являются атомами любой идеи или технологии.
Когда ты работаешь в компании из 100 разных команд, которые придумывают каждый месяц переосмысление очередных велосипедов, то ты не смотришь на шаблоны и фреймворки. Ты смотришь на ДНК системы:
- Какие проблемы это реально решает?
- Улучшает ли это бизнес, или это просто модная штука ради наград, о которой через год забудут?
- Понимают ли авторы и разрабы этой штуки реальные проблемы или это каргокульт?
Удивлен, что мало кто говорит про самый полезный принцип, который вызывает больше всех споров и стал отцом избыточных и фригидных фреймворков а-ля TCA, — Separation of Concerns.
Суть в самом принципе: чистое разделение ответственности даёт масштабируемость и ясность, без которых не живёт ни одна система.
Separation of Concerns отлично заходит с большими масштабами. Где четкие шаблоны не работают. Например, с модуляризацией проекта.
Пример:
У нас есть огромный монолит. Когда было 2-3 разраба все всех устраивало. Не было проблем с пониманием кто за что отвечает. Как только кол-во разрабов сильно выросло, то с масштабами и быстрым ростом кодовой базы, появилось много новых проблем с которыми прошлая инфраструктура не справляется.
Симптомы переросшего монолита:
- Смешение зон ответственности
- Снежный ком зависимостей
- Медленные сборки и "мертвые" ветки
- Неясная ответственность команд
Многие решают такую проблему натягивая на проект общую архитектуру а-ля VIPER/TCA. Но это работает исключительно в слабой инженерной культуре, где большинство джунов, готовых следовать правилам по инструкции.
Если же в компании много сеньоров, то диктатура фреймворка скорее мешает. Тут важнее другое: правильно разграничить зоны ответственности и доверять инженерам. Не загонять всех в один жёсткий шаблон, а строить архитектуру так, чтобы свобода внутри команд оставалась, но при этом система не разваливалась.
Так зачем нужен Separation of Concerns?
Separation of Concerns — это принцип, который помогает системам расти без хаоса и жестких ограничений шаблонных архитектур, которые чаще ломают большие проекты и не создают культуру доверия внутри проекта. Правильное понимание и ощущение принципа помогает не скатываться в диктатуру и шаблонность, которая будет вставлять палки в колеса своими ограничениями.
Полезные ссылки:
- Separation of Concerns in Software Design
- Separation of Concerns (SoC)
Please open Telegram to view this post
VIEW IN TELEGRAM
Alexey Naumov
Separation of Concerns in Software Design
Applying the fundamental Computer Science principles for improving the quality of the software at all levels
2