Сравнение подходов и диагностика группы

В предыдущей теме мы различали мобильный сайт, PWA и нативное приложение. Теперь вопрос меняется: какой вариант подходит конкретной задаче и как обосновать решение? У технологии нет универсального первого места. Подход выбирают по требованиям пользователей, возможностям команды и условиям работы.

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

Предыдущая статья: Какие бывают мобильные приложения.

Почему названия технологии недостаточно

Представим заказчика: «Нужно мобильное приложение колледжа». Это ещё не задача для разработки. Неизвестно, кто будет пользоваться продуктом, какие сведения нужны, кто их обновляет и что считается успешной работой. Можно построить сложную программу, которая окажется неудобнее обычной ссылки.

Другой запрос: «Студент выбирает группу и видит ближайшее занятие с аудиторией; расписание обновляет уполномоченный сотрудник». Здесь уже названы пользователь, действие, результат и источник данных. Но пока неизвестно, требуется ли доступ без сети, как проверять актуальность и нужны ли личные учётные записи.

Разработчик не обязан угадывать скрытые желания. Его работа начинается с уточнения условий. Вопрос «что должно происходить при отсутствии интернета?» часто полезнее, чем ранний спор о языках программирования.

Отделяйте подтверждённое требование от предположения. «У всех студентов есть Android» — утверждение, которое требует сведений о группе. Пока они не получены, разумно учитывать разные устройства или прямо ограничить пилот. Такое ограничение должно быть явным, а не обнаруживаться при сдаче проекта.

От пожелания к сценарию

Рабочее описание можно составить по четырём вопросам:

1. Кто действует?
2. Что он делает?
3. Какой результат получает?
4. При каких условиях результат должен сохраняться?

Для расписания: «Студент открывает страницу на телефоне, выбирает группу и видит занятия на выбранную дату. При отсутствии сети видит последнюю сохранённую таблицу с предупреждением». Последняя фраза добавляет отдельное требование, а не просто украшает описание.

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

Проверяемое требование связано с наблюдением. Вместо «быстро и удобно» можно записать: «Выбранная группа видна на экране; для просмотра следующего занятия не требуется повторно вводить её название». Точный предел времени запуска можно задавать только вместе с условиями измерения: устройством, сетью и объёмом данных.

Критерий приёмки — описание того, как убедиться в выполнении требования. Например: «Загрузить расписание, отключить связь, закрыть и снова открыть приложение. Убедиться, что сохранённая таблица и дата обновления отображаются». Если после этого есть только пустой экран, автономный сценарий не выполнен.

Минимальный полезный результат

Для первого проекта важно выбрать небольшой завершённый сценарий. «Расписание, чат, оценки, карта и уведомления» — несколько продуктов с разными рисками. Начальный результат может быть гораздо меньше: выбор группы и отображение учебного расписания из подготовленных данных.

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

Расширение происходит по шагам: сначала корректный показ, затем выбор даты, потом сохранение предпочтения, позже получение обновлений. После каждого шага можно проверить поведение. Так легче найти ошибку и объяснить, что уже работает.

Полезно различать демонстрационный макет, работающий локальный прототип и продукт для реальных пользователей. Макет показывает идею. Прототип выполняет ограниченный сценарий. Реальный продукт дополнительно требует заботы об актуальности, доступе, восстановлении после ошибок и сопровождении. Красивый макет нельзя выдавать за готовую систему колледжа.

Критерии выбора

Критерии имеют разный вес. Если приложение обязано выполнять особую операцию устройства, отсутствие её поддержки исключает вариант независимо от красивого интерфейса. Если нужен только просмотр информации по ссылке, глубокая системная интеграция может не иметь значения.

Не следует без основания присваивать технологиям оценки вроде «скорость 9 из 10». Такая цифра выглядит точной, но скрывает условия. В учебном сравнении лучше писать: «выполнимо», «нужен эксперимент», «не подходит при данном обязательном требовании» и объяснять причину.

Полный разбор: расписание колледжа

Исходные условия

Рассматриваем учебный пример, а не согласованное внедрение в колледже. Пользователь — студент. Нужны выбор группы, дата, список занятий и аудитории. Данные меняются. Не предполагаем, что у всех одинаковые телефоны или что установка обязательна.

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

Новое требование: отсутствие связи

Заказчик добавляет: «Расписание нужно видеть в дороге». Уточняем: последнюю сохранённую версию или любые свежие изменения? Это принципиально разные обещания. Без связи невозможно получить изменение, о котором устройство ещё не знает.

Реалистичное требование — показать последнюю успешно загруженную таблицу, дату её обновления и предупреждение. PWA можно рассматривать для такого сценария, но само название не обеспечивает сохранение. В нативном решении тоже пришлось бы реализовать локальную копию.

Новое требование: редактирование

Студентский просмотр и служебное редактирование — разные роли. Если любой посетитель сможет менять аудитории, продукт станет ненадёжным. Поэтому права редактирования, проверка изменений и серверная часть требуют отдельного проектирования. Для первого учебного проекта можно использовать подготовленные демонстрационные данные без личной информации.

Предварительное решение и проверка

Начать с мобильного веб-прототипа на учебных данных. После проверки интерфейса отдельно добавить и испытать автономный сценарий; при необходимости — установку. Не обещать реальные обновления колледжа до согласования источника данных и доступа.

Проверки: выбор существующей группы, пустое расписание, неизвестная группа, узкий экран, отсутствие сети и устаревшая копия. Успех в одном идеальном случае не покрывает остальные.

Второй случай: личный счётчик привычки

Минимальный сценарий: пользователь отмечает выполнение действия; число увеличивается; результат восстанавливается после повторного запуска. В первой версии достаточно одного устройства и локального хранения. Сеть для увеличения числа не нужна.

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

Затем появляется пожелание: «Хочу видеть результат и на другом телефоне». Теперь локального хранения недостаточно. Нужно определить, как переносить или согласовывать данные. Учётная запись и серверная синхронизация — один из возможных вариантов, но это заметное расширение проекта.

Ещё одно требование: «После очистки браузера результат должен сохраниться». Оно тоже не следует автоматически из локального хранения. Нужны резервирование, экспорт либо иной согласованный способ восстановления. Лучше заранее обозначить ограничение первой версии, чем обещать сохранность, которой нет.

Проверка: несколько отметок, повторный запуск, отсутствие связи, случайное повторное нажатие, очистка данных в специально созданной тестовой среде. На личном устройстве нельзя удалять реальные данные ради демонстрации.

Третий случай: фотография

Заказчик говорит: «Нужно приложение для фото». Возможные сценарии совершенно разные: выбрать готовое изображение; сделать снимок; уменьшить размер; применить фильтр; управлять особыми параметрами камеры; выполнять тяжёлую обработку.

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

Не следует собирать лишние разрешения. Доступ ко всем фотографиям не всегда нужен для выбора одного файла. Также требуется понять, остаётся ли изображение на устройстве или отправляется на сервер, и сообщить это пользователю.

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

Условия учебной работы

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

В курсе предусмотрен путь от визуальных блоков к веб-программированию, затем к публикации и PWA. Android-направление зависит от реально проверенной среды. Такой порядок позволяет осваивать действия, состояние и данные постепенно. Он не означает, что один подход всегда лучше остальных.

Если сервис недоступен, возможны подготовленный снимок интерфейса и бумажное проектирование. Но просмотр преподавательской демонстрации нельзя засчитать как самостоятельную сборку студентом. Нужно различать «увидел», «объяснил» и «выполнил».

Для выбора темпа не требуется собирать лишние личные данные. Достаточно понять навыки и доступные учебные средства. Ответ «не работал с этим» полезен: он показывает, с чего начинать объяснение.

Диагностика: задания

Диагностика выполняется индивидуально на бумаге или в текстовом файле. Время — около 15 минут. Можно написать «не знаю» и указать, какая часть непонятна. Задача — увидеть ход мысли, а не угадать термин.

Условие и граничное значение

Псевдокод — запись алгоритма понятными словами, без привязки к синтаксису языка:

если число > 10:
    вывести «Большое»
иначе:
    вывести «Не больше десяти»

Что будет выведено для 12, 10 и 7? Почему значение 10 важно проверить отдельно?

Последовательность и состояние

счётчик = 2
счётчик = счётчик + 1
счётчик = счётчик + 1

Какое значение получится? Что означает знак = в этой записи: сравнение или присваивание нового значения?

HTML и CSS

<h1>Расписание</h1>
<button>Показать группу</button>

button {
  color: blue;
}

Что задаёт HTML, что меняет CSS? Есть ли здесь правило, которое после нажатия действительно выбирает группу? Незнакомые элементы можно описать своими словами.

Поиск причины ошибки

Кнопка видна, но нажатие не меняет число. Назовите два вопроса или действия, с которых начнёте проверку. Не требуется знать устройство браузерных инструментов; важен разумный порядок поиска.

Сохранение

После закрытия программы результат исчез. Доказывает ли это, что арифметика была неверной? Какой отдельный сценарий следует проверить?

Выбор технологии

Нужно показывать расписание на разных телефонах по ссылке. Установка пока не нужна. Какой подход вы рассмотрите первым? Какое дополнительное требование может изменить решение?

Опыт работы

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

Ответы и объяснения

Как читать результаты диагностики

Неправильный ответ может означать незнакомый термин, ошибку чтения или недостаток понимания. Поэтому полезно попросить объяснить один пример словами. Студент, который не знает названия «присваивание», но правильно описывает изменение счётчика, уже понимает существенную часть идеи.

Если большинство ошибается на значении 10, нужно подробнее разобрать условия и границы. Если путают HTML с поведением кнопки, важно наглядно разделить структуру, оформление и логику. Если результат после закрытия объясняют «плохим интернетом» без связи с хранением, следует вернуться к местоположению данных.

Обобщённая карта группы может содержать четыре строки: последовательность действий, условия, структура веб-страницы, проверка ошибок. Для каждой отмечают «понимают», «понимают частично», «нужно объяснить». Это ориентир для следующих занятий, а не окончательный вывод о способностях человека.

Дополнительные задачи

1. Заказчик требует свежие изменения расписания без какой-либо связи с источником. Объясните противоречие и предложите честный вариант требования.
2. Команда выбрала инструмент, но он запускается только на компьютере одного участника. Какие сведения нужно собрать до продолжения?
3. Пользователь хочет счётчик без сети и общий результат на двух телефонах. Разделите локальную работу и обмен данными.
4. Для расписания придумайте три отрицательных случая и ожидаемую реакцию интерфейса.

Итог и способ проверки

Обоснованное решение включает задачу, существенные требования, предварительный подход, ограничение и проверку. Утверждение «выбираю эту технологию, потому что она популярная» не заменяет этих пунктов.

Проверка результата: составьте короткое описание одного из трёх проектов по пяти пунктам: пользователь; минимальный сценарий; обязательные условия; выбранный подход с обоснованием; испытание, которое обнаружит невыполнение требования. Допускаются разные решения. Отдельно отметьте сведения, которые ещё нужно узнать.

После диагностики преподаватель получает исходную карту навыков группы. Дальнейшее знакомство с визуальными блоками позволит проверить те же идеи на работающем примере: действие пользователя, правило, изменение состояния и видимый результат.