DSL
У программистов на функциональных языках есть болезнь — выдумывать DSL. Не важно, какую задачу они решают, главное — навертеть что-то похожее на язык и назвать его DSL. Потом поехать на конференцию и выступить, чтобы адепты растаскивали толк по телеграм-каналам.
Почему-то все забывают, что в аббревиатуре DSL буква D означает домен. Язык, специфичный для своего домена. Вопрос: есть ли у вас домен, под который вы пытаетесь подогнать язык? Как правило, нет.
Главное свойство домена в том, что он ортогонален другим доменам. Рассмотрим три вещи: Perl, HTML и SQL. Каждая технология занимает свою нишу. Они не пересекаются, а взаимно дополняют друг друга. Поэтому у каждой технологии — свой язык.
Другой пример: язык команд Redis, XML/XSLT, язык R. Все три — разные сущности, пересечения нет, везде свой язык.
То, что программисты называют DSL — это либо данные, по которым бегает фреймворк, либо макросы, чтобы код был короче. Оба подхода хороши до определенной черты, пока проблем не станет больше, чем пользы. Но называть их DSL — делать себе слишком много чести.
Бывает, макросы становятся такими сложными, что их и вправду можно назвать языком. Возможно, в этом случае их проще удалить. В одном из проектов я выкинул библиотеку meander и заменил на линейный код. Божечки, как это было хорошо! Никакой черной магии, все открыто.
Вот почему слово “DSL” пробуждает во мне плохие эмоции. Вам не нужен DSL. Прогуляйтесь до парка, вернитесь и сделайте задачу без DSL.
Нашли ошибку? Выделите мышкой и нажмите Ctrl/⌘+Enter
Юрий, 12th Apr 2024, link
Есть небольшая история про DSL. Полгода назад имел неосторожность сказать техническому директору, что у нас не великий и могучий “DSL”, а “просто Clojure” для автоматизации тестирования. — “Мне эта кложа вообще неинтересна, на рынке нет людей, кто будет на этом писать. Джава или Питон!”. — Аргументы не сработали (а они были). Документирование и фактическое обучение коллег тоже. Пришлось уволиться. Нашлись герои на попытку переписывания всего массива тестов на Питоне. Без магии, линейно, с обильной копипастой, с нестабильными локаторами на самом верхнем уровне теста, вперемешку с тестовыми данными.
“Велосипедный” фреймворк с переменной интенсивностью использовался с конца 2012 года, один раз действительно был представлен на локальной конференции как “велосипед” (в 2013), где более опытные специалисты не нашли ничего “против” подхода. С его помощью было проверено несколько десятков релизов продуктов. Пережил замену clj-webdriver на Etaoin с минимальными затратами. Был полностью интегрирован с другими инструментами тестирования.
Вот сижу и думаю: если бы назвал 500+ специфических функций и макросов (в терминах продукта) “DSL”, результат мог быть другим? Думаю, что нет. :)
Если вдруг у кого-то из читающих комментарий случайно оказались автотесты на Clojure, и нужен человек на автоматизацию, буду рад сотрудничеству. Skype: yuri–online.
Юрий, 15th Apr 2024, link
Из предыдущего комментария выпали две детали:
В описанном мной случае фреймворк автотестирования и общий подход предлагался его автором, увлечённым и талантливым разработчиком, руководству именно как “DSL”: тесты в терминах продукта, как бы это и есть в его понимании доменная область, они ни с чем другим не совместимы и людей легче удерживать, т.к. в другой компании им придётся переучиваться. Кроме того, бытовало мнение, что тестировщики боятся каких-либо традиционных языков программирования, и им нужен упрощённый, “специальный”.
Сразу оговорюсь, что речь идёт о продуктовой компании, было заранее известно, что продукт завтра не свернут, автоматизация рассматривалась как вспомогательный инструмент тестирования, выделенных автоматизаторов не было.
Руководство приняло предложение разработчика и отказалось от уже написанных автотестов на Java (их было немного), чему мы, как тестировщики, пытались сопротивляться по понятным причинам: странные записи в резюме в будущем, полная зависимость от автора и повторная работа по переписыванию кода. Автор фреймворка, как и следовало ожидать, довольно быстро передал дела и уволился, чтобы открыть собственную компанию.
Со временем, привыкнув к польской нотации и немного почитав о языке, я вдруг обнаружил, что могу писать лаконичные сценарии произвольной длины и функции для них в духе старого автокадовского Visual LISP и понемногу развивать фреймворк, добавляя практически нужные мне вещи. Соблюдение принципов DSL-Based Development меня не сильно беспокоило. С тестировщиками мы разработали шаблон сценария в виде традиционного тест-кейса, которого придерживались. Благодаря этому верхний уровень тестов практически не переписывался и пережил 3 реализации front end-а. Соответствует ли конечный результат замыслу автора, писавшего фреймворк, уже установить невозможно. Но мы отказались от предложенной им древовидной структуры данных для тестов (из многоуровневых комбинаций словарей, векторов и списков) в пользу небольших словарей и констант, после этого отпала потребность в некоторых функциях и макросах, работающих с этой структурой.
Код тестов многократно показывали руководству и получали обратную связь (без принуждения команды к Gherkin). Были даже курьёзы, когда человек на обучении, без опыта написания автотестов, видя код теста впервые в режиме видеозвонка, быстрее меня находил интересующую нас строку. Для диагностики длинных e2e-тестов на 10-15 шагов были видеозаписи, понятные тестировщику логи (локаторы хранились отдельно от тест-кейса и подписывались) и возможность запуска фрагментов в REPL. Новые люди без опыта автоматизации начинали писать тесты по образцу сразу после настройки окружения. Тесты ловили реальные ошибки. Случайные или ошибочные срабатывания сводились к минимуму и легко диагностировались. Оставалось добавить параллельный запуск (который нам был не сильно нужен), и тут на более высоком уровне выяснилось, что мы не сможем обучать людей py-тестам для работы в соседних проектах, из-за чего нужно срочно всё свернуть и переписать.
Сейчас придётся привыкать к “принятым в индустрии” языкам, шаблонам и стандартам для прохождения собеседований и практическому применению. Надеюсь, то что я увидел в наспех написанных коллегами py-тестах на замену, всё-таки не является стандартом и будет со временем доработано.
Ivan Grishaev, 15th Apr 2024, link
Юрий, спасибо за такие подробные комментарии, было интересно!