Применение генераторов кода

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

1. генерация пользовательского интерфейса;
2. генерация документации;
3. применение генерации в тестировании приложения:
   • генерация тестирующего кода,
   • генерация тестовых данных;
4. работа с данными и форматами.

В данной лекции сделаем обзор преимуществ и особенностей указанных применений, рассмотрим рекомендации по их наилучшему внедрению.

Генерация пользовательского интерфейса

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

Что дает нам генерация пользовательского интерфейса? Рассмотрим те преимущества, которые дает нам генерация пользовательского интерфейса:

• возможность абстрагировать бизнес-процессы от конкретной реализации пользовательского интерфейса. Впоследствии это позволит быстрее переходить к новым технологиям и платформам, изменять или внедрять новые бизнес-процессы. Абстрактная форма независима от технологии и остается прежней. С минимальными изменениями ее можно использовать в генерации кода для новой технологии. Это является очень важным свойством, так как технологии разработки пользовательского интерфейса развиваются и меняются весьма быстро, по сравнению, например, с технологиями баз данных;
• возможность систематизировать пользовательский интерфейс и сделать его единообразным во всем приложении. Это относится как к внешнему виду и функциональности, так и к внутреннему содержимому, организации структуры кода и соответствия ее стандартам;
• скорость внедрения. Изменения могут быть быстро распространены по всему приложению, достаточно либо изменить шаблоны, либо изменить абстрактный файл определений;
• гибкость к изменениям. Разделение метаданных и шаблонов, а также большая скорость внедрения изменений при генерации позволяют легко и быстро модифицировать приложения. Можно внедрять несколько вариантов исполнения пользовательских операций, тем самым формируя богатый функциональный интерфейс;
• существенно снижается количество ошибок. Сведен к минимуму человеческий фактор при работе с кодом пользовательского интерфейса, содержащего еще множество вызовов и команд, относящихся к другим уровням приложения.

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

Чтобы весь этот код разнородного характера не препятствовал эффективной генерации, следует в первую очередь минимизировать объем кода, не относящегося к пользовательскому интерфейсу. Его следует минимизировать в объеме путем оптимизации, а также создания и вызова соответствующих процедур в библиотеках функций. Также следует создавать максимально структурированные и хорошо иерархически организованные шаблоны. Все это позволить иметь интерфейс, имеющий простую, стандартизированную и соответственно удобную для генерации структуру.

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

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

Интеграция с существующими инструментами

Многие производители сред разработки интенсивно используют генерацию кода пользовательского интерфейса. Эти среды разработки уже содержат инструменты для создания пользовательского интерфейса. Примерами являются Microsoft Visual Studio и Borland Delphi.

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

Как лучше генерировать интерфейс?

Рассмотрим, что нужно сделать для того, чтобы код интерфейса был не очень сложным и легким для генерации, а сам интерфейс был богатым и эффективным.

Улучшить модель работы пользовательского интерфейса. Пользовательский интерфейс имеет два главных параметра – визуальный и функциональный. Первый - это качество того, как он выглядит (цвета, отступы, расположение элементов и т.д.). Второй - это сам процесс взаимодействия пользователя с интерфейсом и насколько он соответствует предъявляемым требованиям. С первым параметром все понятно - стандарты пользовательского интерфейса (цвета, шрифты, стандартные элементы) должны разрабатываться заранее вручную. Рассмотрим второе.

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

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

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

Улучшение структуры кода. Код пользовательского интерфейса необходимо делать максимально структурированным и организованным в модули, блоки, компоненты и т.п. Это улучшит качество и единообразие пользовательского интерфейса.

Очищение содержимого кода пользовательского интерфейса. Желательно максимально уменьшить объем кода, не являющегося непосредственно интерфейсом. Это код безопасности, код бизнес-логики, код обращения к данным. Необходимо группировать такой код в процедуры и модули, чтобы присутствовали только обращения к ним. Где возможно стараться использовать декларативный код.

Совместная генерация с другими уровнями. Хотя первое, с чем сталкивается пользователь это пользовательский интерфейс, в процессе разработки внимание ему уделяется в последнюю очередь. Так происходит потому, что в первую очередь необходимо разработать программные модули, к которым будет обращаться пользовательский интерфейс. Генерация кода пользовательского интерфейса совместно с генерацией кода базы данных и промежуточным уровнем является эффективным решением, так как это сокращает время на разработку и ввод данных на нескольких уровнях приложения. Кроме того, обеспечивается хорошая согласованность между уровнями.

Выводы по генерации интерфейса

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

Генерация документации

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

Основной причиной этого является то, что разработка полной и актуальной документации является весьма трудоемким мероприятием и занимает сопоставимое (если не больше) время по сравнению с разработкой самого программного кода время.

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

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

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

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

Существующие генераторы документации обладают только основной функциональностью и далеко не всегда их возможности удовлетворяют всем потребностям. Например, они не предоставляют построчную документацию низкого уровня (для каждой строки программного кода). Также поддерживаются не все форматы вывода и не все шаблоны документации. Эти инструменты позволяют ознакомить с проектом программы на более высоком уровне (уровне модулей, классов, методов), хотя и близко к самому уровню программного кода, но не детально, не в любом виде и формате. Решением является создание собственного генератора документации, возможно на базе программного интерфейса существующего.

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

Генератор документации применяется двумя способами:

1. Генерируется документация одновременно с кодом, исходя из определений метаданных. Причем частью метаданных должны быть комментарии, которые будут включены как в сам код, так и в документацию.
2. Осуществляется разбор программного кода, оттуда выбираются важные блоки кода и комментарии, из этой информации составляется документация. Этот вариант очень удобен, так как документация находится там же, где и код. И вероятность того, что программист будет ее своевременно обновлять, гораздо выше. В этом случае также можно применять в качестве библиотек интерфейсы существующих генераторов документации.

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