В конце октября 2014 года в Москве прошла 10-я юбилейная конференция «Разработка ПО, CEE-SECR-2014», на которой был представлен наш доклад о создании кросс-САПР-платформенных приложений. Доклад состоял из исторического обзора, рассказа об опыте портирования САПР приложений на nanoCAD и анализа основных затруднений при портировании. В настоящей статье мы не будем останавливаться на первых двух частях доклада — запись опубликована в конце статьи, а более подробно рассмотрим третью часть, доработанную по результатам обсуждения доклада в кулуарах конференции.
Когда в 2008 году мы начали разрабатывать nanoCAD, у нас уже существовало более двух десятков приложений для AutoCAD. Работы по портированию приложений велись параллельно с разработкой новой САПР платформы, требования приложений в значительной степени определяли направление разработки. В результате портирования приложения стали кросс-САПР-платформенными, заработали в nanoCAD и не потеряли возможность работы в AutoCAD.
В процессе портирования собственных приложений, а также в процессе общения с разработчиками сторонних приложений в рамках Клуба разработчиков nanoCAD, мы обнаружили несколько повторяющихся шаблонов, мешающих эффективному портированию:
- Ожидание, пока API «дорастёт»
- Нежелание использовать обходное решение (workaround), работающее во всех системах
- Использование побочных эффектов
Шаблон 1. Ожидание, пока API «дорастёт»
Периодически мы сталкиваемся с тем, что после первой неудачной попытки портирования существующего приложения разработчик пропадает, в лучшем случае, написав: «Подожду, пока вы доработаете API», при этом не сообщая что именно не получилось. К счастью, так поступают не все, и с каждым релизом nanoCAD-а мы публикуем список доработок API, запрошенных членами Клуба разработчиков nanoCAD через багтрекер Клуба.
Наш опыт показывает, что все приложения в основном используют одни и те же функции API, но у каждого приложения есть свои специфичные потребности. Эта ситуация изображена схематически на рисунке, где центральная часть — это общеупотребительный API, а «тропинки» — это специфичные потребности. На схеме видно, что реализация в nanoCAD специфичных функций для одного приложения, как правило, не приводит к появлению специфичных функций, необходимых другому приложению.
Отсюда становится понятно, почему подход «Подождём, пока API дорастёт» не работает: если мы не знаем о существовании проблемы совместимости, она не будет исправлена.
Решение: Зарегистрироваться в Клубе разработчиков и создать задачи на доработку в багтрекере.
Шаблон 2. Нежелание использовать обходное решение (workaround), работающее во всех системах
Строго говоря, данный шаблон является частным случаем шаблона 1, но он настолько часто встречается, что имеет смысл рассмотреть его отдельно.
Часто существует обходное решение, которое работает во всех САПР платформах. В этом случае запрос на доработку, вероятно, будет отложен, поскольку очевидно, что другие проблемы, не имеющие обходных путей, имеют больший приоритет.
Решение: Есть workaround? Используй!
Шаблон 3. Использование побочных эффектов
Побочные эффекты в разных САПР платформах разные.
Абстрактный пример: Обнаружено, что функция печати умеет умножать числа. Не стоит использовать её для умножения, в другой платформе этого эффекта может не быть.
Пример из жизни: В ObjectARX после закрытия объекта методом pEntity->close(), можно вызвать некоторые методы уже закрытого объекта pEntity. Это противоречит документации ObjectARX, но работает. В nanoCAD после вызова pEntity()->close() объект разрушается и последующие вызовы приводят к падению. Если приложение привести в соответствие с документацией, оно начинает работать в обеих платформах.
Решение: Нет побочным эффектам! Используйте функционал по прямому назначению.
Выводы
Небольшие приложения, использующие общеупотребительную часть API, могут быть портированы на nanoCAD с минимальными изменениями или вообще без них.
Портирование сложного приложения часто требует как доработки недостающего функционала со стороны платформы, так и внесения изменений в приложение. Эти изменения, как правило, носят характер рефакторинга и не приводят к потере совместимости с AutoCAD. В результате полученное приложение строится из одного исходного кода и для nanoCAD и для AutoCAD.
Багтрекер Клуба разработчиков является способом влияния на разработку API nanoCAD-а. Чем больше разработчиков проголосует за ту или иную функцию API, тем раньше она будет реализована.
Запись доклада и презентация
Обсудить статью можно также и на нашем форуме.
P.S. В дополнение к последнему слайду, не можем не поделиться ссылкой на статью «САПР в СССР, или Киевнаучфильм представляет», которая обязательно попала бы в презентацию, если бы была опубликована раньше доклада.
Автор: ISL
