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

[staircaseMaker]

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

[Black Fregat]

Такие вещи всегда должен интегрировать кто-то знающий.. И обязательно нужен этап сопровождения - как раз чтобы отлавливать всплывающие ошибки

Я думаю, вам не обойтись без привлечения специалиста, который для начала подтвердит вашу догадку. Ведь проблема может быть и в ядре и даже в протоколе взаимодействия. За время ковыряния он должен получить представление о вашей системе и выдать дальнейшие рекомендации

[staircaseMaker]

Сообщение от Black Fregat

Такие вещи всегда должен интегрировать кто-то знающий..

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

[Black Fregat]

Сообщение от staircaseMaker

Вообщем-то, первую версию системы писал я сам,

Это уже легче.
Тогда, вероятно, нужно начинать с хорошего багтрекинга - все ошибки фиксировать, сортировать по частоте и критичности, расставлять приоритеты и на этой основе определять очерёдность "перетряски" модулей.

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

[staircaseMaker]

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

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

[WorldMaster]

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

Мне тут видится как минимум два пути.
1. Это попытка как то систематизировать весь проект. Составить список всех методов с хоть каким нибудь примерным описанием что они делают.
Потом возможно сгруппировать методы по обрабатываемым данных. В итоге у вас наверное получится что-то типа дерева где уже можно будет оперировать не такими большими объемами кода.
Потом перебирать методы в схожих группах и пытаться там все упорядочить.

2. Другой вариант это составить максимально полное ТЗ, либо привлечь специалиста который составит документацию с учетом имеющихся знаний и опыта. Затем просто написать весь проект заново.

[staircaseMaker]

Сообщение от WorldMaster

Составить список всех методов с хоть каким нибудь примерным описанием что они делают.

Подскажите пожалуйста, как должна выглядеть документация и как ее потом можно использовать?
можно ли документацией считать комментарий в начале каждой функкции прямо в коде, где написано, что именно она делает, какие входные и какие выходные параметры?

[WorldMaster]

Сообщение от staircaseMaker

Подскажите пожалуйста, как должна выглядеть документация и как ее потом можно использовать?

Четкое представление структуры документации наверняка можно найти если порыться в учебниках по ТРПО. Но если совсем уж радикально. И то лучше все таки специально натасканного инженера привлечь.
Если так в целом то документация должна быть в таком виде чтобы ее потом можно было четко структурировать по методам.

Сообщение от staircaseMaker

можно ли документацией считать комментарий в начале каждой функкции прямо в коде, где написано, что именно она делает, какие входные и какие выходные параметры?

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

Можно попробовать какие нибудь визуальные программные средства. Даже MS Visio для начала достаточно будет чтобы построить диаграмму классов и потоков данных.

[Pavia]

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

Выделить участки которые требуют срочного вмешательства.

Сообщение от staircaseMaker

Проблема, которую надо решить, именно в конструкторских модулях.

Тут видна неправильная расстановка приоритетов. Перво наперво вы должны выяснить, что хочет потребитель, заказчик, пользователь. Какие кнопки нажимает какие функции он использует что он проверят, а что забывает проверить.

Сообщение от staircaseMaker

писались разными программистами, одна и та же задача везде решается по-разному и дублирование кода просто катастрофическое.

Для этого есть системный аналитик(архитектор) которому должны подчиняться программисты. Он должен говорить какую функцию следует в какую библиотеку включить. Перед внесением в ветку проекта код разработчика проверяет его руководитель.

[WorldMaster]

Сообщение от Pavia

Перво наперво вы должны выяснить, что хочет потребитель, заказчик, пользователь. Какие кнопки нажимает какие функции он использует что он проверят, а что забывает проверить.

Сообщение от Pavia

Для этого есть системный аналитик(архитектор) которому должны подчиняться программисты. Он должен говорить какую функцию следует в какую библиотеку включить. Перед внесением в ветку проекта код разработчика проверяет его руководитель.

Это все в идеале. Большинство компаний в нашей стране так не работают. Изначально компания из 1-3 энтузиастов у которых основная задача выжить и заработать денег. Разработка правильных инструментов стоит далеко не на первом месте потому как времени и ресурсов на это попросту нету. Естественно все пишется бегом чтобы быстрее привлечь клиентуру.
А когда компания укрепилась на рынке, есть прогнозируемый приток финансов в бюджет можно заняться наладкой технической стороны.

Я думаю что если взять первые продукты MS или Apple то там тоже можно будет наблюдать ситуацию когда костыль на костыле, но лишь бы работало. И только через несколько лет компании пришли к осознанию процесса разработки ПО и способны привлечь и архитекторов и создать структуру отдела разработки и так далее.