Проблемы с архитектурой веб-приложения

[staircaseMaker]

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

[j0hnik]

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

[j0hnik]

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

[staircaseMaker]

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

[j0hnik]

тут есть соображающие люди, зайдите в раздел работа, постарайтесь четко и понятно поставить задачу, укажите стоимость заказа и сроки. Если игра стоит свеч вам скорее всего помогут.

[staircaseMaker]

тут есть соображающие люди, зайдите в раздел работа, постарайтесь четко и понятно поставить задачу, укажите стоимость заказа и сроки. Если игра стоит свеч вам скорее всего помогут.

А с чего посоветуете начать: с аудита, проектирования архитектуры, документации, непосредственного переписывания кода?

[MallSerg]

Не этот проект случаем ? https://www.pearstairs.co.uk/staircreator/

чтобы система наконец заработала нормально.

Это из области мечтаний или фантастики закон Мерфи непреодолим.



Если это тот конструктор то код переписывать рано там код написан не совсем ужасно. Формы UI отдельно шаги для построения геометрии тоже отдельно и рендер отдельно. Там больше вопросов к задачам которые должен решать этот конструктор и как он с этим справляется. В такой постановке вопроса все не очень гладко.

Этот тот случай когда лучше сначала подумать а потом сделать.

[staircaseMaker]

Не этот проект случаем ? https://www.pearstairs.co.uk/staircreator/

Если это тот конструктор то код переписывать рано там код написан не совсем ужасно. Формы UI отдельно шаги для построения геометрии тоже отдельно и рендер отдельно. Там больше вопросов к задачам которые должен решать этот конструктор и как он с этим справляется. В такой постановке вопроса все не очень гладко.

Этот тот случай когда лучше сначала подумать а потом сделать.

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

[nerv_]

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

это называется регрессия

могу дать простой и бесплатный совет -- покройте тестами (assert), те юзкейсы, которые вас интересуют. Это позволит с одной стороны избежать регрессий, с другой утвердить (assert) уже имеющийся функционал и нащупать точку опоры, которой у вас сейчас нет.
Например, при входных_данных_№1, должен быть выход_№1. Это позволит произвести рефакторинг системы (то, что вам нужно), не убив ее при этом напрочь. Причем рефакторинг итеративный -- переделали кусок, система работает, и вы по прежнему можете ее использовать.

[staircaseMaker]

покройте тестами (assert), те юзкейсы, которые вас интересуют.

Тесты это очень хорошо, но я не смог придумать, как проверять корректность модели. Большинство ошибок выглядят вот так:
http://joxi.ru/v294NPGu35y4Nm
а должно быть вот так http://joxi.ru/zANya0zTBRwEG2
или так http://joxi.ru/vAW4yKOu1dOb6r а должно быть так http://joxi.ru/DrlNbaghvNnEa2
Код построен по принципу множества условий, в зависимости от которых детали лестницы строятся определенным образом. Проблемы возникают от того, что либо нужное условие не срабатывает, либо нужного условия вообще нет.
Как бы Вы посоветовали организовать тесты?
Исходные данные следующие: лестница строится на основе параметров и не меняется от действий пользователя (у модели нет никакого поведения, она статична). В среднем, в зависимости от модели, лестница определяется 350-400 параметрами. Часть параметров непрерывные (ширина ступени может быть любой в диапазоне от 100 до 400), часть дискретные (выбор направления поворота, типа ограждения и т.п.) Проверять надо модель, которая строится браузером через three.js. В зависимости от сложности, модель строится до 5 секунд на компьютере средней производительности. Проблемная часть полностью клиентская, на сервере нет технической логики.