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