97 этюдов для программистов. Опыт ведущих экспертов

Представляют собой текстовое или графическое описание языка, причем текстовые DSL встречаются чаще графических. Текстовые выражения могут проходить обработку в цепочке, включающей в себя лексический анализатор, анализатор синтаксиса, преобразователь модели, генераторы и любые другие средства постобработки. Как правило, выражения не независимых DSL преобразуются во внутренние модели, служащие основой для дальнейшей обработки. Полезно определить грамматику (например, в виде РФБН[10]). Грамматика служит отправным пунктом для создания элементов инструментальной цепочки (например, редактора, визуализатора, генератора анализаторов синтаксиса). Для простых DSL может оказаться достаточно анализатора синтаксиса, созданного вручную — например, на основе регулярных выражений. Если требования к анализатору синтаксиса достаточно сложны, созданный вручную анализатор синтаксиса может стать слишком громоздким, и следует обратить взор на такие инструменты для работы с грамматиками и DSL, как openArchitectureWare, ANTLR, SableCC, AndroMDA. Довольно часто независимые DSL определяют в виде диалектов XML, но с чтением в этом случае могут быть сложности, особенно у неспециалистов.

Всегда следует принимать во внимание целевую аудиторию вашего DSL. Из кого она состоит — из разработчиков, менеджеров, клиентов или конечных пользователей? В зависимости от целевой аудитории нужно выбирать технический уровень языка, доступные пользователю функции, инструмент для подсказки по синтаксису (например, IntelliSense), средства ранней валидации, визуализации и представления. Скрывая технические детали, DSL отдает власть пользователям, предоставляя им возможность адаптировать системы к собственным потребностям, не прибегая к помощи разработчиков. DSL позволяет еще и увеличить скорость разработки благодаря распределению задач после того, как создан начальный каркас языка. Язык может развиваться постепенно. Существуют также различные способы перевести существующие языки и грамматики на новый DSL.

Не бойтесь что-нибудь сломать

Майк Льюис

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

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

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

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

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

Не прикалывайтесь с тестовыми данными Род Бегби