Блог Александра Божко
Архивы
Рубрики
Поделись с другими!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Проблема

Проблема перевода старых Delphi  проектов на unicode это то, что часто отталкивает разработчиков от использования новых (Delphi 2009 и старше) версий Delphi. С другой стороны, именно поддержка unicode, зачастую их больше всего и мотивирует. И хотя, казалось бы, проблема уже давно изучена, формализована и существует масса рекомендаций по ее решению, время от времени ее приходится решать.

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

Решение

В связи с вышесказанным у меня возникла идея создания некоего “анализатора проектов”. Суть его я вижу в следующем:

  • создание списка всех используемых в группе проектов модулей;
  • классификация модулей (модули проекта, сторонние компоненты, “родные” Delphi модули);
  • автоматическое создание списка сторонних компонентов, использованных в модуле и, соответственно, во всем проекте;
  • формирование списка проектов, использующих каждый из модулей;
  • формирование списка “критичных синтаксических конструкций” для каждого из модулей и проектов, соответственно;
  • создание обобщенного отчета по проектам.

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

Под “критичными синтаксическими конструкциями” я понимаю список возможных мест в коде, которые следует найти, чтобы проверить, готов ли код к правильному использованию Юникод.

Как это работает?

Очевидно, что самый простой способ создать подобные  отчеты – получить список директорий, используемых в IDE (Library Path), список модулей из файла проекта, и списки используемых модулей (uses). Технически это не сложно.  Полученные результаты – сложить в таблицы. Разобраться в том, к какому из наборов компонентов относится каждая из директорий не сложно. Таким образом, мы сможем понять и принадлежность модулей. Т. е. либо это “авторский” модуль проекта, либо это модуль стороннего производителя, либо стандартный модуль VCL. Естественно, что анализировать синтаксис кода следует только для “авторских” модулей. Что касается, сторонних компонентов, то в принципе мы сможем оценить сколько же модулей нам придется изменить, отказавшись от какой-либо из библиотек.

Создать сводный отчет, как вы понимаете, дело техники. Несколько SQL запросов.

Интуитивно, я понимаю, что каким-то образом здесь можно использовать приложение Lazy Delphi Builder Алексея Тимохина. Кроме этого, возможно стоит каким-то образом использовать инструмент QA Audits (правда пока не совсем представляю как).

В связи со всем вышесказанным у меня возникает несколько вопросов к читателям блога. Прежде всего, может быть существуют какие-то стандартные средства анализа проектов и (что наиболее важно, групп проектов). Возможно, кто-то занимался чем-то подобным и есть какие-то наработки. Ну, и, как обычно, приветствуются любые идеи.

 


Поделись с другими!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

13 комментариев: Анализатор проекта

  • Есть такая штука – Pascal Analizer

    • Посмотрел я анализатор. Штука, конечно, интересная. Но это не совсем то, что надо. Да, и денег она стоит. Во многом его функционал перекрывают стандартные QA Audit и QA Metric. На досуге надо будет поковырять внимательнее…

  • Синтаксические анализаторы существуют, одна из ссылок выше. Но если взять одну тему (миграция на юникод) и тщательно именно ее проработать, то может получиться интересно. Я думаю, здесь есть ниша и есть спрос на какие-то решения.

  • И если я не ошибаюсь, то в Apple xCode статический анализатор построен на дереве разбора от LLVM

  • Вообще говоря в IDE есть же “дерево проекта”. Если получить его исходники, то “дело в шляпе”.

    А можно взять компилятор от Free-Pascal. Благо – он в исходниках.

    Ну чтобы уж совсем “велосипед” не изобретать.

  • Alex W. Lulin, ну ты обижаешь. Значит ANTLR для всяких руби ты рекомендуешь, а родной дельфовый ndyacclex забыл :)

    Но вообще сам парсер не проблема, как мне кажется. Есть даже вот такая штука – https://github.com/jacobthurman/Castalia-Delphi-Parser

    Но парсер тут это даже не половина работы.

  • Ну yacc/Lexx я “подразумеваю”, что “все знают”

  • Поскольку комменты в Caps-стиле раздражают – позволю привести себе ссылку на свои мысли по этому поводу у меня в блоге – http://programmingmindstream.blogspot.ru/2013/12/blog-post_3748.html

  • Переход на Юникод – это разовое действие. Перевёл проект и – порядок. Если бы такой анализатор был платным, то сомневаюсь, что пользовался бы спросом. Имхо.

    Теперь по делу:
    Инструмента полностью решающего такую проблему я не знаю.

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

    В CnWizards входит одна утилитка CnPack Relation Analyzer (я его когда-то описывал в блоге), который умеет анализировать зависимости проектов от юнитов. Не совсем так как описано в статье, но с поиском общих модулей может помочь.

    Теперь что касается анализаторов кода:
    помимо QA Audits/Reports, есть еще пара хороших сторонних статических анализаторов (платных): Peganza pascal Analyzer (вышеупомянутый), и CodeHealer.

    • Ну, кому разовое, а кому – нет. У меня, в силу ряда обстоятельств, не менее десятка раз, только в этом году спросили, а сложно-ли перевести мой проект на юникод.
      А анализатор зависимостей – классно, спасибо.

  • “Переход на Юникод – это разовое действие. Перевёл проект и – порядок. Если бы такой анализатор был платным, то сомневаюсь, что пользовался бы спросом. Имхо.”

    Мне тоже так кажется. Если не планировать его “с прицелом” на “нормальный статический анализатор”. С возможностью задания пользовательских паттернов для проверки и валидации.

  • Хоть и не для перехода на Юникод, но мне CodeVerifier из этой темы пригодился http://www.sql.ru/forum/297266/peganza-pascal-analyzer-socksoftware-codehealer-ishhu-analogi-i-prodavcov-v-rossii?hl=codeverifier
    Похоже, что у автора приличный задел по теме.

Оставить комментарий

Ваш email не будет опубликован. Обязательные поля отмечены *

Вы можете использовать это HTMLтеги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Продукты DevArt
Купить онлайн:



Читай русскоязычные Delphi блоги
Каталог блогов Blogdir.ru
Яндекс.Метрика