Як обійти основні труднощі при портуванні САПР додатків на nanoCAD?



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

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

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

  1. Очікування, поки API «доросте»
  2. Небажання використовувати обхідні рішення (обхідний шлях), що працює у всіх системах
  3. Використання побічних ефектів
Шаблон 1. Очікування, поки API «доросте»
Періодично ми стикаємося з тим, що після першої невдалої спроби портування існуючого програми розробник пропадає, в кращому випадку, написавши: «Почекаю, поки ви доработаете API», при цьому не повідомляючи що саме не вийшло. На щастя, так чинять не всі, і з кожним релізом nanoCAD-а ми публікуємо список доробок API, запитаних членами Клубу розробників nanoCAD через багтрекер Клубу.

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



Звідси стає зрозуміло, чому підхід «Почекаємо, поки API доросте» не працює: якщо ми не знаємо про існування проблеми сумісності, вона не буде виправлена.



Рішення: Зареєструватися Клубі розробників і створити завдання на доопрацювання в багтрекері.

Шаблон 2. Небажання використовувати обхідні рішення (обхідний шлях), що працює у всіх системах

Оригінал зображення

Строго кажучи, даний шаблон є приватним випадком шаблону 1, але він настільки часто зустрічається, що має сенс розглянути його окремо.

Часто існує обхідний рішення, яке працює у всіх САПР платформах. У цьому випадку запит на доопрацювання, ймовірно, буде відкладено, оскільки очевидно, що інші проблеми, що не мають обхідних шляхів, мають більший пріоритет.

Рішення: Є обхідний шлях? Використовуй!

Шаблон 3. Використання побічних ефектів

Оригінал зображення

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

Абстрактний приклад: Виявлено, що функція друку вміє множити числа. Не варто використовувати її для множення, в іншій платформі цього ефекту може не бути.

Приклад з життя: В ObjectARX після закриття об'єкта методом pEntity->close(), можна викликати деякі методи вже закритого об'єкта pEntity. Це суперечить документації ObjectARX, але працює. В nanoCAD після виклику pEntity()->close() об'єкт руйнується і наступні виклики приводять до падіння. Якщо додаток привести у відповідність з документацією, воно починає працювати в обох платформах.

Рішення: Немає побічних ефектів! Використовуйте функціонал за прямим призначенням.

Висновки
Невеликі додатки, що використовують общеупотребительную частину API, можуть бути портіровани на nanoCAD з мінімальними змінами чи взагалі без них.

Портування складного додатка часто потребує доопрацювання відсутнього функціоналу з боку платформи, так і внесення змін в додаток. Ці зміни, як правило, носять характер рефакторінгу і не призводять до втрати сумісності з AutoCAD. У результаті отримане додаток будується з одного вихідного коду і для nanoCAD і для AutoCAD.

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

Запис доповіді та презентація




Обговорити статтю можна також і на нашому форум.

P. S. На додаток до останнього слайда, не можемо не поділитися посиланням на статтю «САПР в СРСР, або Київнаукфільм презентує», яка обов'язково потрапила б в презентацію, якби була опублікована раніше доповіді.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.