Архитектурой инженерной программы

Здравствуйте, уважаемые коллеги!
Помогите, пожалуйста, советом, как решить проблему с архитектурой приложения.
Краткая предыстория проекта: мы производственная компания, занимаемся производством лестниц для частных домов по индивидуальному проекту. У нас есть система автоматизированного проектирования (сапр). Система сделанная в виде веб-приложения, 3D модель лестницы строится с использованием библиотеки three.js. Система хаотично росла из простенького онлайн калькулятора в течение нескольких лет. Разработка велась командой из 5 удаленных программистов, каждый прорабатывал свою модель лестницы. Их работу на уровне кода никто не проверял, проверялась только итоговая работа системы. В итоге сейчас система полностью написана, но на выходе каждая вторая спроектированная лестница ошибки: где-то отверстия не совпадают, где-то детали пересекаются между собой, где-то часть деталей на модели есть, а в спецификацию не попали и т.п.
На уровне кода система разделена на ядро, содержащее модули визуализации, взаимодействия с пользователем, работы с базой и т.п. и конструкторские модули, которые непосредственно создают модель лестницы (отдельный модуль для каждой серии лестниц, всего 8 серий). Проблема, которую надо решить, именно в конструкторских модулях. По-хорошему, чтобы устранить технические ошибки, надо проверить алгоритм построения модели на уровне кода. Но совокупный объем конструкторских модулей больше 300 тысяч строк, комментариев в коде нет, документации нет, везде встречаются “магические цифры”, которые непонятно откуда взяты. Кроме того, так как разные модули писались разными программистами, одна и та же задача везде решается по-разному и дублирование кода просто катастрофическое.
Система уже год эксплуатируется, но все результаты работы системы перед запуском в производство вручную проверяются и дорабатываются инженерами на производстве. Обнаруживаемые ошибки исправляются в коде, но, такое ощущение, что исправление ошибок часто порождает новые ошибки в других местах.
Мне бы хотелось получить от опытных разработчиков какие-то советы, что теперь со всем этим можно сделать, чтобы система наконец заработала нормально. Толковые детальные консультации мы готовы оплатить.

0

В посте обозначено две задачи/проблемы:

Сообщение от staircaseMaker надо проверить алгоритм построения модели на уровне кода.

Сообщение от staircaseMaker Обнаруживаемые ошибки исправляются в коде, но, такое ощущение, что исправление ошибок часто порождает новые ошибки в других местах.

Прежде, чем приступать к активному рефакторингу, неплохо бы покрыть существующую функциональность тестами. Это позволит как проверить корректность результатов работы, так и предотвратить ситуации вида «в одном месте починили, в 10 сломали». Причем на этом этапе не нужно исправлять ошибки: достаточно зафиксировать фактическое поведение системы, чтобы изменения в ней не оставались незамеченными. Может оказаться, что часть модулей (или все) непригодны для покрытия тестами из-за архитектурных дефектов. В этом случае — сначала аккуратно рефакторить без изменения функциональности, а затем покрывать тестами. Внедрение зависимостей в помощь.

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

Серебряной пули нет. Нужно набраться терпения и методично разгребать эти авгиевы конюшни.

0

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

0

Сообщение от staircaseMaker Суть ошибок, как правило, заключается в неправильном (с производственной точки зрения) построении модели

Неужели совсем никак нельзя определить, какие входные данные привели к такому результату и сформулировать хотя бы часть предикатов, которыми можно верифицировать результат? В данном случае: определить, на каких прямых расположены решетки, найти точку пересечения и понять, что она не там? Да хоть бы и жестко зашить координаты ограждений на конкретных входных данных.

Сообщение от staircaseMaker Вопрос в том, как правильно организовать рефакторинг, чтобы после рефакторинга не получить те же самые проблемы.

Сложно дать какие-то конкретные рекомендации. Менять только одну вещь за раз. Не закапываться в реализацию раньше времени, начать с модулей и их интерфейсов, и потоков данных. Если модули разношерстные, возможно временно ввести уровень абстракции — прокси между ними и клиентом. Если интерфейс уже обобщен, но в реализации лапша — реверсить, декомпозировать, выносить зависимости.

Пока что проблема сформулирована как «код неподдерживаемый и содержит ошибки». Это слишком общая постановка, чтобы были конкретные рекомендации. Желательно, чтобы с кодом работал человек не со стороны — хоть какая-то надежность.

И гарантий никто не даст. Отсутствие проблем после рефакторинга зависит от запущенности проекта, квалификации специалиста, внешних факторов (в сжатые сроки из-под палки результат редко получается качественным) и еще каких-нибудь факторов, которые я не учел.

0

Сообщение от 0x10 Пока что проблема сформулирована как «код неподдерживаемый и содержит ошибки». Это слишком общая постановка, чтобы были конкретные рекомендации. Желательно, чтобы с кодом работал человек не со стороны — хоть какая-то надежность.

Мне бы хотелось получить советы скорее по организации процесса. То есть с чего обычно начинается работа в такой ситуации: с прописывания архитектуры, написания тестов, аудита, поиска программистов или еще чего...
Попытки переписать код силами тех же программистов, кто его писал (за деньги) ничем хорошим не увенчались. Как оказалось, из 5 человек только один вообще в состоянии писать нормальный код, а остальные скорее инженеры чем программисты.

0

Сообщение от staircaseMaker конструкторские модули, которые непосредственно создают модель лестницы

На каком языке написаны модули?
Что из себя представляет интерфейс модулей?

Сообщение от staircaseMaker где-то отверстия не совпадают, где-то детали пересекаются между собой, где-то часть деталей на модели есть, а в спецификацию не попали и т.п.

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

0

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

Исходные данные такие:
Модули написаны на javascript в функциональном стиле. Код построен по принципу множества условий, в зависимости от которых детали лестницы строятся определенным образом. Проблемы возникают от того, что либо нужное условие не срабатывает, либо нужного условия вообще нет.
Лестница строится на основе параметров и не меняется от действий пользователя (у модели нет никакого поведения, она статична). В среднем, в зависимости от модели, лестница определяется 350-400 параметрами. Часть параметров непрерывные (например, ширина ступени может быть любой в диапазоне от 100 до 400), часть дискретные (выбор направления поворота (2 варианта), типа ограждения (8 вариантов) и т.п.) Проверять надо модель, которая строится браузером через three.js. В зависимости от сложности, модель строится до 5 секунд на компьютере средней производительности. Проблемная часть полностью клиентская, на сервере нет технической логики. Сейчас тестирование происходит так: в базу сохранены несколько сотен конфигураций. Инженер их последовательно открывает и визуально проверяет модель.
Как бы Вы посоветовали организовать автоматические тесты?

0

Сообщение от staircaseMaker Код построен по принципу множества условий, в зависимости от которых детали лестницы строятся определенным образом.

Не понятно. Код генерит json объект на основе данных из БД? Или?

Сообщение от staircaseMaker Проблемы возникают от того, что либо нужное условие не срабатывает, либо нужного условия вообще нет.

Я бы использовал декларативный стиль.

Сообщение от staircaseMaker в базу сохранены несколько сотен конфигураций

Правильно я понимаю, что проблема в том, что конфигурации некорректные?

Сообщение от staircaseMaker Как бы Вы посоветовали организовать автоматические тесты?

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

0

Сообщение от staircaseMaker Сейчас тестирование происходит так: в базу сохранены несколько сотен конфигураций. Инженер их последовательно открывает и визуально проверяет модель.

Все, что проверяется визуально, формализовать и автоматизировать, насколько это возможно. На первой итерации может подойти даже сохранение результата как эталонного и последующее точное сравнение с ним.

Сообщение от staircaseMaker То есть с чего обычно начинается работа в такой ситуации: с прописывания архитектуры, написания тестов, аудита, поиска программистов или еще чего...

Мне кажется очевидным, что прежде чем делать какую-либо работу, нужно найти человека, который за нее возьмется. Нужен один разработчик, способный писать качественный код, и готовый заниматься реверс-инженерингом и рефакторингом на полный день. Возможно, понадобится консультант, разбирающийся в предметной области. Не на полный день, а эпизодически — если разработчик не может узнать в спагетти-коде стандартный для домена алгоритм.

Архитектура уже есть, поскольку есть разбиение на модули. Качество же интерфейсов вскроется при покрытии тестами — неудачные интерфейсы покрывать тестами будет совсем сложно или невозможно. Например, если функция модуля вызывается только ради вычислений и побочного эффекта (отображения результата), то можно не тратить время на покрытие тестами, а рефакторить, разделяя данные и представление. Повторюсь: чтобы это обнаружить, нужно начать делать. Или хотя бы вдумчиво прочитать интерфейсы.

Еще процессный момент: у вас есть багтрекер? Если нет, то нужно завести. И пусть все, кто обнаруживает баги, репортит их в формате «Шаги для воспроизведения, ожидаемое поведение, фактическое». Когда наберется список багов, их можно будет приоритезировать, определить самые критичные — с них и начать исправления. К этому моменту тесты уже должны быть. Или же исправление каждого бага должно сопровождаться написанием теста, покрывающего случай.

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

0

Сообщение от 0x10 Неужели совсем никак нельзя определить, какие входные данные привели к такому результату и сформулировать хотя бы часть предикатов, которыми можно верифицировать результат? В данном случае: определить, на каких прямых расположены решетки, найти точку пересечения и понять, что она не там? Да хоть бы и жестко зашить координаты ограждений на конкретных входных данных.

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

Сообщение от Shamil1 Не понятно. Код генерит json объект на основе данных из БД? Или?

на входе конструкторских модулей массив параметров лестницы, на выходе массивы javascript объектов, созданных конструкторами из библиотеки THREE.js. Я бы это назвал скорее многомерными ассоциативными массивами с большой вложенностью.

Сообщение от Shamil1 Правильно я понимаю, что проблема в том, что конфигурации некорректные?

В базу сохраняются только исходные параметры лестницы, модель строится на клиенте каждый раз заново и на сервер не отправляется. Корректность исходных данных проверяется при вводе и они корректные. А вот модель, которая по ним строится, может быть кривой.

Сообщение от Shamil1 Попробовать придумать правила, которые должны выполняться

Такие правила есть и модель строится как раз на основе этих правил. То есть, например, при отрисовке каркаса координаты отверстий для крепления ступеней передаются в функцию построения ступеней и ступени строятся по этим координатам. Ошибки как раз и возникают из-за ошибок в этих правилах. А написать альтернативные правила и потом сравнивать результат это по-сути написать вторую систему, только другую.

Сообщение от 0x10 На первой итерации может подойти даже сохранение результата как эталонного и последующее точное сравнение с ним.

Вот этот вариант вполне реализуем, можно сохранять в базу проверенные инженером результаты работы конструкторского модуля и сравнивать их с вновь рассчитанными. Но меня терзают сомнения относительно целесообразности таких тестов: они ведь не помогут выловить те ошибки которые есть, а помогут выловить только вновь возникшие. К тому же после каждого исправления надо будет пересохранять все эталонные модели. И получается что надо будет не только править саму систему, но и постоянно переписывать тесты. Вы считаете, в этом есть смысл?

0

Сообщение от staircaseMaker на входе конструкторских модулей массив параметров лестницы, на выходе массивы javascript объектов, созданных конструкторами из библиотеки THREE.js. Я бы это назвал скорее многомерными ассоциативными массивами с большой вложенностью.

Т.е. на входе параметры, на выходе — графический объект? Хочется здесь разнести, чтобы модули не зависели от графической библиотеки и возвращали не модели, а данные для их построения.

Сообщение от staircaseMaker они ведь не помогут выловить те ошибки которые есть, а помогут выловить только вновь возникшие. К тому же после каждого исправления надо будет пересохранять все эталонные модели. И получается что надо будет не только править саму систему, но и постоянно переписывать тесты. Вы считаете, в этом есть смысл?

Да, такие тесты сложны в поддержке. Но они и не должны ловить вновь возникшие ошибки. Цель таких тестов — зафиксировать поведение системы. Если планируется выполнить рефакторинг без изменения функциональности, то нужно защититься от непредвиденного изменения поведения. Плюс, кажется, что подготовка стартового набора таких тестов обойдется дешевле, чем формулировка условий для валидации моделей.

Подсказать относительно того, какие проверки реализовать в тестах, сейчас не смогу. Сам разрабатывал систему, в которой для точной проверки результата фактически нужно было реализовать алгоритм получения этого результата. На первой итерации работали с набором эталонных результатов. Все, как и сказал выше — подготовка стартового набора тестов заняла относительно немного времени, но поддержка была сложной. Тем не менее, тесты оказались полезны и спасали некоторое время. Потом написали более честные проверки.

0

Сообщение от staircaseMaker на входе конструкторских модулей массив параметров лестницы, на выходе массивы javascript объектов, созданных конструкторами из библиотеки THREE.js. Я бы это назвал скорее многомерными ассоциативными массивами с большой вложенностью.

Можно разбить модель на крупные детали, затем эти детали на более мелкие и так далее?
Затем для каждой детали, начиная с самых мелких, написать отдельную функцию. И для этой функции хотя бы несколько тестов, которые проверяют, что при неких фиксированных параметрах получаются правильные объекты.

У меня сложилось впечатление (хотя информации недостаточно), что написать эту подсистему (конструкторские модули) с нуля будет дешевле, чем исправлять уже существующую. Плюс в том, что можно это начать делать, не затрагивая работоспособность системы в целом (добавить ещё один конструкторский модуль).
Сначала написать сверху-вниз вызовы функций заглушек (опираясь на знания предметной области и структуру модели на выходе). Затем идти снизу-вверх, реализуя функции и сразу покрывая их модульными тестами (предположительно что-нибудь типа QUnit).
В процессе, возможно, будут копироваться некоторые куски существующего кода. Главное избегать в дублирования кода в пределах нового модуля. По возможности избегать вложенных if. Стараться, чтобы любая функция отвечала за что-нибудь одно и умещалась на 1-2 экрана.

Добавлено через 4 минуты

Сообщение от 0x10 Т.е. на входе параметры, на выходе — графический объект? Хочется здесь разнести, чтобы модули не зависели от графической библиотеки и возвращали не модели, а данные для их построения.

Полезное замечание.

0

Сообщение от Shamil1 Т.е. на входе параметры, на выходе — графический объект? Хочется здесь разнести, чтобы модули не зависели от графической библиотеки и возвращали не модели, а данные для их построения. Полезное замечание.

Модель собирается из деталей, каждая из которых строится отдельной функцией. Само построение большинства деталей многоэтапное и глубоко завязано на методах three.js. Например, вот такой объект строится следующим образом: строится проекция одной грани из линий и дуг (path), объединяется в область (shape), потом в нем делаются отверстия при помощи специального метода (addHole), методом экструзии делается тело (mesh), потом аналогично строится вторая грань и угол, потом все эти три объекта позиционируются и добавляются в составной объект (complexObject), затем весь этот уголок добавляется в составной объект нижнего марша, затем в лестницу, затем в сцену. На каждом этапе используются практически исключительно библиотечные методы. Я не представляю, как и зачем надо это разделять.

По поводу моего основного вопроса: я пока склоняюсь к тому, чтобы начать с аудита самого лучшего (с моей точки зрения) модуля, чтобы получить образец, к которому надо привести остальные. Как Вы думаете, как лучше всего это организовать, чтобы польза от этого аудита была максимальной? Код написан на javascript с использованием библиотеки THREE.js, объем того модуля, который я считаю наилучшим в районе 12 тыс строк.

Добавлено через 14 минут
И сколько может стоить такой аудит?

0

Сообщение от staircaseMaker Например, вот такой объект строится следующим образом: строится проекция одной грани из линий и дуг (path), объединяется в область (shape), потом в нем делаются отверстия при помощи специального метода (addHole), методом экструзии делается тело (mesh), потом аналогично строится вторая грань и угол, потом все эти три объекта позиционируются и добавляются в составной объект (complexObject), затем весь этот уголок добавляется в составной объект нижнего марша, затем в лестницу, затем в сцену.

Если всё так просто, то откуда ошибки?
Видимо, существует какая-то информация, которая является для Вас привычной и поэтому кажется Вам очевидной. А мне не хватает этой информации, чтобы понять причину проблемы.

Сообщение от staircaseMaker Как Вы думаете, как лучше всего это организовать, чтобы польза от этого аудита была максимальной?

В конечном итоге всё будет зависеть от специалиста, который будет проводить аудит.

0

Сообщение от Shamil1 Если всё так просто, то откуда ошибки? Видимо, существует какая-то информация, которая является для Вас привычной и поэтому кажется Вам очевидной. А мне не хватает этой информации, чтобы понять причину проблемы.

Изначально все и было достаточно просто, упрощенная визуализация для коммерческого модуля (где не важна техническая точность) была написана с нуля за 1,5 месяца. Проблема заключается в большой вариативности модели из зависимости конструкции узлов лестницы от параметров. Вот пример с уголком крепления ступени Например, при ширине ступени больше 300мм ставится уголок 230мм, для ступени 230-300мм ставится уголок 200мм, для ступени меньше ставится уголок 160мм, потом 90мм. На той ступени, где есть перемычка, уголки другие чем на осльаных. На поворотных ступенях они тоже другие и зависят от конфигурации поворота. Плюс отверстия в уголке должны совпадать с отверстиями в каркасе и в ступенях. Сдвиг хотя бы одного отверстия это провал - лестница не соберется. А в коммерческом модуле это не важно - там и отверстий-то нет.
И таких условий огромное количество и не все они заранее известны. То есть надо сначала написать модуль, поиграться с ним при разных параметрах, выцепить сочетания параметров, при которых появляются косяки (в примере со ступенями это вылезание уголка из под ступени) и добавить в код условия, не допускающие возникновения этих косяков. Проще говоря, сложная и заранее не формализованная бизнес-логика. А если учесть еще и то, что все эти модели лестниц мы разрабатываем сами и идет постоянный процесс улучшения конструкции, поддерживаемость кода становится очень важной

Сообщение от Shamil1 В конечном итоге всё будет зависеть от специалиста, который будет проводить аудит.

А на что бы Вы посоветовали обратить внимание при выборе этого человека и какие подготовительные мероприятия с нашей стороны можно произвести для достижения максимального результата?

0

Сообщение от staircaseMaker Вот пример с уголком крепления ступени Например, при ширине ступени больше 300мм ставится уголок 230мм, для ступени 230-300мм ставится уголок 200мм, для ступени меньше ставится уголок 160мм, потом 90мм. На той ступени, где есть перемычка, уголки другие чем на осльаных. На поворотных ступенях они тоже другие и зависят от конфигурации поворота.

Выбор уголка нужно вынести в отдельную функцию. В идеале для каждой функции должна существовать лишь одна причина для изменений её кода и для каждого изменения в логике должна существовать лишь одна функция, в которую придётся внести изменения.
Функцию желательно написать без вложенных if (часто вложенность можно уменьшить за счёт инвертирования условия и/или изменения порядка проверки условий). Размер уголка выбирается без if - поиском по массиву пар. Возможно, потребуются различные функции для создания уголков различных типов. Возможно, специальная функция для отображения типов ступеней на типы уголков. И так далее.

Сообщение от staircaseMaker И таких условий огромное количество и не все они заранее известны.

Теоретически, можно придумать "язык условий" и задавать их декларативно, без изменения кода программы. Зависит от предметной области.

Сообщение от staircaseMaker А на что бы Вы посоветовали обратить внимание при выборе этого человека

Сложно советовать.

0

staircaseMaker, Вариант решения задачи средствами промышленных САПР - т.е. параметризируемых типовых элементов/сборок c заданием исходных данных и выводом результатов через API не рассматривали? Если рассматривали то почему не подошел?

0

Сообщение от Fulcrum_013 staircaseMaker, Вариант решения задачи средствами промышленных САПР - т.е. параметризируемых типовых элементов/сборок c заданием исходных данных и выводом результатов через API не рассматривали? Если рассматривали то почему не подошел?

Все-таки cad это больше облегчение работы инженера-конструктора, а не замена человека машиной. А у нас стояла задача полностью уйти от проектирования, то есть на основе введенных пользователем данных автоматически сгенерировать всю необходимую для производства техническую документацию, включая управляющие программы для станков с чпу. Стандартными средствами cad систем нашу задачу решить не получается, т.к. модель очень сильно меняется в зависимости от сочетания параметров. Код построения модели, по-сути, почти полностью состоит из вложенных if и case. Более того, в зависимости от сочетания условий не просто меняются параметры блоков, а используются совершенно разные блоки. А стандартные параметрические модели, например, в Solidworks, можно сделать если внешний вид не меняется принципиально. А у нас при изменении всего одного параметра модель меняется от такой до вот такой И при для этого пользователь меняет всего один (!) параметр - геометрию лестницы.
Мы сначала пытались реализовать нашу задачу на платформе автокада, писали библиотеки и макросы для построения моделей из деталей этих библиотек (lisp). Но, во-первых, сам автоад стоит 1000$ на каждую машину (а нам надо 20 пользователей), очень геморная работа с базой данных на сервере, колоссальные проблемы с пользовательским интерфейсом (убогие dcl окна несравнимы с возможностями html+css), да и сам ископаемый autoLisp несравнимо более убогий чем javascript
И, что самое главное, использование автокадовской оболочки не дает в нашем случае вообще никаких преимуществ перед нашей собственной оболочкой написанной на three.js, т.к. все проектирование выполняется полностью автоматически и пользователю не надо что-либо чертить. Зато веб-приложение обладает целой массой преимуществ при развертывании и поддержке перед десктопным

0

Сообщение от staircaseMaker Все-таки cad это больше облегчение работы инженера-конструктора, а не замена человека машиной.

Ну вообще вопрос был о варианте использования API SolidWorks для прикручивания к ней вашего интерфейса и конструкторской части. Т.е. то что средствами параметризации сделать нереально делается VB-скриптом/плагином/внешней программой - все команды которые солид умеет мышью можно делать и через API из вашего приложения на любом языке. В т.ч. сверление отверстий в уже спозиционированных элементах. Т.е. совпадение отверстий и соблюдение остальных привязок - это вопрос решаемый движком солида.

Сообщение от staircaseMaker Зато веб-приложение обладает целой массой преимуществ при развертывании и поддержке перед десктопным

При этом сам js обладает кучей недостатков в плане реализации конструкторской части, особенно движка геометрического моделирования. Для сравнения видел движки твердотельного моделирования с функционалом подобным солиду,
которые помещаются в объем кода порядка 10 тыс строк.
Т.е. насколько вижу наиболее логичный вариант - солид или его аналог на сервере, конструкторская часть и мост с WEB посредством API и WEB интерфейс у пользователей. При этом проблем с 5-ю сырыми геометрическими движками, делающими одно и то же, точно не будет, а соответственно упростится и реализация каждого типа лестницы.

0

Сообщение от Fulcrum_013 Ну вообще вопрос был о варианте использования API SolidWorks

На мой взгляд, с экономической точки зрения не очень рационально вместо бесплатной, простой и удобной оболочки на three.js (написанной, кстати, всего за неделю одним человеком) использовать SolidWorks за 11к$ на каждую машину (20 машин), и искать специалистов, разбирающегося в их API (даже не представляю, сколько такой специалист может стоить). А проблема у нас вовсе не в оболочке, а как раз в бизнес-логике, а именно в алгоритме создания моделей лестниц, который, по-большому счету, вообще не зависит от оболочки. А отверстия гораздо проще по координатам привязывать, просто это надо было с самого начала нормально делать.
Да и зачем вообще может быть нужна для подобной задачи cad система (ну, конечно, если нет задачи освоить как можно больший бюджет)?

Сообщение от Fulcrum_013 При этом сам js обладает кучей недостатков в плане реализации конструкторской части, особенно движка геометрического моделирования.

Что Вы имеете в виду? Если Вы про качество рендеринга, то тут сравнение однозначно не в пользу солида.

0