Начинайте с дорогих ошибок
Линтер способен проверить тысячи предложений за секунды, поэтому хочется закодировать в нём каждое редакционное предпочтение. Не стоит. Первые правила должны ловить то, что дорого проверять вручную: неправильные названия продукта, дрейф терминологии, опасные формулировки, неоднозначные предупреждения и повторяющиеся ошибки оформления.
Если первый запуск выдаёт сотни малополезных предупреждений, команда научится игнорировать инструмент раньше, чем он заслужит доверие.
Относитесь к правилам как к коду
Храните конфигурацию Vale и словари в репозитории, ревьюйте их изменения и давайте правилам имена, которые объясняют намерение. ApprovedProductNames обсуждать легче, чем RegexRule17.
Полезно иметь небольшой набор примеров, которые обязаны проходить и падать. При изменении правила ожидаемое поведение должно меняться вместе с ним.
Разделяйте ошибки и рекомендации
Блокируйте сборку только по тем проблемам, которые команда действительно считает обязательными к исправлению. Для случаев, где требуется редакционное суждение, используйте warning. Пассивная конструкция иногда уместна; устаревшее написание товарного знака обычно менее спорно.
Так CI остаётся предсказуемым: автор понимает, какие находки мешают публикации.
Настройте терминологию
Именно терминология часто даёт самый быстрый эффект. Централизованно храните допустимые названия, регистр и замены. Продуктовые исключения добавляйте явно, а не отключайте полезное правило целиком.
Ложные срабатывания тоже дают информацию: иногда ошибочно правило, а иногда контент-модель заставляет употреблять термин непоследовательно.
Оставьте человеческую редактуру людям
Vale не определит, отвечает ли объяснение на реальный вопрос пользователя, правильно ли размещена информация и обучает ли пример верной модели. Автоматизируйте повторяемые дефекты, а редакционное внимание тратьте на структуру, доказательства и ясность.
Хороший quality gate почти скучен: он каждый раз ловит одни и те же важные ошибки и редко удивляет автора.
Практический разбор
Рассматривайте «Vale как quality gate, а не полиция запятых» как небольшое испытание, а не сравнение списков функций. Возьмите три реальных материала: простую страницу, страницу с кодом или структурированными данными и неудобный материал с навигацией, переиспользованием или локализацией. Прогоните все три через выбранный инструмент или подход и отдельно запишите, что стало проще, а какая новая стоимость сопровождения появилась.
Оценивайте повторяющуюся работу команды:
- понятен ли исходник автору без специальной подготовки;
- видит ли рецензент содержательный diff;
- сообщает ли сборка об ошибке так, чтобы было понятно, что исправить;
- можно ли переносить, локализовать и переиспользовать контент без ручной чистки.
Не награждайте инструмент за красивую демонстрацию, которую реальный контент не выдерживает. Хороший инструмент уменьшает неопределённость в написании, ревью и публикации. Если сложность просто переехала в конфигурацию, хрупкие плагины или память одного специалиста, это тоже часть цены.
Короткий редакционный чек-лист
- Начинайте с дорогих ошибок. Линтер способен проверить тысячи предложений за секунды, поэтому хочется закодировать в нём каждое редакционное предпочтение.
- Относитесь к правилам как к коду. Храните конфигурацию Vale и словари в репозитории, ревьюйте их изменения и давайте правилам имена, которые объясняют намерение.
- Разделяйте ошибки и рекомендации. Блокируйте сборку только по тем проблемам, которые команда действительно считает обязательными к исправлению.
- Настройте терминологию. Именно терминология часто даёт самый быстрый эффект.
