Как обойти основные затруднения при портировании САПР-приложений на nanoCAD
В конце октября 2014 года в Москве прошла 10я, юбилейная конференция «Разработка ПО, CEESECR2014», на которой был представлен наш доклад о создании кроссСАПРплатформенных приложений. Доклад состоял из ретроспективного обзора, рассказа об опыте портирования САПРприложений на 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, тем быстрее она будет реализована.
