|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
25.02.2018, 17:31 | #1 |
Пользователь
Регистрация: 25.02.2018
Сообщений: 18
|
Проблемы с архитектурой инженерной программы
Здравствуйте, уважаемые коллеги!
Помогите, пожалуйста, советом, как решить проблему с архитектурой приложения. Краткая предыстория проекта: мы производственная компания, занимаемся производством лестниц для частных домов по индивидуальному проекту. У нас есть система автоматизированного проектирования (сапр). Система сделанная в виде веб-приложения, 3D модель лестницы строится с использованием библиотеки three.js. Система хаотично росла из простенького онлайн калькулятора в течение нескольких лет. Разработка велась командой из 5 удаленных программистов, каждый прорабатывал свою модель лестницы. Их работу на уровне кода никто не проверял, проверялась только итоговая работа системы. В итоге сейчас система полностью написана, но на выходе каждая вторая спроектированная лестница ошибки: где-то отверстия не совпадают, где-то детали пересекаются между собой, где-то часть деталей на модели есть, а в спецификацию не попали и т.п. На уровне кода система разделена на ядро, содержащее модули визуализации, взаимодействия с пользователем, работы с базой и т.п. и конструкторские модули, которые непосредственно создают модель лестницы (отдельный модуль для каждой серии лестниц, всего 8 серий). Проблема, которую надо решить, именно в конструкторских модулях. По-хорошему, чтобы устранить технические ошибки, надо проверить алгоритм построения модели на уровне кода. Но совокупный объем конструкторских модулей больше 300 тысяч строк, комментариев в коде нет, документации нет, везде встречаются “магические цифры”, которые непонятно откуда взяты. Кроме того, так как разные модули писались разными программистами, одна и та же задача везде решается по-разному и дублирование кода просто катастрофическое. Система уже год эксплуатируется, но все результаты работы системы перед запуском в производство вручную проверяются и дорабатываются инженерами на производстве. Обнаруживаемые ошибки исправляются в коде, но, такое ощущение, что исправление ошибок часто порождает новые ошибки в других местах. Мне бы хотелось получить от опытных разработчиков какие-то советы, что теперь со всем этим можно сделать, чтобы система наконец заработала нормально. Толковые детальные консультации мы готовы оплатить. |
25.02.2018, 17:52 | #2 |
Программист
Участник клуба
Регистрация: 23.06.2009
Сообщений: 1,772
|
Такие вещи всегда должен интегрировать кто-то знающий.. И обязательно нужен этап сопровождения - как раз чтобы отлавливать всплывающие ошибки
Я думаю, вам не обойтись без привлечения специалиста, который для начала подтвердит вашу догадку. Ведь проблема может быть и в ядре и даже в протоколе взаимодействия. За время ковыряния он должен получить представление о вашей системе и выдать дальнейшие рекомендации |
25.02.2018, 18:01 | #3 |
Пользователь
Регистрация: 25.02.2018
Сообщений: 18
|
Поясните, пожалуйста, поподробнее что это значит. Вообщем-то, первую версию системы писал я сам, так что где именно находится проблема понятно. Дальше я выступал в роли заказчика - ставил задачи программистам, контролировал работу программы. Моя очень большая ошибка заключалась в том, что сам код, который пишется, я не проверял - смотрел только поведение системы. Переписать весь код своими силами сейчас я не могу, т.к. много других задач. Вопрос в том, как правильно организовать рефакторинг, чтобы после рефакторинга не получить те же самые проблемы.
|
25.02.2018, 19:00 | #4 |
Программист
Участник клуба
Регистрация: 23.06.2009
Сообщений: 1,772
|
Это уже легче.
Тогда, вероятно, нужно начинать с хорошего багтрекинга - все ошибки фиксировать, сортировать по частоте и критичности, расставлять приоритеты и на этой основе определять очерёдность "перетряски" модулей. Что касается самого рефакторинга, то боюсь, что при таком зоопарке каждый модуль потребует индивидуального подхода. Возможно, имеет смысл привлечь кого-то из этих разработчиков, у них меньше порог вхождения |
25.02.2018, 21:04 | #5 | |
Пользователь
Регистрация: 25.02.2018
Сообщений: 18
|
Цитата:
|
|
27.02.2018, 08:42 | #6 |
Старожил
Регистрация: 25.08.2011
Сообщений: 2,841
|
Вот так всегда и получается. По началу на мелкие недочеты не обращаешь внимания пока это все не соберется в огромный снежный ком.
Мне тут видится как минимум два пути. 1. Это попытка как то систематизировать весь проект. Составить список всех методов с хоть каким нибудь примерным описанием что они делают. Потом возможно сгруппировать методы по обрабатываемым данных. В итоге у вас наверное получится что-то типа дерева где уже можно будет оперировать не такими большими объемами кода. Потом перебирать методы в схожих группах и пытаться там все упорядочить. 2. Другой вариант это составить максимально полное ТЗ, либо привлечь специалиста который составит документацию с учетом имеющихся знаний и опыта. Затем просто написать весь проект заново.
Skype - wmaster_s E-Mail - WorldMasters@gmail.com
Работаем по 3 критериям - быстро, качественно, недорого. Заказчик выбирает любые два. |
27.02.2018, 13:30 | #7 | |
Пользователь
Регистрация: 25.02.2018
Сообщений: 18
|
Цитата:
можно ли документацией считать комментарий в начале каждой функкции прямо в коде, где написано, что именно она делает, какие входные и какие выходные параметры? |
|
27.02.2018, 14:10 | #8 | ||
Старожил
Регистрация: 25.08.2011
Сообщений: 2,841
|
Цитата:
Если так в целом то документация должна быть в таком виде чтобы ее потом можно было четко структурировать по методам. Цитата:
Обзывать методы тоже хорошо но тогда нужно придерживаться строгого определения или формата описания. Это нужно чтобы не получилось что вы по ошибке методы со схожим кодом или схожей задачей обозвали по разному. Можно попробовать какие нибудь визуальные программные средства. Даже MS Visio для начала достаточно будет чтобы построить диаграмму классов и потоков данных.
Skype - wmaster_s E-Mail - WorldMasters@gmail.com
Работаем по 3 критериям - быстро, качественно, недорого. Заказчик выбирает любые два. |
||
27.02.2018, 14:24 | #9 | |
Лис
Старожил
Регистрация: 18.09.2015
Сообщений: 2,409
|
staircaseMaker
С менеджмента. Вам нужен специалист который грамотно организует работу, распишет бизнес процессы. Процесс ренфакторинга преложительно к вашей задачи должен быть непрерывным. Плюс тестирование, так как большинство ошибок находится именно во время тестирования. Все программисты должны быть вовлечены в эти процессы. Запланировать, а вернее нарезать время на каждую из этих подзадач. Введение нового функционала сократить до минимума. Выделить участки которые требуют срочного вмешательства. Цитата:
Для этого есть системный аналитик(архитектор) которому должны подчиняться программисты. Он должен говорить какую функцию следует в какую библиотеку включить. Перед внесением в ветку проекта код разработчика проверяет его руководитель.
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
У дзен программиста программа делает то что он хотел, а не то что он написал . Последний раз редактировалось Pavia; 27.02.2018 в 14:39. |
|
27.02.2018, 14:49 | #10 | ||
Старожил
Регистрация: 25.08.2011
Сообщений: 2,841
|
Цитата:
Цитата:
А когда компания укрепилась на рынке, есть прогнозируемый приток финансов в бюджет можно заняться наладкой технической стороны. Я думаю что если взять первые продукты MS или Apple то там тоже можно будет наблюдать ситуацию когда костыль на костыле, но лишь бы работало. И только через несколько лет компании пришли к осознанию процесса разработки ПО и способны привлечь и архитекторов и создать структуру отдела разработки и так далее.
Skype - wmaster_s E-Mail - WorldMasters@gmail.com
Работаем по 3 критериям - быстро, качественно, недорого. Заказчик выбирает любые два. |
||
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Проблемы с компиляцией программы | mrKrog | Общие вопросы C/C++ | 16 | 25.05.2017 22:20 |
"Огниво" – Блокнот для прозы, инженерной мысли, личных записей и планов на жизнь | Ognivo | Софт | 13 | 09.10.2014 23:51 |
Чудо инженерной мысли | sweex1234 | Помощь студентам | 1 | 17.02.2011 19:02 |
Проблемы с запуском программы | Gogent | Помощь студентам | 2 | 19.08.2010 13:08 |