- PVSM.RU - https://www.pvsm.ru -

Как обойти основные затруднения при портировании САПР приложений на nanoCAD?

Как обойти основные затруднения при портировании САПР приложений на nanoCAD? - 1

В конце октября 2014 года в Москве прошла 10-я юбилейная конференция «Разработка ПО, CEE-SECR-2014», на которой был представлен наш доклад о создании кросс-САПР-платформенных приложений. Доклад состоял из исторического обзора, рассказа об опыте портирования САПР приложений на nanoCAD и анализа основных затруднений при портировании. В настоящей статье мы не будем останавливаться на первых двух частях доклада — запись опубликована в конце статьи, а более подробно рассмотрим третью часть, доработанную по результатам обсуждения доклада в кулуарах конференции.

Когда в 2008 году мы начали разрабатывать nanoCAD, у нас уже существовало более двух десятков приложений для AutoCAD. Работы по портированию приложений велись параллельно с разработкой новой САПР платформы, требования приложений в значительной степени определяли направление разработки. В результате портирования приложения стали кросс-САПР-платформенными, заработали в nanoCAD и не потеряли возможность работы в AutoCAD.

В процессе портирования собственных приложений, а также в процессе общения с разработчиками сторонних приложений в рамках Клуба разработчиков nanoCAD, мы обнаружили несколько повторяющихся шаблонов, мешающих эффективному портированию:

  1. Ожидание, пока API «дорастёт»
  2. Нежелание использовать обходное решение (workaround), работающее во всех системах
  3. Использование побочных эффектов

Шаблон 1. Ожидание, пока API «дорастёт»

Периодически мы сталкиваемся с тем, что после первой неудачной попытки портирования существующего приложения разработчик пропадает, в лучшем случае, написав: «Подожду, пока вы доработаете API», при этом не сообщая что именно не получилось. К счастью, так поступают не все, и с каждым релизом nanoCAD-а мы публикуем список доработок API [1], запрошенных членами Клуба разработчиков nanoCAD через багтрекер Клуба.

Наш опыт показывает, что все приложения в основном используют одни и те же функции API, но у каждого приложения есть свои специфичные потребности. Эта ситуация изображена схематически на рисунке, где центральная часть — это общеупотребительный API, а «тропинки» — это специфичные потребности. На схеме видно, что реализация в nanoCAD специфичных функций для одного приложения, как правило, не приводит к появлению специфичных функций, необходимых другому приложению.

Как обойти основные затруднения при портировании САПР приложений на nanoCAD? - 2

Отсюда становится понятно, почему подход «Подождём, пока API дорастёт» не работает: если мы не знаем о существовании проблемы совместимости, она не будет исправлена.

Как обойти основные затруднения при портировании САПР приложений на nanoCAD? - 3

Решение: Зарегистрироваться в Клубе разработчиков [2] и создать задачи на доработку в багтрекере.

Шаблон 2. Нежелание использовать обходное решение (workaround), работающее во всех системах

Как обойти основные затруднения при портировании САПР приложений на nanoCAD? - 4
Оригинал изображения [3]

Строго говоря, данный шаблон является частным случаем шаблона 1, но он настолько часто встречается, что имеет смысл рассмотреть его отдельно.

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

Решение: Есть workaround? Используй!

Шаблон 3. Использование побочных эффектов

Как обойти основные затруднения при портировании САПР приложений на nanoCAD? - 5
Оригинал изображения [4]

Побочные эффекты в разных САПР платформах разные.

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

Пример из жизни: В ObjectARX после закрытия объекта методом pEntity->close(), можно вызвать некоторые методы уже закрытого объекта pEntity. Это противоречит документации ObjectARX, но работает. В nanoCAD после вызова pEntity()->close() объект разрушается и последующие вызовы приводят к падению. Если приложение привести в соответствие с документацией, оно начинает работать в обеих платформах.

Решение: Нет побочным эффектам! Используйте функционал по прямому назначению.

Выводы

Небольшие приложения, использующие общеупотребительную часть API, могут быть портированы на nanoCAD с минимальными изменениями или вообще без них.

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

Багтрекер Клуба разработчиков является способом влияния на разработку API nanoCAD-а. Чем больше разработчиков проголосует за ту или иную функцию API, тем раньше она будет реализована.

Запись доклада и презентация

Обсудить статью можно также и на нашем форуме [5].

P.S. В дополнение к последнему слайду, не можем не поделиться ссылкой на статью «САПР в СССР, или Киевнаучфильм представляет» [6], которая обязательно попала бы в презентацию, если бы была опубликована раньше доклада.

Автор: ISL

Источник [7]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/api/82492

Ссылки в тексте:

[1] список доработок API: http://forum.nanocad.ru/index.php?showforum=114

[2] Клубе разработчиков: http://developer.nanocad.ru

[3] Оригинал изображения: http://magazinot.ru/files/picture/Sasa/StroyPloschadka/Scheet/T08.png

[4] Оригинал изображения: http://hiero.ru/2184958

[5] форуме: http://forum.nanocad.ru/index.php?showforum=146

[6] «САПР в СССР, или Киевнаучфильм представляет»: http://isicad.ru/ru/articles.php?article_num=17471

[7] Источник: http://habrahabr.ru/post/248753/