Изменение подходов к разработке и выпуску ПО проекта DM

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

В ходе анализа релиза 3_0_0 точное количество багов, которые прошли в продакшн, не зафиксировано. Основная причина их появления связана не с действиями команды, а с архитектурными ограничениями системы. Продукт DM построен на устаревшем WinForms, с высокой связанностью компонентов и накопленным архитектурным долгом. Любые изменения могут непредсказуемо влиять на другие части системы, поэтому баги часто выявляются только после выхода в продакшн. Для минимизации подобных случаев рекомендуется ограничивать функциональные изменения, сосредотачиваться на стабилизации текущей версии и уделять приоритетное внимание поддержке и исправлению архитектурных проблем.

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

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

Реанимация и DA и работа на этой платформе.

Восстановление DA в исходном виде невозможно. Анализ текущего состояния и исходного кода показал, что проект изначально создавался без учёта современных принципов архитектуры программного обеспечения. Ранее на DA предпринимались попытки перейти на чистую архитектуру, но, как видно по Git-репозиторию, работа остановилась на этапе закладки архитектуры. Для восстановления DA рекомендуется переработать продукт, используя архитектурные подходы BM Linux, адаптируя их под специфику DA. При этом уже существующий код DA можно использовать для отдельных компонентов, например интеграций с PLC и части бизнес-логики, что позволит ускорить восстановление функциональности и обеспечить стабильность дальнейшего развития продукта.

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

На текущий момент, проект DM построен на устаревшей, сильно связанной архитектуре с использованием .NET Framework, что делает любые попытки внедрить внешний модульный функционал крайне рискованными. Перенос на .NET Core или рефакторинг системы для поддержки модулей в текущей архитектуре неизбежно приведёт к большому количеству багов, непредсказуемым регрессиям и увеличению технического долга.

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