🔨 Stanford CS193p Лекция 4
Заканчиваем неделю уже регулярной еженедельной рубрикой по лекциям из курса по разработке iOS приложений на SwiftUI от Стендфорда. Эта лекция посвящена построению модели игры CodeBreaker и связке её с UI. Это важный этап курса — теперь приложение не просто отображает данные, а игра становится полностью работоспособной с логикой в модели. Вся лекция это лайв кодинг, который отображает подход к иттерационной разработке и выстраивает правильное мышление при решении задачи. Что проходит в лекции:

Повторение архитектуры Model ↔️ View
🔵Model для CodeBreaker — логику игры, проверку ходов, хранение состояния
🔵Отделение логики от UI — ключ к тестируемости и масштабируемости
🔵UI теперь связан с моделью через @StateObject / @ObservedObject / bindings, и игра оживает

Работа с состоянием и обновлениями
🔵Рассматриваются структуры данных и состояния
🔵SwiftUI автоматически реагирует на изменения модели, обновляя интерфейс

Применение Optional, Enum и коллекций
🔵Для Game Status удобно использовать enum и Optional, чтобы чётко описать стадии игры
🔵Такого рода типы делают модель выразительной и безопасной

Интеграция с UI
🔵View без бизнес-логики — модель принимает решения, а UI отображает результат
🔵Обработка событий (нажатие плитки, новая попытка) прокидывается через binding к модели

#cs193p

🔨 Stanford CS193p Лекция 5
Первые дни новогодних праздников позади, а значит пора возвращаться к контенту. Что может быть лучше для начала года чем лекции Стенфорда. Пятая лекция сосредотачивается на архитектуре приложений, модели состояния и связке с UI — это следующий логичный шаг после первых четырёх лекций

🔵Глубокая архитектура приложения — как строить устойчивые, масштабируемые структуры, где Model, ViewModel и View чётко разделены.
🔵Связь модели и UI — через @StateObject, @ObservedObject, @Binding и реактивное обновление View.
🔵Swift Type System в архитектуре — как использовать enum, структуры и Optional для описания состояния приложения
🔵Обработка пользовательских событий — обновление модели, навигация, состояние побед/ошибок.
Все эти подходы помогают перейти от простого UI к полноценному приложению с бизнес-логикой, состояниями и тестируемой моделью

Почему это полезно?
🟡Если вы строите серьёзные приложения на SwiftUI, важно не только знать синтаксис, но уметь проектировать архитектуру
🟡Эта лекция показывает best practices по организации кода, которые работают и для небольших MVP, и для крупных приложений с десятками экранов
🟡Контент из Stanford — один из самых авторитетных источников входа в изучение SwiftUI и архитектуры iOS-приложений

#cs193p

🔨 Stanford CS193p Лекция 6
Новая лекция из курса iOS Development with SwiftUI от Stanford University продолжает тему архитектуры приложений на SwiftUI — от базового разделения Model/View/ViewModel к более сложным паттернам устойчивости и масштабируемости. Лекция полностью состоит из демонстрации, на основе которой после лекции формируется домашнее задание.

Продвинутая архитектура SwiftUI-приложений:
🔵Управление состоянием на уровне всего приложения
🔵Организация логики и зависимостей через Observable, @MainActor, ViewModels
🔵Стратегии для больших проектов (модули, слои, separation of concerns)

Связь Model ↔️ ViewModel ↔️ View
🔵Обновление UI через реактивные свойства (@Published, Binding, @StateObject)
🔵Продвинутые паттерны: сценирование, flows, экраны со сложным состоянием

Работа с навигацией и состоянием
🔵Управление переходами в больших приложениях
🔵Сохранение состояния при смене экранов / вкладок

Домашнее задание:
Создать игру, похожую на CodeBreaker (которую создают в курсе), но с буквами английского алфавита вместо цветных меток, а также со следующими требованиями:
🟢Код и попытки должны быть словами на английском языке. Поэтому в игре используются все 26 букв алфавита как возможные «пины»
🟢UI должен показывать точные и неточные совпадения прямо на буквах (не через отдельные индикаторы)
🟢Кнопки должны быть расположены в виде QWERTY-клавиатуры, чтобы пользователь мог выбирать буквы
🟢Игра должна поддерживать перезапуск, выбор длины слова (от 3 до 6 букв), анимации из предыдущих лекций

#cs193p

🎯 Agent Skills: отказ от AGENTS.md в пользу переиспользуемых знаний для AI-агентов
Оказывается есть аналог глобального AGENTS.md для каждого проекта. Можно настроить общие подходы через скилы.

Skills заменяют AGENTS.md
🔵AGENTS.md — это единый файл с правилами/правилами для вашего AI-агента, но он обычно включает много проект-специфичной информации, которую трудно переиспользовать
🔵Agent Skills — это отдельные, тематические блоки знаний, хранимые в своих папках и которые можно подключать к разным проектам и инструментам

Skill — это каталог, содержащий:
🔵SKILL.md — файл с описанием навыка / инструкциями.
🔵references/ — дополнительные справочные материалы.
🔵scripts, assets — вспомогательные файлы, шаблоны и прочее

Skills позволяют разделять знания по темам, например:
➡️Swift Concurrency
➡️Testing Patterns
➡️SwiftUI Best Practices
➡️Refactoring Guidelines
и использовать их во всей своей экосистеме AI-инструментов

Автор создал Swift Concurrency Skill с модульной структурой:

swift-concurrency/
├── SKILL.md
└── references/
    ├ async-await-basics.md
    ├ actors.md
    ├ tasks.md
    ├ memory-management.md
    └ …

Это даёт агенту глубокий, структурированный контекст, когда он отвечает на вопросы или делает refactor/анализ кода

Преимущества подхода
🔵Повторное использование: навыки можно применять во многих проектах — больше не нужно копировать и править AGENTS.md в каждом
🔵Структурированность: навыки маленькие, тематические, легче поддерживаются
🔵Поддержка инструментов: многие инструменты (например Claude/Claude Code, Cursor) уже поддерживают стандарт Skills, а стандарт открыт
🔵Более качественные ответы: агенту легче выбирать и подгружать только нужные знания, чем держать весь контекст в одном AGENTS.md

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