Страница открывается, кнопка нажимается, форма выглядит аккуратно. Значит ли это, что с кодом всё хорошо? Пока нет: браузер может скрыть ошибку разметки, а форма принять данные, с которыми приложение не умеет работать.
В редакции Mentoring.digital разберём валидацию кода на примере небольшой формы записи. Покажем, какие проверки нужны разработчику, что означает отчёт валидатора и почему сообщение «ошибок не найдено» ещё не завершает работу.
Что называют валидацией кода
Обычно под этим понимают проверку исходного текста по определённым правилам. Для HTML это могут быть требования к элементам, атрибутам и их вложенности. Для программы отдельно проверяют синтаксис, типы, правила проекта и поведение при выполнении. У этих проверок разные инструменты и границы.
Поэтому просьбу «проверь код на валидность» полезно уточнить. Нужно найти ошибки в HTML? Проверить данные из формы? Убедиться, что расчёт соответствует требованиям? Без такого уточнения два человека могут говорить о разных задачах.
Валидация входных данных тоже существует, но это отдельная проверка. Она отвечает на вопрос, допустимо ли полученное значение. Проверка разметки страницы не подтверждает, что сервер правильно обработает это значение.
Разберём форму записи по слоям
Представим учебную страницу: посетитель выбирает дату консультации, оставляет имя и отправляет заявку. Это вымышленный пример, а не результат проверки конкретного сервиса.
- Разметка. Поля и подписи связаны правильно, идентификаторы элементов не дублируются, элементы используются допустимым способом. Часть таких ошибок найдёт HTML-проверка.
- Код поведения. Обработчик отправки существует, обращается к нужным полям и не падает из-за опечатки. Здесь помогают инструменты языка, анализ кода и запуск приложения.
- Данные. Дата распознаётся и соответствует правилам записи. Проверить только формат недостаточно: корректно записанная дата может оказаться недоступной для бронирования.
- Сценарий. После отправки пользователь получает понятный результат, а заявка действительно обрабатывается. Это нужно проверять отдельно от внешнего вида формы.
Если страница прошла проверку HTML, последний пункт всё ещё может не работать. И наоборот: успешная отправка одной заявки не доказывает, что разметка корректна и обработаны все ошибки.
Как пользоваться HTML-валидатором
Начните с небольшого документа или одной страницы. Передайте её адрес либо исходный HTML подходящему проверяющему инструменту. Для современных страниц можно использовать Nu Html Checker. Закрытый код, секреты и личные данные в публичные сервисы отправлять не следует: для рабочих материалов выбирают разрешённую командой среду.
В отчёте найдите описание ошибки и фрагмент, к которому оно относится. Не исправляйте текст только ради исчезновения красной строки: сначала поймите правило. Например, повторяющийся идентификатор требует разобраться, какие элементы и сценарии на него ссылаются.
- Сохраните исходный вариант, чтобы видеть внесённые изменения.
- Разберите первую существенную ошибку и проверьте окружающую разметку.
- Исправьте причину и запустите проверку повторно. Одно нарушение структуры может создавать несколько последующих сообщений.
- Откройте страницу в браузере и повторите затронутый сценарий.
Номер строки в сформированном HTML не всегда совпадает со строкой компонента в проекте. Если страницу собирает шаблон или фреймворк, нужно найти источник проблемного фрагмента. С этим помогает разбор HTML-разметки с наставником: важно научиться объяснять исправление, а не просто копировать предложенную замену.
Что добавляют линтер, тесты и ревью
Линтер проверяет заданные правила и может указывать на подозрительные конструкции. Форматтер приводит запись к согласованному виду. Аккуратные отступы удобны для чтения, но сами по себе не исправляют неверный расчёт или потерянную заявку.
Тесты проверяют ожидаемое поведение на выбранных условиях. Для нашей формы стоит продумать пустое обязательное поле, допустимую дату, недоступную дату, ошибку сети и повторную отправку. Это план учебной проверки: без фактического запуска нельзя утверждать, что сценарии пройдены.
Ревью помогает обсудить решение с другим разработчиком: понятно ли назначение функции, где обрабатывается ошибка, почему выбрана такая проверка. Если пока трудно проследить путь от клика до запроса, полезны занятия по JavaScript с разбором обработки формы. Задача конкретная: объяснить каждый шаг и увидеть, где он может прерваться.
Почему проверки в браузере недостаточно
Пользовательский интерфейс может заранее подсказать, что поле заполнено неправильно. Это улучшает удобство, но не заменяет проверку на сервере: запрос способен прийти в обход формы.
Проверяют и структуру значения, и его смысл для операции. Дата должна иметь ожидаемый формат, а выбранное время должно быть доступно по правилам сервиса. Право записывать другого человека или изменять чужую заявку относится уже к контролю доступа.
Валидация данных также не заменяет другие меры безопасности. Параметризованные запросы к базе и безопасный вывод текста решают свои задачи. Обещание «мы проверили поля, значит приложение защищено» слишком широкое.
Как понять, что проверка завершена
Сформулируйте результат предметно: какой документ проверен, каким инструментом, какие сообщения исправлены и какие сценарии действительно выполнены. Оставшиеся ограничения запишите рядом. Это полезнее общей отметки «код хороший».
Для первого учебного задания возьмите одну форму, составьте список ожидаемого поведения и пройдите его после исправления разметки. Затем предложите другому человеку повторить шаги. Если нужна помощь с выбором условий и описанием ошибки, подойдёт наставник по QA и проверке пользовательских сценариев.
Рабочая привычка проста: автоматическая проверка отвечает на свой вопрос, а разработчик проверяет, решена ли задача пользователя. Именно сочетание этих действий помогает находить ошибки, которые не видны по одной зелёной отметке.
